-
Notifications
You must be signed in to change notification settings - Fork 520
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
Unable to use maccatalyst binding library, getting Could not create an native instance of the type 'WindowsAzure.Messaging.SBNotificationHub': the native class hasn't been loaded. #17347
Comments
As a temporary workaround, try adding the following to the csproj: <PropertyGroup>
<MtouchExtraArgs>--registrar:static</MtouchExtraArgs>
</PropertyGroup> now I get this exception:
which seems to be because the connection string is invalid. |
@rolfbjarne it works now, thank you! |
Reopening since there's an actual bug here on our side. |
The bug manifests like this: > Could not create an native instance of the type WindowsAzure.Messaging.SBNotificationHub: the native class hasn't been loaded. which happens because the SBNotificationHub doesn't exist in the final executable. We asked the linker to link with the static library containing this type, but the linker didn't link with the library because it didn't need any of the symbols in it. We should have collected all the exported Objective-C types from this library and asked the native linker to keep them, but that didn't happen because: 1. We collect bound Objective-C classes from binding libraries here (the ListExportedSymbolsStep): https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/linker/MonoTouch.Tuner/ListExportedSymbols.cs#L148-L157 2. That only happens for attributes with a LinkWith attribute. * We compute if an assembly has a LinkWith attribute here: https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/common/Assembly.cs#L266 * Which is called from here: https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/common/Assembly.cs#L198 * Which is called from here (the ExtractBindingLibrariesStep): https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/dotnet-linker/Steps/ExtractBindingLibrariesStep.cs#L18 Now, we must obviously compute if an assembly has a LinkWith attribute before doing anything that depends on that value, but we weren't doing things in that order. Changing the custom linker steps to run the ListExportedSymbols step *after* the ExtractBindingLibrariesStep fixes this logic problem. Fixes dotnet#17347.
The bug manifests like this: > Could not create an native instance of the type WindowsAzure.Messaging.SBNotificationHub: the native class hasn't been loaded. which happens because the SBNotificationHub doesn't exist in the final executable. We asked the linker to link with the static library containing this type, but the linker didn't link with the library because it didn't need any of the symbols in it. We should have collected all the exported Objective-C types from this library and asked the native linker to keep them, but that didn't happen because: 1. We collect bound Objective-C classes from binding libraries here (the ListExportedSymbolsStep): https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/linker/MonoTouch.Tuner/ListExportedSymbols.cs#L148-L157 2. That only happens for attributes with a LinkWith attribute. * We compute if an assembly has a LinkWith attribute here: https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/common/Assembly.cs#L266 * Which is called from here: https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/common/Assembly.cs#L198 * Which is called from here (the ExtractBindingLibrariesStep): https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/dotnet-linker/Steps/ExtractBindingLibrariesStep.cs#L18 Now, we must obviously compute if an assembly has a LinkWith attribute before doing anything that depends on that value, but we weren't doing things in that order. Changing the custom linker steps to run the ListExportedSymbols step *after* the ExtractBindingLibrariesStep fixes this logic problem. Fixes dotnet#17347.
The bug manifests like this: > Could not create an native instance of the type WindowsAzure.Messaging.SBNotificationHub: the native class hasn't been loaded. which happens because the SBNotificationHub doesn't exist in the final executable. We asked the linker to link with the static library containing this type, but the linker didn't link with the library because it didn't need any of the symbols in it. We should have collected all the exported Objective-C types from this library and asked the native linker to keep them, but that didn't happen because: 1. We collect bound Objective-C classes from binding libraries here (the ListExportedSymbolsStep): https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/linker/MonoTouch.Tuner/ListExportedSymbols.cs#L148-L157 2. That only happens for attributes with a LinkWith attribute. * We compute if an assembly has a LinkWith attribute here: https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/common/Assembly.cs#L266 * Which is called from here: https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/common/Assembly.cs#L198 * Which is called from here (the ExtractBindingLibrariesStep): https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/dotnet-linker/Steps/ExtractBindingLibrariesStep.cs#L18 Now, we must obviously compute if an assembly has a LinkWith attribute before doing anything that depends on that value, but we weren't doing things in that order. Changing the custom linker steps to run the ListExportedSymbols step *after* the ExtractBindingLibrariesStep fixes this logic problem. Fixes #17347.
I'm trying to create binding library for azure-notificationhubs-ios framework (https://github.com/Azure/azure-notificationhubs-ios/releases). Framework supports both ios and maccatalyst
net7.0-ios project is working good
net7.0-maccataltyst crashes during runtime with "Could not create an native instance of the type 'WindowsAzure.Messaging.SBNotificationHub': the native class hasn't been loaded."
I tried referencing the WindowsAzureMessaging.xcframework, and also maccatalyst's framework from WindowsAzureMessaging.xcframework\ios-arm64_x86_64-maccatalyst\WindowsAzureMessaging.framework but sill got the same error
Steps to Reproduce
Expected Behavior
applications runs, creates SBNotificationHub instance on line
var hub = new WindowsAzure.Messaging.SBNotificationHub("123", "456");
Actual Behavior
application crashes with the following exception:
Could not create an native instance of the type WindowsAzure.Messaging.SBNotificationHub: the native class hasn't been loaded. It is possible to ignore this condition by setting ObjCRuntime.Class.ThrowOnInitFailure to false.
Environment
Version information
Example Project
sample project.zip
The text was updated successfully, but these errors were encountered: