Add documentation for the risks for version incompatibilities between msbuild and a plugin dependencies about msbuild

[rainersigwald]

There are two relevant things here:

1. For applications that use the MSBuild API, we need to be able to load MSBuild from the SDK folder, so MSBuildLocator adds a resolver to find assemblies from there. This does not, however, override the runtime behavior that prefers to load assemblies "from next to the application" if they exist there.
2. For MSBuild task plugins, we are (usually) running in an application from the SDK folder. We use AssemblyDependencyResolver to respect a .deps.json if the task provides one which should allow using a different version of one of our dependencies in the task's ALC.

This started with the first situation: mpc.exe shipped CodeDOM v6.0.0.0 but an MSBuild assembly loaded from the SDK directory wanted to load CodeDOM v8.0.0.0. Removing it from the app directory via ExcludeAssets="runtime" cleared that up.

I'm not completely sure why removing the CodeDOM deployment from next to the task caused failures there; the SDK copy should be just as available in that context.

[YuliiaKovalova]

@vitek-karas, this issue can be interesting for you.
Before bumping to net8.0, there weren't any compatibility problems between used System.CodeDom net6.0 in the source project and net7.0 in MSBuild.

cc: @baronfel

[vitek-karas]

My guess would be that the problem is caused by:

 <PackageReference Include="System.CodeDom" ExcludeAssets="runtime" />

This brings in the 8.0 version of System.CodeDom but only as a compiler reference, it explicitly excludes it from the output. So when SDK builds this along with MSBuild - it will probably use the MSbuild's version (7.0) in the output. The end result is that you have a package/app which has code which references 8.0, but carries 7.0 as the implementation.

I don't know why the ExcludeAssets was added above.

That said there are other possible reasons, this involves custom ALCs and MSBuild's custom assembly resolution logic, so that might complicate things even more.

[YuliiaKovalova]

cc: @AArnott

[AArnott]

@vitek-karas I added ExcludeAssets above, and it worked, because I don't reference System.CodeDom 8.0. I reference the 6.0 version. That makes it work with MSBuild whether MSBuild provides 6.0, 7.0, or 8.0 of the System.CodeDom dll.

The original failure was because I shipped the 6.0 assembly while MSBuild wanted 8.0. Because I shipped it, .NET loaded the 6.0 version, and refused to load the 8.0 version that MSBuild itself required.

[vitek-karas]

@AArnott oh - sorry, my bad. Thanks for the explanation. I missed the package version part of your PR.

@YuliiaKovalova if you want I can look into this some more, but I would need to know what is the project you're building - is it the message pack executable, or something else?

/cc @elinor-fung

[AArnott]

@vitek-karas for the repo @YuliiaKovalova links to, which I maintain, there are two front-ends that matter:

1. An executable that uses MSBuildLocator.
2. An MSBuild Task.

Both of these front-end projects depend on MessagePack.Generator.Core, a library that depends on System.CodeDom.dll.

[vitek-karas]

I guess this problem then happens when the MSBuild task is loaded into some msbuild execution. It doesn't carry System.CodeDom with it, and instead relies on the one from msbuild. That would explain the behavior above.

I don't know what's the detailed design of allowing msbuild tasks to carry their own versions of some of the msbuild dependencies - like System.CodeDom.