msbuild
msbuild copied to clipboard
dotnet
.NET Framework TaskHost
Currently, MSBuild running on .NET Core cannot run tasks compiled against the full desktop .NET environment (because those assemblies can't be loaded in-proc in a .NET Core process). This might be overly limiting, especially considering existing NuGet packages that are built targeting MSBuild 12 or 14.
There's some precedent for this: full-framework MSBuild ships with MSBuildTaskHost.exe, which is used to run tasks that require a different runtime (in practice, this means that they were compiled against .NET Framework version 2 instead of 4.x). There's logic in NodeProviderOutOfProcTaskHost to identify the the right executable to run a task that could potentially be extended.
Further considerations:
- Is this worth the effort?
- Will there be communication-protocol problems between nodes running on different runtimes?
- Should probably allow Mono, .NET Core, and Full Framework options (though assemblies that target netstandard should work in Mono and desktop).
- what if different runtimes have different dependency resolution schemes (e.g. deps.json)
We could also require people to re-compile their tasks against .net core assemblies, which would make them work on full framework as well. But this would not be a transparent thing :)
If we want to reach a unified build engine then this is worth the effort. I don't see alternatives (other than changing the core clr)
I can see this potentially working on windows, but how would you imagine this working for x-plat? At this point I'm not sure it is actually worth the effort but it depends on the compat goals for windows.
@weshaggard Right, you couldn't possibly run a full-framework task off of Windows. Could potentially use Mono . . .
I tend to agree that this doesn't seem worthwhile.
My feeling is that if we open source MSBuild, it should be able to compile existing projects on Windows and Mono, period. There's no point in an MSBuild that can't compile the millions and millions of existing projects out there, many of which use custom tasks, and many of which will need to continue to be maintained and usable with .NET Framework and Mono (or son-of-Mono) for a very long time going forward. Otherwise we will forever live in a bifurcated world.
For F#, it's an absolute nightmare to see every F# community project having to support two build systems, two runtimes, two frameworks, two package dependency managers.... No one in the world can deal with the complexity that a bifurcated set of development tools brings. If we don't simplify things - by It Just Works techniques which maintain compat - then people will simply stop doing .NET development because making the simplest repo will be too complex.
So I do beg you, for the sake of the future, please make the open source MSBuild just work on existing Windows .NET Framework and Mono projects. It's just a build tool, it should just work.
@dsyme There's not a separate open source version of MSBuild that can't build existing projects. There are multiple versions of MSBuild, but they all are open source. Right now the full framework version of MSBuild is built out of the master branch, and the Mono and .NET Core versions of MSBuild are built out of the xplat branch. I believe work is underway to merge these all into the same branch.
The .NET Core version of MSBuild does not support building most existing projects. It was created mainly to support building .NET Core projects without depending on the full .NET Framework (or Mono). Now that the .NET Core tooling is going to be based on MSBuild, there will probably need to be some more thought into how it works with existing projects. The answer may be just to use the full framework or Mono versions of MSBuild (which are also open source) to build non .NET Core projects.
@dsplaisted Thanks for that clarification. I guess I'd like one MSBuild, that does everything reasonably possible, since at any particular point in time I'll probably have no actual idea which MSBuild I'm running.
TBH this whole .NET Core v. .NET Framework v. Mono tooling bifurcation (or trifurcation) is enough to drive any repo owner or contributor crazy. I really fear that people will just stop creating .NET libraries because of the complexity involved in even learning enough of this stuff to contribute.
If I understand this issue correctly, I think it's critical to be run tasks and handle targets from any source from the perspective of using MSBuild as an API. In OmniSharp, we use the MSBuild API to process projects -- regardless of whether that project is targeting Mono, Windows, or .NET Core. Today, if we're compiled against full framework, we can process full framework projects; if we're compiled against .NET Core, we can't.
In my view, having a different msbuild.exe executable that handled different platform-targeted project would be akin to the C# compiler not being able to target .NET Framework 3.5 unless it was compiled against .NET Framework 3.5.
I agree that msbuild should be able to build various project types but the task libraries are the thing in question here.
In my view, having a different msbuild.exe executable that handled different platform-targeted project would be akin to the C# compiler not being able to target .NET Framework 3.5 unless it was compiled against .NET Framework 3.5.
While I agree with your general concern I think msbuild is a little different then csc here in the fact that it actually needs to load arbitrary task libraries up for running in process. In order to do that they have to be running on a compatible runtime and framework. This is more closely connected to running Roslyn Analyzers in process with the compiler that were built on a different framework, it just doesn't work in all cases. We should definitely have portable task libraries work in any of these targets but it is much more difficult to take older preexisting task libraries that might use everything in the full framework and get them running on .NET Core (especially x-plat).
I totally get that point Wes and I realize that we'd have to do something like what's described above (some MSBuildTaskHost.exe) to make older tasks work. My point is that the problem proliferates to any MSBuild API consumer -- not just MSBuild itself. Every API consumer will need to either run on Desktop, or deal with tons of fallout when running as a .NET Core App.
There's additional fun, because running tasks isn't the only place where we might be highly OS or Framework dependent--we offer property functions that can be as well, and don't have any way to remote them to another runtime. Most of the approved list should work fine, so this may not be too much of a problem, but it's worth worrying about. ToolLocationHelper is scary due to its Windows entanglements, but looks to be mostly filesystem and registry code that could work on Windows/.NET Core.
