Create a NuGet package containing the MSBuild runtime

[jeffkl]

We need a NuGet package that customers can reference to load projects and evaluate properties/items or do in-proc builds.

Proposal

Create a new package containing the .props, .targets, and .tasks files needed for evaluating projects. This will supersede the Microsoft.Build.Targets' andMSBuild` packages which we will deprecate.

The new package, Microsoft.Build.Runtime will have the following layout:

contentFiles
└─ any
   ├─ any
   |  ├─ 15.0
   |  |  └ Microsoft.Common.props
   |  │  *.props
   |  │  *.targets
   |  └  *.tasks
   ├─ net46
   |  │  MSBuild.exe
   |  └  MSBuild.exe.config
   └─ netcoreapp1.0
      └  MSBuild.exe

This will place what we consider to be the core MSBuild runtime into the end user's output directory.

Scenarios

.NET Core via dotnet run

In this scenario, the CLR loads assemblies from their NuGet package location. This means that our BuildEnvironmentHelper will need to be updated to look in AppContext.BaseDirectory instead of the directory containing Microsoft.Build.dll.

.NET Core via dotnet publish

This command places all dependencies in a folder named 'publish' and when running an application from this folder, the assemblies are loaded from that directory. The AppContext.BaseDirectory is still the correct place to use as MSBuild directory.

.NET Framework via building against net46

NuGet copies all of the referenced assemblies and content files to the output directory. The BuildEnvironmentHelper can remain the same for this scenario and use the directory containing Microsoft.Build.dll as the MSBuild directory.

Visual Studio

The BuildEnvironmentHelper already looks for the MSBuild directory based on the process name being devenv.exe or the VSINSTALLDIR environment variable. This means that extensions within Visual Studio or the Visual Studio Developer Command Prompt will use the MSBuild that ships with Visual Studio and won't need to redistribute the MSBuild runtime.

In-proc builds and project evaluation

Not everything will work when building or evaluating projects. This is because some build logic comes from various teams. This includes building Azure cloud projects, C++ projects, FSharp, etc. These teams will need to provide a package that users can reference along with the Microsoft.Build.Runtime package that will give them all of the required functionality to evaluate or build their projects.

Tasks

• Update BuildEnvironmentHelper to look in AppContext.BaseDirectory for .NET Core (Update BuildEnvironmentHelper to locate .NET Core app directory #1069)
• Create a .nuspec that will package up the intended .props, .targets, and .tasks as well as MSBuild.exe (NuGet package containing the MSBuild runtime #1080)
• Discuss the secondary packages with teams like Roslyn that would allow customers to build projects

Related issues

This new package should fix the following issues:

• Internal MSBuild Error: could not load type Microsoft.Build.Utilities.ToolLocationHelper #1000 Internal MSBuild Error: could not load type Microsoft.Build.Utilities.ToolLocationHelper
• Microsoft.Common.props should be contained in a "15.0" directory #882 Microsoft.Common.props should be contained in a "15.0" directory
• MSBuild package doesn't contain MSBuild.exe.config #872 MSBuild package doesn't contain MSBuild.exe.config

It is also related to:

• Deployment of targets with MSBuild #712 Deployment of targets with MSBuild
• Create packages to easily acquire and use .NET Core MSBuild #356 Create packages to easily acquire and use .NET Core MSBuild
• Create NuGet package with portable targets files #354 Create NuGet package with portable targets files
• Create NuGet package with .NET Core Roslyn tasks and targets #353 Create NuGet package with .NET Core Roslyn tasks and targets
• Targets, props, and tasks required for selfhost build should come from NuGet packages #195 Targets, props, and tasks required for selfhost build should come from NuGet packages

[natemcmaster]

I see it's not mentioned above, but was consideration given to the scenario of a DotNetCli tools that need to evaluate a project? e.g. ASP.NET CLI tools

[jeffkl]

Yes sorry we consider in-process builds and project evaluation to be the same thing. So any tool that wants to evaluate a project should be able to reference this package and do project evaluation. I've tested it out and it works for very basic scenarios. You must have all of the imports available so we'll probably need to work with other teams to ensure they have packages available for users to reference so that then end up with everything needed to evaluate and build projects.

I have updated the design above to mention project evaluation.

[natemcmaster]

Ok thanks for clarifying.

[DustinCampbell]

I see the PR was merged. Should this be closed at some point?

[jeffkl]

Yeah sorry I was leaving it open while I did some more testing. I'll close it for now.

[DustinCampbell]

Out of curiosity, is this published anywhere yet? I didn't see it in the dotnet-buildtools feed.

[natemcmaster]

@jeffkl which feed is the "Microsoft.Build.Runtime" package pushed to?

[jeffkl]

Sorry I'm fixing the versioning of the package and then I'll be publishing it. We had done some work in master and are getting that merged into xplat so that our packages don't collide. I'm working on a change right now and hope to publish the packages in the morning.

[jeffkl]

I have pushed the runtime package to our MSBuild MyGet feed: https://dotnet.myget.org/feed/msbuild/package/nuget/Microsoft.Build.Runtime/15.1.262-preview5

I'll work on getting daily builds pushed there. Let me know if you have any issues with the package.

[DustinCampbell]

I'm going to try the package shortly. Should this be uploaded to https://dotnet.myget.org/gallery/dotnet-buildtools? That's where we're currently grabbing MSBuild packages from.

[rainersigwald]

@DustinCampbell by request of the CLI team, we're moving away from the build-tools feed into our own. Unfortunately, right now we're in an awkward transition phase where you might need both.

[DustinCampbell]

Sounds good. I just wanted to check. I have no worries about changing feeds.

[DustinCampbell]

So far, I've been unable to successfully add a dependency on this package. It sends OmniSharp restore into fits:

https://github.com/OmniSharp/omnisharp-roslyn/blob/dev/src/OmniSharp.MSBuild/project.json

[DustinCampbell]

Just switching the feed without moving to the new package results in all manner of package downgrades, such as System.Collections from 4.0.11 to 4.0.11-rc3-24128-00