-
Notifications
You must be signed in to change notification settings - Fork 519
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
[dotnet] Hardcode 'true' as the default value for GenerateSatelliteAssembliesForCore. Fixes #16193. #16306
Conversation
…sembliesForCore. Fixes dotnet#16193. Hardcode 'true' as the default value for GenerateSatelliteAssembliesForCore, because .NET gets it wrong when building from inside VS (Windows). When building using either VSMac or the command line (either from Windows or Mac), the `MSBuildRuntimeType` property is set to `Core`, and as a result, the default value for `GenerateSatelliteAssembliesForCore` is `true`: ```xml <GenerateSatelliteAssembliesForCore Condition=" '$(GenerateSatelliteAssembliesForCore)' == '' and '$(MSBuildRuntimeType)' == 'Core' ">true</GenerateSatelliteAssembliesForCore> ``` See: https://github.com/dotnet/sdk/blob/00100960bf06cb595daba647673cd0329be896f4/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets#L41 This is the correct behavior. However, when building from inside Visual Studio (for Windows), the `MSBuildRuntimeType` property is set to `Full`, and thus `GenerateSatelliteAssembliesForCore` is not set to `true`, and we end up executing al.exe to generate satellite assemblies, which is wrong (al.exe complains that 'arm64' is an invalid platform). Fix this by always defaulting `GenerateSatelliteAssembliesForCore` to `true`, independent on where we're executing. Ref: dotnet/sdk#28419. Fixes dotnet#16193.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
🔥 [PR Build] Build failed 🔥Build failed for the job 'Detect API changes' Pipeline on Agent |
🔥 Unable to find the contents for the comment: D:\a\1\s\change-detection\results\gh-comment.md does not exist :fire Pipeline on Agent |
💻 [PR Build] Tests on macOS M1 - Mac Big Sur (11.5) passed 💻✅ All tests on macOS M1 - Mac Big Sur (11.5) passed. Pipeline on Agent |
🚀 [CI Build] Test results 🚀Test results✅ All tests passed on VSTS: simulator tests. 🎉 All 223 tests passed 🎉 Tests counts✅ bcl: All 69 tests passed. Html Report (VSDrops) Download Pipeline on Agent |
Hardcode 'true' as the default value for GenerateSatelliteAssembliesForCore,
because .NET gets it wrong when building from inside VS (Windows).
When building using either VSMac or the command line (either from Windows or
Mac), the
MSBuildRuntimeType
property is set toCore
, and as a result, thedefault value for
GenerateSatelliteAssembliesForCore
istrue
:See: https://github.com/dotnet/sdk/blob/00100960bf06cb595daba647673cd0329be896f4/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets#L41
This is the correct behavior.
However, when building from inside Visual Studio (for Windows), the
MSBuildRuntimeType
property is set toFull
, and thusGenerateSatelliteAssembliesForCore
is not set totrue
, and we end upexecuting al.exe to generate satellite assemblies, which is wrong (al.exe
complains that 'arm64' is an invalid platform).
Fix this by always defaulting
GenerateSatelliteAssembliesForCore
totrue
,independent on where we're executing.
Ref: dotnet/sdk#28419.
Fixes #16193.