[net7-rc2] Building an app in Release configuration reports incorrect duplicate types #7473

jeromelaban · 2022-10-20T01:15:38Z

Android application type

Android for .NET (net6.0-android, etc.)

Affected platform version

net7.0-rc2

Description

Building a net6.0-android app in Release configuration causes the following errors:

C:\hostedtoolcache\windows\dotnet\packs\Microsoft.Android.Sdk.Windows\32.0.476\tools\Xamarin.Android.Common.targets(1438,3): 
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]

then java-related errors:

C:\hostedtoolcache\windows\dotnet\packs\Microsoft.Android.Sdk.Windows\32.0.476\tools\Xamarin.Android.Common.targets(1438,3): 
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]

Steps to Reproduce

dotnet new install Uno.ProjectTemplates.Dotnet
dotnet new unoapp -o testapp
cd testapp\testapp.Mobile
dotnet build -f net6.0-android -c Release

Notice a very large number of errors after the AOT step:

C:\hostedtoolcache\windows\dotnet\packs\Microsoft.Android.Sdk.Windows\32.0.476\tools\Xamarin.Android.Common.targets(1438,3): 
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]

then java-related errors:

C:\hostedtoolcache\windows\dotnet\packs\Microsoft.Android.Sdk.Windows\32.0.476\tools\Xamarin.Android.Common.targets(1438,3): 
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]

Did you find any workaround?

No, bumping to net7.0-android did not fix the issue. Considering the number of times the duplicate assembly is found, this would look like the number of target CPU architectures ?

Relevant log output

msbuild.zip

The text was updated successfully, but these errors were encountered:

jeromelaban · 2022-10-20T01:19:17Z

Update: Building with -p:RuntimeIdentifier=android-arm64 makes the error go away, but only builds for one CPU architecture.

dellis1972 · 2022-10-20T13:50:01Z

We probably need to add some additional logic to check for assemblies in the different runtime directories.

jeromelaban · 2022-10-20T14:01:36Z

@dellis1972 would you know of a possible workaround for this (even if it means changing the targets files) ?

dellis1972 · 2022-10-20T14:15:31Z

@jeromelaban the check is done within the Task GenerateJavaStubs. https://github.com/xamarin/xamarin-android/blob/main/src/Xamarin.Android.Build.Tasks/Tasks/GenerateJavaStubs.cs#L191

The problem is GenerateJavaStubs is getting ALL of the assemblies for each RuntimeIdentifier. So we end up with 4 entires for Uno.UI etc and others.

I guess you could write a target which runs just before the _GenerateJavaStubs target which will remove those duplicates from @(_ResolvedAssemblies) and @(_ResolvedUserMonoAndroidAssemblies) .. but I'm not sure how that would effect the packaging as those same ItemGroups are used to package the final app. https://github.com/xamarin/xamarin-android/blob/main/src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets#L1477

You might be able to add a filter to that target locally and make copies of those ItemGroups which you then pass to GenerateJavaStubs. (effectively replacing the @(_ResolvedAssemblies) and @(_ResolvedUserMonoAndroidAssemblies) for that target, but leaving those ItemGroups intack for the other targets.

… 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.

lukasf · 2022-11-08T21:25:52Z

I just installed the latest official Uno version and .NET 7 RTM, and I cannot compile Android as Release (empty app from template). This issue should have top priority.

dellis1972 · 2022-11-09T10:06:04Z

@jeromelaban @lukasf we have a PR in progress which I think will work. However, what is blocking is a good unit test. I have been unable to replicate the envionment in a standard android app which does not rely on other external sources.

Do you have any idea what Uno in particular is doing which might cause this issue? Is there something specific which the Uno.UI assembly has which results it in having a per abi assembly? Then I might be able to replicate that behaviour in a standard anroid app.

dellis1972 · 2022-11-09T11:17:09Z

ok I think I've managed to cobble together an managed android example. I'll try and convert that to a unit test.

jeromelaban · 2022-11-09T12:30:51Z

@dellis1972 I do not think we're doing anything RID specific in Uno (the binary is the same for all net6.0-android and net7.0-android). Have you found out what the difference is? I'm very curious :)

dellis1972 · 2022-11-09T14:57:02Z

@dellis1972 I do not think we're doing anything RID specific in Uno (the binary is the same for all net6.0-android and net7.0-android). Have you found out what the difference is? I'm very curious :)

