[net6][iOS][Catalyst] Using Xamarin.iOS binaries can lead to Can't register the class XX when the dynamic registrar has been linked away.

[jeromelaban]

Steps to Reproduce

1. Create an application which uses an assembly or nuget package built for xamarinios10
2. Instantiate a class which has the [Register(...)] attribute defined

Expected Behavior

Not sure what the expected should be, since other APIs may break, but a build-time error or warning would be useful.

Actual Behavior

Can't register the class XXX when the dynamic registrar has been linked away.

Adding --optimize=-remove-dynamic-registrar kind of helps, but other issues may arise with iOS APIs breaking changes.

Environment

.NET 6 Mobile RC2

Build Logs

On demand.

[spouliot]

IMO that should be a bidirectional build error.

• a legacy app should not have any references to Microsoft.[iOS|tvOS|macOS|MacCatalyst].dll platform assembly; and
• a net6 app should not any references to Xamarin.[iOS|Mac|TVOS|Watch].dll

[rolfbjarne]

This is not expected to work at all, but you're right that an error message at build time would be helpful.

1. NuGet: this should be an error. It used to be a warning (before we did any breaking changes), but it was changed to be an error here: [DCR]: Adjust compatibility rules for Apple TFMs in .NET  NuGet/Home#11338. I'm unsure which version contains this change though, we might still be using an older version of the nuget logic, since I get this warning if I try:

    warning NU1701: Package 'MonoTouch.Dialog 2.0.0-pre1' was restored using 'Xamarin.iOS,Version=v1.0, .NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework 'net6.0-ios15.4'. This package may not be fully compatible with your project.
   

2. If you manually reference an assembly you're kind of on your own (this is pretty standard: you can reference a library built with .NET 6 in a project built with .NET 5, and it'll build just fine, but it may or may not blow up at runtime). That said, we could add extra logic that detects this particular scenario, at the cost of slowing down the build a little bit for everybody.

I'm setting the milestone to .NET 7, because it's too late to fix/improve this for the upcoming stable release, so I'm leaning towards waiting and see how this affects people trying to upgrade.

If it turns out a lot of people struggle with this, then we can always change our mind and fix it before .NET 7 (or also decide to not do it at all).

[rolfbjarne]

Nobody seems to have run into the same problem (and in any case any build errors should be obvious that), so I'm closing this since it doesn't look like we need to do anything else here.