-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Update MicrosoftBuildVersion to latest #98006
Update MicrosoftBuildVersion to latest #98006
Conversation
…raphy.XML component governance alert.
Tagging subscribers to this area: @dotnet/runtime-infrastructure Issue DetailsUpdate MicrosoftBuildVersion to latest to fix a component governance alert.
|
... necessary for dotnet/runtime#98006
* Add MSBuild 17.8.3 + dependencies ... necessary for dotnet/runtime#98006 * Add manual pragma warning disable as in dotnet/runtime
@ericstj @rainersigwald MSBuild exposes the internal type Why is internal type required? Its omission causes the build failures in this PR. |
Looks like this introduced the interface: dotnet/msbuild@f69319c I suspect we're mixing assemblies here. Looks like we have TaskItem that claims it implements internal interface IMetadataContainer, but then we have a reference package for Microsoft.Build.Framework without IMetadataContainer. Looks like the compiler needs to resolve (all) interfaces whenever you cast from contrete type to interface. Can we fix this by making sure we reference all live or all SBRP packages and not a mix? IIUC The interface lives in Microsoft.Build.Framework and the consumer is in Microsoft.Build.Utilities. Update: we don't seem to be mixing assemblies. I see the following in the binlog. |
Oh, maybe it's because we don't actually have a 17.8.3 in SBRP so it pulled the real one. That explains it. https://github.com/dotnet/source-build-reference-packages/tree/main/src/referencePackages/src/microsoft.build.utilities.core Looks like we have a consistent set for 17.4.0, but not 17.8.3 |
Hmm I wonder why the source-build flag doesn't report Microsoft.Build.Utilties.Core and Microsoft.Build.Tasks.Core 17.8.3 as new prebuilts. cc @dotnet/source-build-internal Maybe because the build failed? I wonder if the prebuilt analysis should always run. It only needs project.assets.json so only the restore needs to succeed, right? |
Yes - prebuilt detection only runs upon a successful build. |
Filed dotnet/source-build#4103 for prebuilt detection not running for failing builds. |
Required for dotnet/runtime#98006 Follow-up on #885
…8.3 (#886) * Add Microsoft.Build.Tasks.Core and Microsoft.Build.Utilities.Core 17.8.3 Required for dotnet/runtime#98006 Follow-up on #885 * Update unrelated files * Manual change because of attribute filtering by GenAPI * Remove dependency from nuspec as well
Needs #98178 |
@LoopedBard3 @ViktorHofer looks like we need to backport this to release/8.0, 7.0, and 6.0. |
/backport to release/8.0 |
Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/8542745559 |
Update MicrosoftBuildVersion to latest to fix a component governance alert.