I haven't found a difference yet. But I did manage to repo in a basic android app just by adding a reference to Uno.WinUI. So I'm hoping I can at least convert that project into a unit test so I can test the fix in the PR.

jeromelaban · 2022-11-09T15:21:18Z

@dellis1972 Could it be a linker option that causes this? But even then, there's no RID specific changes here, unless the runtime has content that is removed or altered there with some internal dependency on the BCL?

dellis1972 · 2022-11-09T15:31:43Z

@jeromelaban so I just did a diff of the IL produced between the android-arm/Uno.UI.dll and the android-arm64/Uno.UI.dll and got this

diff arm.il arm64.il 
4686c4686
< // MVID: {16515C9E-2BDA-4300-AAB3-EBE9BE5FF5F5}
---
> // MVID: {B51D27AA-5ED2-4FC1-A974-FD6D86D4ED29}
121459c121459
<     IL_0000:  ldc.i4     0x4
---
>     IL_0000:  ldc.i4     0x8

So it looks like there is a difference between these two. It also means the fix I was hoping would work, wont. Since the MVID's are different.

dellis1972 · 2022-11-09T15:37:46Z

I would guess that is caused by https://github.com/unoplatform/uno/blob/bd2789df8f9a2014dacff88751dfe20117b5fa6b/src/Uno.UI/UI/Xaml/SpecializedResourceDictionary.cs#L118

dellis1972 · 2022-11-09T15:40:37Z

Hmm. But that looks like its always included even on x86 based assemblies.

dellis1972 · 2022-11-09T15:53:07Z

@jeromelaban just out of curiosity does using AndroidLinkSkip=Uno.UI work around the issue for now?
It seems the 64bit support is throwing off the .net linker and its producing 4 files when it really only needs one.

jeromelaban · 2022-11-09T19:00:28Z

I tried with the following, but it produces the same result:

dotnet build -f net7.0-android -c Release /p:AotAssemblies=true /p:AndroidLinkSkip=Uno.UI

liveinvarun · 2022-11-14T22:24:51Z

When i build the application that targets .net 7 on pipeline i get following error.
Targets are only .net7-android and .net7-ios.
@jonathanpeppers @dellis1972

error XA4215: The Java type crc643f2b18b2570eaa5a.PlatformGraphicsView is generated by more than one managed type. Please change the [Register] attribute so that the same Java type is not emitted. [D:\a\1\s\src\App\App.Application\App.App.csproj::TargetFramework=net7.0-android]

C:\hostedtoolcache\windows\dotnet\packs\Microsoft.Android.Sdk.Windows\33.0.4\tools\Xamarin.Android.Common.targets(1476,3): error XA4215: crc643f2b18b2570eaa5a.PlatformGraphicsView generated by: Microsoft.Maui.Graphics.Platform.PlatformGraphicsView, Microsoft.Maui.Graphics, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null [D:\a\1\s\src\App\App.Application\App.App.csproj::TargetFramework=net7.0-android]

C:\hostedtoolcache\windows\dotnet\packs\Microsoft.Android.Sdk.Windows\33.0.4\tools\Xamarin.Android.Common.targets(1476,3): error XA4215:

… 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.

liveinvarun · 2022-11-28T06:34:38Z

@dellis1972 Any update on when this will be fixed. Currently the release build is broken when we target .net7 based workloads for android.

dellis1972 · 2022-11-28T10:30:59Z

