Using Microsoft.Build.Runtime with a self-contained application

[MansenC]

Hey there,

as the title says I'm basically trying to ship a self-contained application built with .NET with MSBuild so the users of my program do not need to install Visual Studio or MSBuild themselves. The description of the Microsoft.Build.Runtime NuGet package basically says it does exactly that, and then states that there have to be additional steps to achieve this. I could not find a single bit of documentation on how to achieve that, so I've been struggling through some issues along here.

What I have achieved so far:
I have looked into what MSBuildLocator does for registering Visual Studio instances, and registered the following environment variables: MSBUILD_EXE_PATH to the MSBuild.dll shipped with my application, MSBuildExtensionsPath to the folder where the MSBuild.dll is located and MSBuildSDKsPath to a sub folder called Sdks in that path. MSBuild.dll is located in my application folder with the rest of everything .NET related. That by itself obviously doesn't do all the trick.
After adding the Microsoft.Build.NuGetSdkResolver package that was then required, I failed when MSBuild could not locate the Microsoft.NET.Sdk sdk definition when I tried to load a project.

Here's issue number 1: Into my Sdks folder I manually copied the Microsoft.NET.Sdk and Microsoft.NET.ILLink.Tasks Sdks and set the environment variable MSBuildEnableWorkloadResolver to false. This made the project load because the definitions were there. But manually copying these is really bad, and ideally I don't want to clutter my Git with these files. So is there a better way to include these definitions? I got them from my installation of .NET 6.0

So, going on, the project finally loaded. But what am I trying to do with the project? I want to restore it. However, after calling CreateProjectInstance on my MSBuild.Evaluation.Project file I got from parsing and checking, whether the target Restore does exist in the defined Targets I found out that it doesn't. No restore for my projects since the target doesn't exist is quite odd, so what things am I forgetting that I cannot do that.

Alternatively to Restore I tried the target Build and now I get a build failure as a result. Adding a logger to my build request reveals the error message that reads: The "ProcessFrameworkReferences" task was not given a value for the required parameter "RuntimeGraphPath". @MSBuildPath\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets:90. Edit: This was solved by copying the missing file Microsoft.NETCoreSdk.BundledVersions.props into the root directory. This made the build start, however the build is now reporting that a NuGet restore is required. The restore still is not present in the project's targets.

I'm at a loss on how to continue or how to include MSBuild with my application, so I hope someone can help me continue. Thanks in advance

[rainersigwald]

There is unfortunately no documentation on this. We have two distributions of MSBuild + enough other stuff to work. .NET SDK uses the Runtime package and packages a bunch of other stuff--but we don't have a clear picture of how much of that stuff is required, because that understanding is not required to build the SDK, which may need the stuff for other reasons.

Likewise, Visual Studio ships MSBuild (the bits built from this repo) packaged in a VSIX file + many, many other things, defined in an internal-to-Microsoft graph that also doesn't have clear delineations on what is required.

It's likely possible to assemble enough open-source bits to get the functionality of the .NET SDK in your own distribution, but that sounds very difficult to me. So difficult that I would not do it, in favor of requiring that the .NET SDK be installed.

[MansenC]

Surprisingly, in the time in between I managed to get it to run. Well, sort of, but on that later.

I had to include the NuGet.Build.Tasks package and now copy the following required files into the application directory:

• SdkDir/Sdks/Microsoft.NET.ILLink.Tasks
• SdkDir/Sdks/Microsoft.NET.Sdk
• SdkDir/Roslyn
• SdkDir/Microsoft.NETCoreSdk.BundledVersions.props
• SdkDir/NuGet.props
• SdkDir/NuGet.RestoreEx.targets
• SdkDir/NuGet.targets

And that's it. Those were the missing puzzle pieces so far. And it works if I start this in Visual Studio. So, for claricifaction I have my native application that can host my .Net code, and I have a "debug adapter" that replaces all that code with just an http server so I can actually debug when calls to my .Net code are made. And that is what I mean by starting in Visual Studio, with the debug adapter everything works like a charm, I found the restore task, analyzing using Roslyn works fine. The issue now comes up when I start my code using the native host.
I now simply get the error message when calling restore on a project that goes as follows: MSB ERROR: The \"WarnForInvalidProjectsTask\" task could not be instantiated from the assembly "NuGet.Build.Tasks.dll\. Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Unable to cast object of type 'NuGet.Build.Tasks.WarnForInvalidProjectsTask' to type 'Microsoft.Build.Framework.ITask'.. And that is quite odd to, since it's an error that should just come up when a different version of the MSB Framework is being loaded. It's the same DLL and version that is being loaded both for when I execute my debug adapter and when I start the system using my native host. And I verified that using procmon, only one attempt is being made at loading the framework, it'st he same file so I am quite surprised to see a version mismatch error being raised. I even created a new instance of that task and explicitly casted it to ITask and everything worked fine, this only happens when MSBuild gets to invoke that Target defined in NuGet.targets. I hope I can somehow fix this issue but I expect it's going to take quite some time. The good thing is so far that running the code without any programming environment does produce the same error so this seems like the last hurdle I have to get over