Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
The extension limitation where app extensions can only access frameworks in the main apps bundle makes providing framework bindings for frameworks that provide UNNotificationServiceExtension near impossible.
While trying to provide the AirshipAppExtension framework as a separate package, I ran into the following issues:
- Framework packages that are added to an extension must also be added to the main app bundle. However if the main app does not reference the package that includes the framework, the framework will not be loaded into the application bundle. I tried force loading, preserve attribute, etc... nothing would cause the framework to show up in the app bundle. I was able to work around this using 2 different methods by either manually referencing the package in the main app, or including the framework in a package that the main app was actually using.
- When I tried one of my workaround to get an app extension framework for a UNNotificationServiceExtension in the app bundle, it would work fine until the app ran on an older iOS device. I received this error:
Dyld Error Message:
Dyld Message: Library not loaded: /System/Library/Frameworks/UserNotifications.framework/UserNotifications
Referenced from: /private/var/containers/Bundle/Application/B6FB66F7-2D65-408A-9EC0-BB0CE5731EBA/Demo.app/Frameworks/AirshipAppExtensions.framework/AirshipAppExtensions
Reason: image not found
Dyld Version: 390.7
I eventually tried writing a C# library that accomplished the same thing, but I ran into a memory issue described here - https://bugzilla.xamarin.com/show_bug.cgi?id=43985.
It would be awesome if framework for packages referenced in an extension project would be dropped in the framework directory of extensions bundle. This would remove the limitation and make sure that any packages referenced in the extension will work fine.
Thanks for the detailed description Ryan we will look into this.
Rolf, looks like the fix is to copy the frameworks into the main app bundle's framework directory. I believe this will still cause the dyld issue above. Extensions have their own framework directory that can be used to make sure the frameworks are only loaded when the extension is loaded. It will also allow an extension to use a different version of a framework than the main application.
@Ryan, you ran into the dyld issue because in your workaround you made the main app link with the framework, which prevents it from working on older iOS versions (since older iOS versions don't support user frameworks).
With the fix, the main app won't link with the framework, so you won't run into the dyld issue.
I also checked with Xcode, and frameworks used in extensions end up in the main app's Frameworks directory.
@Rolf, awesome. I was not 100% sure what caused the dyld issue. I will try it out once its released.
For Xcode, I am pretty sure the default behavior is to not copy any frameworks over and instead you have to add a build phase step that explicitly copies the framework. When you add that it ends up in AppBundle/Plugins/AppExtension/Frameworks. The default build settings for an extension looks in both directories, so as long as the dyld is fixed this should be fine.
It would be helpful for us if you verify this issue at your end with new Xcode. And feel free to reopen it, if you are still facing this issue.
I will verify that the issue is fixed later today.
This does not appear to be 100% fixed. I see the frameworks.txt file in the generated extension directory, but extension package is not listed. Only the Mono.framework:
I tested https://www.nuget.org/packages/urbanairship.appextensions and https://www.nuget.org/packages/urbanairship and both failed to list the framework. The generated app bundle also does not have the expected frameworks.
@Ryan, can you attach a verbose build log from your test project (see https://developer.xamarin.com/guides/android/troubleshooting/troubleshooting/#Diagnostic_MSBuild_Output for how to make build logs more verbose, and also please add "-v -v -v -v" to the additional mtouch arguments in the project's iOS Build options).
Created attachment 19099 [details]
Verbose log file
@Ryan, it looks like you're not using any code from the urbanairship assemblies in your project.
It's not enough to add a reference to the nuget/project/assembly for the corresponding assemblies to be put in your app, you also need to somehow reference any code from those assemblies (this can be as simple as a "Console.WriteLine (typeof (Some.UrbanAirshipType));".
Created attachment 19135 [details]
@Rolf, my mistake. I recreated the extension to give it a better name for the logs but forgot to extend the class again. After extended the class things are still not working. I attached new logs and the sample project I am using to reproduce the issue.
Created attachment 19136 [details]
@Ryan, thanks, I found a bug in the implementation, which I'm fixing now:
@Ryan Thanks for reporting this issue.
Now, Could you please check if this issue is 100% fixed for you, when you get a chance?
Looks like framework.txt is updated with the proper frameworks and I confirmed all the expected frameworks end up in the app bundle. Appears to be fixed! Awesome job @Rolf!
I am currently unable to fully test the UNNotificaitonService as I do not have a iOS device on hand (requires remote notifications), but I can report back on Monday.
Thanks @Ryan for verifying this issue.
As of now I am closing this issue by marking it as Verified. Please feel free to reopen it if you are still getting this issue.