dotnet
Create a .NET TaskHost so that .NET Framework MSBuild can consume .NET Tasks
Task declaration supports a Runtime attribute that allows MSBuild-running-on-.NET-4 to call tasks that support only .NET 3.5 (by spawning an MSBuildTaskHost.exe that runs on .NET 3.5 and communicates with the rest of the build via IPC).
Similar support could be used to support running .NET Core (or .NET Standard 2.1+) tasks from Visual Studio with Runtime="NET" (or something like that).
A more immediate solution would be to allow Visual Studio to run the entire build on .NET Core.
That could be complemented by failing if .NET Framework-based MSBuild attempted to run a task marked with Runtime="Core".
@john-larson "yes" in the sense "we still think this is a good idea worth doing sometime hopefully soon", but "no" in the "we have a planned time to work on this".
@rainersigwald, just wondering if there are any ways to run the code in a newer runtime? I am looking for workarounds.
@Denis535 the best option at the moment to run code during a .NET Framework/Visual Studio-driven build is to use an executable; then you can use anything that will run on the machine.
Similar support could be used to support running .NET Core (or .NET Standard 2.1+) tasks from Visual Studio with
Runtime="Core"
OR vice-versa, i.e. running full framework tasks from Core MSBuild via Runtime="CLR2/CLR4"
OR vice-versa, i.e. running full framework tasks from Core MSBuild via Runtime="CLR2/CLR4"
@Nirmal4G that's #711
Yeah, it seems I'm the one marked the issue but forgot entirely. Silly me 😜🙃
I am particularly interested in seeing this implemented. Is there a way for a community member to help?
@teo-tsirpanis Unfortunately, I think most of the work for this is
- building consensus on direction with VS partners
- deciding on some VS-specific implementation details
- making VSIX authoring changes that can only be tested by triggering internal VS test builds
which makes it pretty hard to help externally.
Can you expand on your desire for the feature though? Having clear use cases can help us prioritize it internally.
I have an MSBuild task that runs after compilation and executes code from the compiled assembly using AssemblyLoadContext, necessiating targeting modern .NET. To support the .NET Framework edition of MSBuild Visual Studio runs I tried to do the same with AppDomains but gave up; I could not make it load the assembly's dependencies, and the complete object isolation of app domains would affect the structure of my code.
So what I did is run the task out-of-process on modern .NET when we build on .NET Framework, but this presents its own challenges. The out-of-process tool has to be installed separately (to avoid increasing package size for everyone), sending logging messages requires additional ceremony ~~, and there are issues around targeting frameworks greater than the tool (the tool runs on .NET 6 and cannot load .NET 7 assemblies, while the in-process task runs on the same framework as the SDK and does not have this problem)~~.
Implementing this would reduce complexity in my code and improve the user experience.
Great news! (I was just going to tag @ViktorHofer (for runtime repo) but saw he has already reacted 😉)
