[Xamarin.Android.Build.Tasks] Don't report duplicate type if the AssemblyName is the same.#7477
Merged
jonpryor merged 5 commits intodotnet:mainfrom Nov 29, 2022
Merged
Conversation
|
@dellis1972 Would you know if this fix going to make it for 7.0.100? |
Contributor
Author
|
@jeromelaban sorry, I got distracted with some other stuff and forgot about this one. I'm not sure if I've missed the 7.0.100 cut off or not. @jonpryor any ideas when the cut off is? |
grendello
approved these changes
Nov 2, 2022
Contributor
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
jonathanpeppers
approved these changes
Nov 2, 2022
d7ed3e4 to
3269d04
Compare
Contributor
|
As per https://discord.com/channels/732297728826277939/732297837953679412/1039930020170313921 , this approach may not work at all, because the MVID does change; it's just that it's per-ABI.. I think we need to update |
Contributor
Author
|
@jonpryor i reworked this to compage the module name. This stops the error being genereated. |
jonathanpeppers
approved these changes
Nov 10, 2022
ad81d7e to
cba760c
Compare
Contributor
|
This should be able to land for MAUI SR1. |
jonpryor
reviewed
Nov 16, 2022
src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/Tasks/LinkerTests.cs
Outdated
Show resolved
Hide resolved
Contributor
|
Commit message for review: Fixes: https://github.com/xamarin/xamarin-android/issues/7473
Context: https://github.com/xamarin/monodroid/commit/4c697e5a6b
Context: https://github.com/dotnet/runtime/blob/27c19c31f574375fd1651207b2dc28d39fe1225c/src/libraries/System.Private.CoreLib/src/ILLink/ILLink.Substitutions.64bit.xml
With the .NET 6+ build system, it is possible for an AnyCPU assembly
to become a *set* of assemblies, one per `$(RuntimeIdentifiers)`
value.
In particular, the linker will now *inline* calls to
`System.IntPtr.get_Size()`, replacing them with the appropriate
architecture-specific value. This means that a single assembly that
uses the `IntPtr.Size` property could become *4* assemblies, one each
for android-arm, android-arm64, android-x86, and android-x64.
Furthermore, each of these assemblies will have a different MVID.
This is "fine", until the assembly contains a `Java.Lang.Object`
subclass that needs a Java Callable Wrapper generated for it, at
which point the `<GenerateJavaStubs/>` task starts emitting XA4214
warnings and XA4215 *errors*:
warning XA4214: The managed type `Microsoft.UI.Xaml.Controls.AnimatedIcon` exists
in multiple assemblies: Uno.UI, Uno.UI, Uno.UI, Uno.UI.
Please refactor the managed type names in these assemblies so that they are not identical.
error XA4215: The Java type `crc64a5a37c43dff01024.GridViewHeaderItem` is generated by more than
one managed type. Please change the [Register] attribute so that the same Java type is not emitted.
**Workaround**: Build with only a single `$(RuntimeIdentifier)`:
dotnet build -p:RuntimeIdentifier=android-arm64 …
Fix this scenario by updating the XA4214 warning and XA4215 error
checks to verify that the module name has changed; if the module name
is the same, then it's not a duplicate type. |
bc54e9c to
bb7c21d
Compare
… is the same. Fixes dotnet#7473 With the new build system under `dotnet` we can end up with duplicate assemblies for different `RuntimeIdentifiers`. This can cause the `GenerateJavaStubs` task to mistakenly report duplicate types. ``` warning XA4214: The managed type `Microsoft.UI.Xaml.Controls.AnimatedIcon` exists in multiple assemblies: Uno.UI, Uno.UI, Uno.UI, Uno.UI. Please refactor the managed type names in these assemblies so that they are not identical. [C:\a\1\s\UnoAppAll\UnoAppAll.Mobile\UnoAppAll.Mobile.csproj::TargetFramework=net6.0-android] error XA4215: The Java type `crc64a5a37c43dff01024.GridViewHeaderItem` is generated by more than one managed type. Please change the [Register] attribute so that the same Java type is not emitted. [C:\a\1\s\UnoAppAll\UnoAppAll.Mobile\UnoAppAll.Mobile.csproj::TargetFramework=net6.0-android] ``` We should ignore these duplicates is the `mvid` of the the type module is the same. If it is then they will be from the same assembly.
bb7c21d to
10e8379
Compare
jonathanpeppers
pushed a commit
that referenced
this pull request
Nov 30, 2022
…7477) Fixes: #7473 Context: xamarin/monodroid@4c697e5a6b Context: https://github.com/dotnet/runtime/blob/27c19c31f574375fd1651207b2dc28d39fe1225c/src/libraries/System.Private.CoreLib/src/ILLink/ILLink.Substitutions.64bit.xml With the .NET 6+ build system, it is possible for an AnyCPU assembly to become a *set* of assemblies, one per `$(RuntimeIdentifiers)` value. In particular, the linker will now *inline* calls to `System.IntPtr.get_Size()`, replacing them with the appropriate architecture-specific value. This means that a single assembly that uses the `IntPtr.Size` property could become *4* assemblies, one each for android-arm, android-arm64, android-x86, and android-x64. Furthermore, each of these assemblies will have a different MVID. This is "fine", until the assembly contains a `Java.Lang.Object` subclass that needs a Java Callable Wrapper generated for it, at which point the `<GenerateJavaStubs/>` task starts emitting XA4214 warnings and XA4215 *errors*: warning XA4214: The managed type `Microsoft.UI.Xaml.Controls.AnimatedIcon` exists in multiple assemblies: Uno.UI, Uno.UI, Uno.UI, Uno.UI. Please refactor the managed type names in these assemblies so that they are not identical. error XA4215: The Java type `crc64a5a37c43dff01024.GridViewHeaderItem` is generated by more than one managed type. Please change the [Register] attribute so that the same Java type is not emitted. **Workaround**: Build with only a single `$(RuntimeIdentifier)`: dotnet build -p:RuntimeIdentifier=android-arm64 … Fix this scenario by updating the XA4214 warning and XA4215 error checks to verify that the module name has changed; if the module name is the same, then it's not a duplicate type.
grendello
added a commit
to grendello/xamarin-android
that referenced
this pull request
Nov 30, 2022
* main: [tests] Add nightly localization unit tests (dotnet#6693) [Xamarin.Android.Build.Tasks] Fix XA4215 if AssemblyName is the same (dotnet#7477) Bump to dotnet/installer@24f5950 8.0.100-alpha.1.22577.1 (dotnet#7585) Bump manifest-merger from 30.3.0 to 30.3.1 in /src/manifestmerger (dotnet#7467)
This file contains hidden or 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
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 #7473
With the new build system under
dotnetwe can end up with duplicate assemblies for differentRuntimeIdentifiers. This can cause theGenerateJavaStubstask to mistakenly report duplicate types.We should ignore these duplicates if the name of the the type module is the same. If it is then they will be from the same assembly. We cannot use the
mvidsince that also changes.