Open YuliiaKovalova opened 1 month ago
@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
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.
cc: @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.
@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
@vitek-karas for the repo @YuliiaKovalova links to, which I maintain, there are two front-ends that matter:
Both of these front-end projects depend on MessagePack.Generator.Core, a library that depends on System.CodeDom.dll.
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.
There are two relevant things here:
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.
Description:
We have encountered an issue, when MSBuild was using System.CodeDom net8.0 and the source project had System.CodeDom net6.0 package dependency that was copied in the output folder. During the runtime it caused the exception:
Suggested action
Document the versions that MSBuild binds to for each feature-band release and publish it as a part of documentation. The ticket #9312 can be used as a basement for that.