-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add documentation for the risks for version incompatibilities between msbuild and a plugin dependencies #10213
Comments
@vitek-karas, this issue can be interesting for you. 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 I don't know why the 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 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:
This started with the first situation: 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.
The text was updated successfully, but these errors were encountered: