Skip to content
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

Closed
marekdovjak opened this issue Jan 23, 2023 · 3 comments · Fixed by #17360
Labels
binding-projects Issue or PR that affects binding projects bug If an issue is a bug or a pull request a bug fix
Milestone

Comments

@marekdovjak
Copy link

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

  1. Extract attached zip file
  2. Open bindCatalyst.sln
  3. Run the bindApp project

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
Visual Studio Community 2022 for Mac Preview
Version 17.5 Preview (17.5 build 1701)
Installation UUID: e276f654-5fb9-420c-8f75-eddd5ca476a5

Runtime
.NET 7.0.1 (64-bit)
Architecture: X64
Microsoft.macOS.Sdk 12.3.2372; git-rev-head:754abbf6a3563f6267e5717ae832b4ac25b1f2fb; git-branch:release/7.0.1xx-xcode13.3

Roslyn (Language Service)
4.5.0-3.23056.2+97881342e427ff5cdcba8f12b12ff8e6f3564431

NuGet
Version: 6.4.0.117

.NET SDK (x64)
SDK: /usr/local/share/dotnet/sdk/7.0.200-preview.22628.1/Sdks
SDK Versions:
	7.0.200-preview.22628.1
	7.0.102
	7.0.101
	7.0.100
	7.0.100-rc.2.22477.23
	6.0.405
	6.0.404
	6.0.403
	6.0.402
	6.0.401
	6.0.400
	6.0.400-preview.22330.6
	6.0.302
	6.0.301
	6.0.300
	6.0.203
	6.0.202
	6.0.201
	3.1.426
	3.1.425
	3.1.424
	3.1.423
	3.1.422
	3.1.421
	3.1.420
	3.1.419
	3.1.418
	3.1.417
MSBuild SDKs: /Applications/Visual Studio (Preview).app/Contents/MonoBundle/MSBuild/Current/bin/Sdks

.NET Runtime (x64)
Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
	7.0.2
	7.0.1
	7.0.0
	7.0.0-rc.2.22472.3
	6.0.13
	6.0.12
	6.0.11
	6.0.10
	6.0.9
	6.0.8
	6.0.7
	6.0.6
	6.0.5
	6.0.4
	6.0.3
	5.0.17
	3.1.32
	3.1.31
	3.1.30
	3.1.29
	3.1.28
	3.1.27
	3.1.26
	3.1.25
	3.1.24
	3.1.23

Xamarin.Profiler
Version: 1.8.0.19
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

Updater
Version: 11

Xamarin.Android
Not Installed

Microsoft Build of OpenJDK
Java SDK: /Library/Java/JavaVirtualMachines/microsoft-11.jdk
11.0.16.1
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

Eclipse Temurin JDK
Java SDK: /Library/Java/JavaVirtualMachines/temurin-8.jdk
1.8.0.302
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

Android SDK Manager
Version: 17.5.0.26
Hash: 2eaa6bb
Branch: remotes/origin/HEAD
Build date: 2023-01-12 16:28:13 UTC

Android Device Manager
Version: 0.0.0.1236
Hash: bd1b161
Branch: main~1
Build date: 2023-01-12 16:28:13 UTC

Apple Developer Tools
Xcode: 14.2 21534
Build: 14C18

Xamarin.Mac
Version: 9.0.0.27 Visual Studio Community
Hash: 933c6c2c9
Branch: xcode14.1
Build date: 2022-11-22 02:00:36-0500

Xamarin.iOS
Version: 16.1.1.27 Visual Studio Community
Hash: 933c6c2c9
Branch: xcode14.1
Build date: 2022-11-22 02:00:37-0500

Xamarin Designer
Version: 17.5.3.19
Hash: bdc89f6bdb
Branch: remotes/origin/main
Build date: 2023-01-12 16:28:09 UTC

Build Information
Release ID: 1705001701
Git revision: 9204c908b1c63abd5512ab3fc1b702a21b75f5cb
Build date: 2023-01-12 16:26:24+00
Build branch: release-17.5
Build lane: release-17.5

Operating System
Mac OS X 12.6.2
Darwin 21.6.0 Darwin Kernel Version 21.6.0
    Sun Nov  6 23:31:16 PST 2022
    root:xnu-8020.240.14~1/RELEASE_X86_64 x86_64

Example Project

sample project.zip

@rolfbjarne
Copy link
Member

As a temporary workaround, try adding the following to the csproj:

<PropertyGroup>
    <MtouchExtraArgs>--registrar:static</MtouchExtraArgs>
</PropertyGroup>

now I get this exception:

Could not initialize an instance of the type 'WindowsAzure.Messaging.SBNotificationHub': the native 'initWithConnectionString:notificationHubPath:' method returned nil.

which seems to be because the connection string is invalid.

@marekdovjak
Copy link
Author

@rolfbjarne it works now, thank you!

@rolfbjarne
Copy link
Member

Reopening since there's an actual bug here on our side.

@rolfbjarne rolfbjarne reopened this Jan 24, 2023
@rolfbjarne rolfbjarne added bug If an issue is a bug or a pull request a bug fix binding-projects Issue or PR that affects binding projects labels Jan 24, 2023
@rolfbjarne rolfbjarne added this to the Future milestone Jan 24, 2023
rolfbjarne added a commit to rolfbjarne/xamarin-macios that referenced this issue Jan 24, 2023
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.
rolfbjarne added a commit to rolfbjarne/xamarin-macios that referenced this issue Jan 24, 2023
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.
rolfbjarne added a commit that referenced this issue Jan 25, 2023
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.
@ghost ghost locked as resolved and limited conversation to collaborators Feb 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
binding-projects Issue or PR that affects binding projects bug If an issue is a bug or a pull request a bug fix
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants