Change VSIX authoring to include .NET MSBuild

[rainersigwald]

In order to run a taskhost node on .NET from a .NET Framework host, we'll need the .NET MSBuild bits available, meaning we'll need to ship the .NET MSBuild.dll and supporting assemblies in our VSIX for insertion to VS.

I think this will be "add a new folder under MSBuild\Current\Bin named net with these files in it". The exact closure of files isn't totally clear to me and may need some experimentation--it's essentially "the output of a framework-dependent dotnet publish for MSBuild/net9".

[baronfel]

Having to ship a .NET build of MSBuild seems to go against the goal of decoupling VS and the SDK the user brings. Can we not use the information that the SDK resolver gives us to find the SDK to load/invoke .NET MSBuild nodes from?

[YuliiaKovalova]

I am wondering if we can use the same set of files that we put to core folder in bootstrap ?

[rainersigwald]

Having to ship a .NET build of MSBuild seems to go against the goal of decoupling VS and the SDK the user brings.

It isn't a full decoupling but is still a very meaningful step, I think.

Can we not use the information that the SDK resolver gives us to find the SDK to load/invoke .NET MSBuild nodes from?

This would be difficult because it would impose compatibility constraints on the IPC protocol that has long been constrained to talk only between the same versions of MSBuild. It'd probably be impossible to use the existing translation mechanisms and we'd have to rewrite our IPC or add a new mechanism in parallel--not just for properties/items (easy) but also for all the types of log messages that can be generated in a task.

And the benefit would be quite limited: we have a great track record of maintaining task compatibility for old tasks on new MSBuild engines. I don't expect that .NET runtimes and core libraries will make changes so breaking in the future that that wouldn't stay true.

There is one very solid benefit though: today we target .NET 4.7.2 and .NET 9. Soon we'll target net472 and net10.0, then eventually net11.0 and so on. If we use that MSBuild.dll as the taskhost we'll run into cases where we're running .NET 10 SDK tasks on .NET 11 purely for the MSBuild bits to run, which would require installing .NET 11 even on a machine that intends to build only .NET 10 stuff.

Do you think it'd be worth building that compatible communication protocol out to get the "slightly more self-contained" SDK behavior?

[rainersigwald]

I am wondering if we can use the same set of files that we put to core folder in bootstrap ?

I think it'd be a subset: all (I think?) the DLLs and the .deps.json file but none of the targets.