Microsoft.Build.Runtime packages can not be consumed by netstandard1.6

[DustinCampbell]

Currently, the Microsoft.Build.Runtime package wont deploy if it is referenced by a project target netstandard1.6. It only supports net46 and netcoreapp1.0. This blocks OmniSharp from taking a dependency on this package because the MSBuild project system in OmniSharp is defined in a library.

[eerhardt]

In general, I find it non-conventional for a "library" to depend on an "executable program". Your netstandard1.6 library is stating it will run on any platform that supports netstandard1.6. But you are requiring an executable program that actually requires a runnable platform in order to be invoked.

I don't think MSBuild is doing anything wrong here - in order to actually use its runtime package, it needs a specific runnable platform: either net46 or netcoreapp1.0. It can't say "my program will execute correctly on any platform that supports netstandard1.6". For example, if Xamarin IOS supports netstandard1.6, would you expect MSBuild.exe to run on it?

In my opinion, Microsoft.Build.Runtime is a program - not a library. And as such, it needs to follow rules about executables, not libraries.

/cc @ericstj - to get his take on this issue.

[DustinCampbell]

That's true @eerhardt, and I agree with you. However, my current understanding of MSBuild (which is possibly limited in this matter) is that it searches in various locations for the presence of msbuild.exe just to establish a tools path but never actually uses it. By design, it crashes if it can't find msbuild.exe. So, in the scenario that I'm working on where MSBuild is used purely as a library in-process and msbuild.exe is never even executed, it is still required to be there.

[DustinCampbell]

FWIW, I would be completely if the APIs allowed a way to specify a tools path so that msbuild.exe weren't required at all. 😄

[rainersigwald]

We could potentially change our toolset-identification code and allow missing MSBuild.exe. Multiproc builds would break--we'd need to keep track of the fact that we were proceeding without the ability to run multiproc and throw a nice error.

Since we're seeing so many of these problems I'm starting to think this might be the best idea. Even though it's awful.

[eerhardt]

Maybe there are two "modes"/"scenarios"/"use cases" here that need separation:

1. You want to deploy the full MSBuild application along with your application, so you can shell out to it. (The CLI needs/wants this.)
2. You want to load up MSBuild in your current process and start invoking APIs on it, but you will never try invoking it in a separate process.

@DustinCampbell - your scenario is strictly #2, right?

I 100% agree with you that in scenario #2, me as the caller/loader of MSBuild - I should be able to tell MSBuild all the "locations" it needs to know about.

[DustinCampbell]

@eerhardt -- yup my scenario is purely #2. I rely on you for #1. 😁

[DustinCampbell]

@rainersigwald: this is my scenario: https://github.com/OmniSharp/omnisharp-roslyn/blob/dev/src/OmniSharp.MSBuild/ProjectFile/ProjectFileInfo.cs#L92-L185. Does that help?

[rainersigwald]

@DustinCampbell Yeah, your scenario makes sense. The problem is that from MSBuild's perspective, it's almost identical to a scenario that does require starting another MSBuild.exe--all you need to do is build with a multiproc option instead of through projectInstance.Build().

I'm wary of building a package that supports building--unless you set an option, in which case it catastrophically fails. But that would serve your needs (and others!).

[DustinCampbell]

Catastrophically failing if I set an option to do multiproc builds without have the facilities to do a multiproc build (e.g. MSBuild.exe) seems perfectly reasonable to me.

[jeffkl]

With or without MSBuild.exe in the package it could technically support netstandard1.5+.

My concerns:

• Our package can evaluate our build very few project types or of the box. We still need a more in depth package from an upstream team that has compilers etc.
• I need to verify where or not our contentFiles will be copied to the top level app's output if a library is pulled in which depends on our runtime. From Dustin's attempt it appears they do not.

I also wanted to paste in my explanation from email so it is captured here:

the MSBuild runtime is not a simple assembly to redistribute. You technically need a collection of .props and .targets, along with task assemblies and compilers. That’s just to build standard projects. If you want to build Azure projects, Visual Studio SDK projects, C++ projects, or anything more custom you need another set of .props, .targets, and task assemblies for each one.

In the past, MSBuild was installed on the machine with its assemblies installed in the GAC and a known folder for SDKs to drop their extensions into. With the move to a no-install scenario plus cross platform support, we are hitting challenges with distribution. We’re facing the possibility that each app that wants to use MSBuild has to re-distribute everything or we need to create an installer that would work for all platforms.

[livarcocc]

Team triage: just use https://github.com/microsoft/MSBuildLocator.