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.
When trying to integrate GoogleAnalytics in our shared library, I ran into what might be a bug in the monotouch builder.
Our project setup looks something like this:
* Project FlowPilots.Mono
-> Contains Analytics.cs, a wrapper around Google Analytics
-> References GoogleAnalytics.dll (a binding that was verified
to work in another project)
* Project WestVlinderen.iOS (the app itself)
-> References FlowPilots.Mono
-> Uses Analytics
If I don't reference GoogleAnalytics.dll in WestVlinderen.iOS, the app crashes, due to GANTracker.SharedTracker being null (so basically: the Objective-C method behind it returned null). Looks even worse when ran on the device: https://gist.github.com/7a6a754218d2d28f87ae
When I add a reference to GoogleAnalytics.dll in WestVlinderen.iOS, everything works fine.
This was not expected behavior, nor very convenient. Would it be possible to pick up the reference correctly?
Ruben, you're right that this is not the expected behaviour (nor optimal). c.c. Jeff
Jeff: the linker, thru the resolver, finds (and includes) references of references. However your [LinkWith] support code, that extract the .a from the .dll, executes before that. Is is possible you're not doing the same ?
I'm not sure what your asking...
Jeff: The above scenario works for .dll that do not include static library (extracted with [LinkWith]).
The LinkWith code just extracts the native libraries, though, right? So I'm not understanding why this would matter...
It's not about what it does, i.e. the process. It's about what's taken as the input of the process - if you don't consider all references you're missing some!
From the description the [LinkWith] support code is processing *only* direct references of the application. IOW it is _not_ considering (indirect) references of (application) references (see original description). Because of this the application ends up without the native .a static library which cause the crash (endless recursion).
Oooooohhhhhh, got it.
Yes, that is very possible.
Fixed in master: d953f6701aeea96276a2aef4a83c3e59b4b1afa5
Needs a bit more testing before backporting to 5.2-series so, until then, adding an extra (otherwise unneeded) reference to the binding assembly on the main project is the workaround.
*** Bug 3730 has been marked as a duplicate of this bug. ***
The fix will only be in 5.3+