-
Notifications
You must be signed in to change notification settings - Fork 528
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
[One .NET] specify all RIDs by default #6398
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dellis1972
approved these changes
Oct 18, 2021
I think moving to 4 RIDs has triggered a problem on Windows:
Let me look into this. |
jonathanpeppers
force-pushed
the
dotnet-all-rids
branch
from
October 18, 2021 20:18
19233d9
to
8b76acd
Compare
Another related error:
|
Fixes: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1413756 Fixes: dotnet#6353 The API 31 emulator no longer has 32-bit images and the x86_64 image has dropped support for 32-bit architectures: > adb shell getprop | grep cpu [ro.product.cpu.abi]: [x86_64] [ro.product.cpu.abilist]: [x86_64,arm64-v8a] [ro.product.cpu.abilist32]: [] [ro.product.cpu.abilist64]: [x86_64,arm64-v8a] Compared to an API 30 x86_64 emulator: > adb shell getprop | grep cpu [ro.product.cpu.abi]: [x86_64] [ro.product.cpu.abilist]: [x86_64,x86,arm64-v8a,armeabi-v7a,armeabi] [ro.product.cpu.abilist32]: [x86,armeabi-v7a,armeabi] [ro.product.cpu.abilist64]: [x86_64,arm64-v8a] The problem is our default RIDs are: <RuntimeIdentifiers Condition=" '$(RuntimeIdentifier)' == '' And '$(RuntimeIdentifiers)' == '' ">android-arm64;android-x86</RuntimeIdentifiers> And so you hit this error when trying to deploy a `dotnet new android` app on an API 31 x86_64 emulator: error ADB0020: Mono.AndroidTools.IncompatibleCpuAbiExceptiopn: The package does not support the CPU architecture of this device. To workaround this, you can add `android-x64` to your list of `$(RuntimeIdentifiers)`. To solve this issue, we can default `$(RuntimeIdentifiers)` to all 4 architectures. We have code that will select a single architecture for Debug builds using "Fast Deployment". It seems better to have a default here that will always work, and the only drawback would be the additional architectures for Release builds. After this change, I discovered an issue introduced in 33a6d1e: ILLink error IL1012: IL Linker has encountered an unexpected error. Please report the issue at https://github.com/mono/linker/issues [C:\a\_work\1\s\bin\TestRelease\temp\BuildProguard Enabled Project(1)Trued8r8\UnnamedProject.csproj] ... Unhandled exception. System.IO.IOException: The process cannot access the file 'C:\a\_work\1\s\bin\TestRelease\temp\BuildProguard Enabled Project(1)Trued8r8\obj\Release\proguard\proguard_project_references.cfg' because it is being used by another process. When we build each RID in parallel, each inner build was attempting to write to the same file. I changed the path for this file to be: $(IntermediateOutputPath)%(_RIDs.Identity)\proguard\proguard_project_references.cfg And then set `$(_ProguardProjectConfiguration)` appropriately after the inner builds complete. This also needs to actually be a file path, I don't see how the value was working before: <_ProguardProjectConfiguration Condition=" '$(AndroidLinkTool)' != '' ">;_ProguardProjectConfiguration=$(IntermediateOutputPath)proguard\proguard_project_references.cfg</_ProguardProjectConfiguration> Then another related issue: (_TouchAndroidLinkFlag target) -> Microsoft.Android.Sdk.ILLink.targets(114,5): error MSB3371: The file "obj\Release\net6.0-android\link.flag" cannot be created. The process cannot access the file 'C:\a\_work\2\s\bin\TestRelease\temp\DotNetBuildandroid-armandroid-arm64android-x86android-x64TrueTrue\obj\Release\net6.0-android\link.flag' because it is being used by another process. I setup `$(_AndroidLinkFlag)` the same as `$(_ProguardProjectConfiguration)` to solve this issue.
jonathanpeppers
force-pushed
the
dotnet-all-rids
branch
from
October 19, 2021 15:05
8b76acd
to
8ea1708
Compare
dellis1972
approved these changes
Oct 19, 2021
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1413756
Fixes: #6353
The API 31 emulator no longer has 32-bit images and the x86_64 image
has dropped support for 32-bit architectures:
Compared to an API 30 x86_64 emulator:
The problem is our default RIDs are:
And so you hit this error when trying to deploy a
dotnet new android
app on an API 31 x86_64 emulator:
To workaround this, you can add
android-x64
to your list of$(RuntimeIdentifiers)
.To solve this issue, we can default
$(RuntimeIdentifiers)
to all 4architectures. We have code that will select a single architecture for
Debug builds using "Fast Deployment". It seems better to have a
default here that will always work, and the only drawback would be the
additional architectures for Release builds.
After this change, I discovered an issue introduced in 33a6d1e:
When we build each RID in parallel, each inner build was attempting to
write to the same file. I changed the path for this file to be:
And then set
$(_ProguardProjectConfiguration)
appropriately afterthe inner builds complete. This also needs to actually be a file path,
I don't see how the value was working before:
Then another related issue:
I setup
$(_AndroidLinkFlag)
the same as$(_ProguardProjectConfiguration)
to solve this issue.