We have a fix (see #7477) just having issues getting the unit tests green so it can be merged.

… 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.

…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.

jeromelaban · 2022-11-29T17:02:30Z

🚀🚀 Thanks for the work on fixing this issue!

…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.

jeromelaban · 2022-12-15T03:23:35Z

@jonpryor Would you know when this update will be released? It does not seem to be part of an SR1 update (only iOS and macOS were updated, for what I could see). Thanks!

jonathanpeppers · 2022-12-15T03:34:41Z

This fixed missed the cutoff date but should be in the next one.

The .NET 7 release branch is: https://github.com/xamarin/xamarin-android/tree/release/7.0.1xx

queequac · 2023-01-10T20:31:37Z

Obviously also not fixed in today's VS 17.4.4 release. :(

jeromelaban · 2023-01-19T21:29:50Z

Fixed in 17.5 Preview 3!

jonathanpeppers · 2023-01-19T21:46:50Z

You also should be able to run dotnet workload update. This will also be in 17.5 GA.

queequac · 2023-02-02T20:59:14Z

With updated workloads and Uno 4.7.37 it finally works even in VS17.4.4. I am able to publish targeting .net7 with AOT enabled. 😄

jeromelaban added Area: App+Library Build Issues when building Library projects or Application projects. needs-triage Issues that need to be assigned. labels Oct 20, 2022

jeromelaban assigned dellis1972 and jonathanpeppers Oct 20, 2022

dellis1972 removed the needs-triage Issues that need to be assigned. label Oct 20, 2022

dellis1972 mentioned this issue Oct 20, 2022

[Xamarin.Android.Build.Tasks] Don't report duplicate type if the AssemblyName is the same. #7477

Merged

jeromelaban mentioned this issue Nov 9, 2022

fix: Switch template to default to net7.0 unoplatform/uno#10371

Closed

6 tasks

jonpryor closed this as completed in #7477 Nov 29, 2022

jeromelaban mentioned this issue Dec 13, 2022

WinUI Android : Release build is flooded with "_x_ is generated by more than one managed type" errors unoplatform/uno#10722

Closed

jeromelaban mentioned this issue Jan 24, 2023

[net7] System.NotSupportedException: no Java peer type found #7736

Closed

ghost locked as resolved and limited conversation to collaborators Mar 5, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[net7-rc2] Building an app in Release configuration reports incorrect duplicate types #7473

[net7-rc2] Building an app in Release configuration reports incorrect duplicate types #7473

jeromelaban commented Oct 20, 2022 •

edited

Loading

jeromelaban commented Oct 20, 2022

dellis1972 commented Oct 20, 2022

jeromelaban commented Oct 20, 2022

dellis1972 commented Oct 20, 2022 •

edited

Loading

lukasf commented Nov 8, 2022

dellis1972 commented Nov 9, 2022

dellis1972 commented Nov 9, 2022

jeromelaban commented Nov 9, 2022

dellis1972 commented Nov 9, 2022

jeromelaban commented Nov 9, 2022

dellis1972 commented Nov 9, 2022

dellis1972 commented Nov 9, 2022

dellis1972 commented Nov 9, 2022

dellis1972 commented Nov 9, 2022

jeromelaban commented Nov 9, 2022

liveinvarun commented Nov 14, 2022 •

edited

Loading

liveinvarun commented Nov 28, 2022

dellis1972 commented Nov 28, 2022

jeromelaban commented Nov 29, 2022

jeromelaban commented Dec 15, 2022

jonathanpeppers commented Dec 15, 2022

queequac commented Jan 10, 2023

jeromelaban commented Jan 19, 2023

jonathanpeppers commented Jan 19, 2023

queequac commented Feb 2, 2023

[net7-rc2] Building an app in Release configuration reports incorrect duplicate types #7473

[net7-rc2] Building an app in Release configuration reports incorrect duplicate types #7473

Comments

jeromelaban commented Oct 20, 2022 • edited Loading

Android application type

Affected platform version

Description

Steps to Reproduce

Did you find any workaround?

Relevant log output

jeromelaban commented Oct 20, 2022

dellis1972 commented Oct 20, 2022

jeromelaban commented Oct 20, 2022

dellis1972 commented Oct 20, 2022 • edited Loading

lukasf commented Nov 8, 2022

dellis1972 commented Nov 9, 2022

dellis1972 commented Nov 9, 2022

jeromelaban commented Nov 9, 2022

dellis1972 commented Nov 9, 2022

jeromelaban commented Nov 9, 2022

dellis1972 commented Nov 9, 2022

dellis1972 commented Nov 9, 2022

dellis1972 commented Nov 9, 2022

dellis1972 commented Nov 9, 2022

jeromelaban commented Nov 9, 2022

liveinvarun commented Nov 14, 2022 • edited Loading

liveinvarun commented Nov 28, 2022

dellis1972 commented Nov 28, 2022

jeromelaban commented Nov 29, 2022

jeromelaban commented Dec 15, 2022

jonathanpeppers commented Dec 15, 2022

queequac commented Jan 10, 2023

jeromelaban commented Jan 19, 2023

jonathanpeppers commented Jan 19, 2023

queequac commented Feb 2, 2023

jeromelaban commented Oct 20, 2022 •

edited

Loading

dellis1972 commented Oct 20, 2022 •

edited

Loading

liveinvarun commented Nov 14, 2022 •

edited

Loading