Wrong-TFM assembly loading, producing empty .jlo.xml files (0 JCW types)

[qjustfeelitp]

Android framework version

net10.0-android

Affected platform version

VS 18.3.0, .NET 10.0.103

Description

When a solution contains multi-TFM projects (e.g. a MAUI library targeting net10.0 or just plain business logic shared library) referenced by an Android app project, the build tasks can load wrong-TFM assemblies from CopyLocal'd copies in non-Android output directories. This causes FindJavaObjectsStep to report "Found 0 Java types" for affected assemblies, producing empty .jlo.xml files and no JCW generation. At runtime, this results in No java peer type found for XYZ exceptions.

In previous versions this used to work, I have spend a week trying to fix it.

Steps to Reproduce

App.Droid (net10.0-android) → references Core
App.Core (net10.0) → references LibA
CompanyName.Mobile.Common (net10.0 + net10.0-android) → contains Java-interop types (e.g. IHostnameVerifier impl, BroadcastReceiver etc.)

Reproduction code can be found here: https://github.com/qjustfeelitp/dotnet.android.NoJavaPeer

there are three branches

master is the current behaviour
net9 to show how it used to behave and that it works there
workaround contains the MSBuild target to fix it in net10

I have tried to keep it simple and as close to what we actually use.

Did you find any workaround?

Add this to the main droid project

<_AndroidTfmResolvedAssemblies Include="@(_AllResolvedAssemblies)"
Condition="$([System.String]::new('%(Identity)').Contains('-android'))" />
<_NonAndroidTfmResolvedAssemblies Include="@(_AllResolvedAssemblies)"
Condition="!$([System.String]::new('%(Identity)').Contains('-android'))" />
<_AllResolvedAssemblies Remove="@(_AllResolvedAssemblies)" />
<_AllResolvedAssemblies Include="@(_AndroidTfmResolvedAssemblies)" />
<_AllResolvedAssemblies Include="@(_NonAndroidTfmResolvedAssemblies)" />
<_AndroidTfmResolvedAssemblies Remove="@(_AndroidTfmResolvedAssemblies)" />
<_NonAndroidTfmResolvedAssemblies Remove="@(_NonAndroidTfmResolvedAssemblies)" />

Relevant log output

exception:
Cannot create instance of type 'CompanyName.Mobile.Common.UsbAttachedReceiver': no Java peer type found.


stack trace:

at Java.Interop.JniPeerMembers.JniInstanceMethods..ctor(Type declaringType)
   at Java.Interop.JniPeerMembers.JniInstanceMethods.GetConstructorsForType(Type declaringType)
   at Java.Interop.JniPeerMembers.JniInstanceMethods.StartCreateInstance(String constructorSignature, Type declaringType, JniArgumentValue* parameters)
   at Android.Content.BroadcastReceiver..ctor()
   at CompanyName.Mobile.Common.UsbAttachedReceiver..ctor(Action onUsbAttached) in C:\Users\XXX\source\repos\App.Droid\CompanyName.Mobile.Common\UsbAttachedReceiver.android.cs:line 11
   at App.Droid.MainActivity.OnCreate(Bundle savedInstanceState) in C:\Users\XXX\source\repos\App.Droid\App.Droid\MainActivity.cs:line 19
   at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_(IntPtr jnienv, IntPtr native__this, IntPtr native_savedInstanceState)

[jonathanpeppers]

In previous versions this used to work, I have spend a week trying to fix it.

Do you know what version used to work? .NET 9?

[qjustfeelitp]

In previous versions this used to work, I have spend a week trying to fix it.

Do you know what version used to work? .NET 9?

Since unified dotnet that means from net6. Only android has these problems, ios and windows are fine.

[jonathanpeppers]

Well, but the .jlo.xml files were introduced only in .NET 10.

[qjustfeelitp]

Ok, then how is it supposed to work? I mean if multitargeting is supported then the correct tfm should correctly go from top to bottom, no?

[jonathanpeppers]

I'm asking when you think this regressed.

Is the answer .NET 6?

[qjustfeelitp]

No. I apologize if my writing is confusing. Since net6 and maui came to fruition we moved our codebase there and followed the multitargeting best practices. Thanks to this we could shrink the codebase and simplify our builds.

Right now I upgraded everything to net10 with this situation in front of me. I applied the workaround that I presented to you and everything is fine.

But I would really like not to be applying these types of things therefore I started this issue.

So from net6 to net9 everything is fine. Net10 is broken.

[qjustfeelitp]

If the title or description of this issue is wrong or misleading, can you edit it so that it makes sense? 😄

If the .jlo.xml files were introduced in net10, their generation should respect the previous behaviour and correctly use the TFM.

[qjustfeelitp]

I had a suspicion that there is some alphabetical order, and updated the reproduction repository that confirms it. You can find the corresponding in branch called net10-alphabetical where the first receiver from assembly that alphabetically preceeds the rest can be correctly instantiated.