MSBuild NuGet package

[jnm2]

Please provide an MSBuild NuGet package. It would help immensely with versatility and reliability of build scripts.

Not having a NuGet package causes problems in things like Cake scripts which obtain tooling from NuGet without affecting the rest of the machine. It becomes difficult to cleanly locate MSBuild (#1377). People (e.g. Cake) resort to searching the default SKU paths, which requires you to install VS2017. Installing VS2017 is bloat for many people.

I know that https://www.visualstudio.com/downloads/#build-tools-for-visual-studio-2017-rc exists but the problem is that it affects the whole build server, not just a single isolated build. Currently in order to take advantage of the new CPS .csproj format or C# 7 language features, I have do a machine-affecting installation. Even if this build tools package worked with Cake build scripts today, it's not something we'd be very able or willing to experiment with on our build server the way we could if it was a no-install NuGet package.

I can't think of a single downside to the NuGet approach. You'd be able to download a specific version to a specific folder, and most importantly have the exact MSBuild version be source-controlled in the build script without being affected by shared installations.

/cc @onovotny @devlead

[rainersigwald]

We provide such a NuGet package since #1080: https://www.nuget.org/packages/Microsoft.Build.Runtime. However, you may not find it very useful, because it doesn't contain the tasks and targets needed to build much of anything.

This is the motivation behind the Sdks feature--initial design at #1493, partially implemented for the current VS2017/MSBuild 15.1 release but without the crucial acquisition story (#1436) to open it up for third-party Sdks. We plan to continue development on this but don't have a specific timeline for it at the moment.

I can't think of a single downside to the NuGet approach.

There is a major one: it requires that all SDKs be available in a packaged form. They are currently not. That includes SDKs that are no longer in active development and those whose maintainers don't weigh a strong desire to have an installer-free experience higher than other work they're doing. Without the SDKs that projects use, having an unzip-and-run copy of MSBuild isn't worth much. But at least we have that, now!

[jnm2]

Great, this is good information! I'd like to figure out which issues to follow until it is possible to build a solution that contains Roslyn Project System .csprojs and traditional .vcxprojs using only MSBuild tooling and SDKs from NuGet.

If I understand you correctly, you're saying MSBuild is ahead of the game and it's already on NuGet, but it can't be used with any SDKs at all because the MSBuild work hasn't been done to load SDKs from packages? Or can some SDKs be used right now? Is there one place to go for documentation on all of this?

If I copy the SDK tasks and targets from a VS2017 installation to a build-local folder on a build machine without VS2017, can I use the MSBuild NuGet package and manually point MSBuild at the tasks and targets in that folder, as a workaround in the meantime? I'm okay with my build script adding XML to the project file to locate the targets if that's what it takes.

[rainersigwald]

If I understand you correctly, you're saying MSBuild is ahead of the game and it's already on NuGet, but it can't be used with any SDKs at all because the MSBuild work hasn't been done to load SDKs from packages?

Essentially correct. If you want to xcopy deploy MSBuild today, you must supply your own SDKs. The CLI does this in its build, and VS does it through a combination of VSIX packages that assemble at install time.

Is there one place to go for documentation on all of this?

Not at the moment. We're aware that this is bad.

If I copy the SDK tasks and targets from a VS2017 installation to a build-local folder on a build machine without VS2017, can I use the MSBuild NuGet package and manually point MSBuild at the tasks and targets in that folder, as a workaround in the meantime?

With my could-it-work/hacker hat (🤠) on: yeah, that could probably be made to work, for projects that use only the new Core SDKs. There's nothing magic about how the CLI or VS puts files into a subfolder and/or sets the MSBuildSdksPath environment variable before invoking MSBuild. You'd have to make sure the Roslyn compiler made it into the mix too.

With my Microsoft-employee hat (🎩?) on: that is not a supported configuration, so you'd be on your own with any problems you discovered.