Skip to content
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

Merged
merged 2 commits into from
Oct 10, 2022

Conversation

rolfbjarne
Copy link
Member

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:

<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 #16193.

…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.
@rolfbjarne rolfbjarne added the bug If an issue is a bug or a pull request a bug fix label Oct 10, 2022
@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2
Copy link
Collaborator

🔥 [PR Build] Build failed 🔥

Build failed for the job 'Detect API changes'

Pipeline on Agent
Hash: [PR build]

@vs-mobiletools-engineering-service2
Copy link
Collaborator

🔥 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
Hash: 7ee68aae65c372d5da6450df26a0756be7f0eb06 [PR build]

@vs-mobiletools-engineering-service2
Copy link
Collaborator

📚 [PR Build] Artifacts 📚

Packages generated

View packages

Pipeline on Agent XAMBOT-1043.Monterey'
Hash: 7ee68aae65c372d5da6450df26a0756be7f0eb06 [PR build]

@vs-mobiletools-engineering-service2
Copy link
Collaborator

💻 [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
Hash: 7ee68aae65c372d5da6450df26a0756be7f0eb06 [PR build]

@vs-mobiletools-engineering-service2
Copy link
Collaborator

🚀 [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
✅ cecil: All 1 tests passed. Html Report (VSDrops) Download
✅ dotnettests: All 1 tests passed. Html Report (VSDrops) Download
✅ fsharp: All 7 tests passed. Html Report (VSDrops) Download
✅ framework: All 8 tests passed. Html Report (VSDrops) Download
✅ generator: All 2 tests passed. Html Report (VSDrops) Download
✅ interdependent_binding_projects: All 7 tests passed. Html Report (VSDrops) Download
✅ install_source: All 1 tests passed. Html Report (VSDrops) Download
✅ introspection: All 8 tests passed. Html Report (VSDrops) Download
✅ linker: All 65 tests passed. Html Report (VSDrops) Download
✅ mac_binding_project: All 1 tests passed. Html Report (VSDrops) Download
✅ mmp: All 2 tests passed. Html Report (VSDrops) Download
✅ mononative: All 12 tests passed. Html Report (VSDrops) Download
✅ monotouch: All 23 tests passed. Html Report (VSDrops) Download
✅ msbuild: All 2 tests passed. Html Report (VSDrops) Download
✅ mtouch: All 1 tests passed. Html Report (VSDrops) Download
✅ xammac: All 3 tests passed. Html Report (VSDrops) Download
✅ xcframework: All 8 tests passed. Html Report (VSDrops) Download
✅ xtro: All 2 tests passed. Html Report (VSDrops) Download

Pipeline on Agent
Hash: [PR build]

@rolfbjarne rolfbjarne merged commit 9e3dbf2 into dotnet:main Oct 10, 2022
@rolfbjarne rolfbjarne deleted the issue-16193 branch October 10, 2022 19:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug If an issue is a bug or a pull request a bug fix
Projects
None yet
5 participants