Bug 29090 - Native library 'liboleaut32.dylib' seems to disappear after updating to Xamarin.Mac 2 via changing update channel to alpha
Summary: Native library 'liboleaut32.dylib' seems to disappear after updating to Xamar...
Status: RESOLVED FIXED
Alias: None
Product: Xamarin.Mac
Classification: Desktop
Component: mmp ()
Version: 2.0.0
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: ---
Assignee: Chris Hamons
URL:
Depends on:
Blocks:
 
Reported: 2015-04-14 14:09 UTC by Norbert Virth
Modified: 2015-05-29 12:23 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Build output and About Xamarin Studio - Summary (10.77 KB, application/octet-stream)
2015-04-14 14:09 UTC, Norbert Virth
Details
Example project which shows the bug (results in empty window) (28.80 KB, application/octet-stream)
2015-04-15 14:31 UTC, Norbert Virth
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:
Status:
RESOLVED FIXED

Description Norbert Virth 2015-04-14 14:09:14 UTC
Created attachment 10754 [details]
Build output and About Xamarin Studio - Summary

I just changed the Xamarin Studio's update channel to Alpha, to be able to try out the Xamarin.Mac 2. Also the Xamarin Studio and the Mono framework got updated. See my attachments to more details.

So, after a successful build, I get a warning:
.../MMP: Warning MM2006: Native library 'liboleaut32.dylib' was referenced but could not be found. (MM2006) (<proj.name>)

This happend by an existing project, with target framewrok "Xamarin.Mac Mobile Framework". This happens also by creating new projects. When I choose the new "Xamarin.Mac .NET 4.5 Framework" as Target Framework, there will be a lot more warnings, with the same message to missing dylibs:

liboleaut32.dylib
libintl.dylib
libsqlite3.dylib
libgobject-2.0.dylib
libgda-2.dylib
libodbc32.dylib
Comment 1 Chris Hamons 2015-04-14 14:23:31 UTC
I believe this is a cosmetic issue. Have you been seeing any actual differences in your program's execution?
Comment 2 Norbert Virth 2015-04-15 03:08:36 UTC
Yes :) Actually, my surface completely disappeared down from my MainWindow's ContentView property. 
We use Xib-less way to build the UI. The project I'm working on is in initial state yet, it's a one-page app; so we usually just replace this window's ContentView property with new NSViews.
Earlier, it worked; but now, an empty window is the result. The only thing I've done was to change the update channel to alpha. I don't know if this problem was caused by this missing dylib, or due to smg else.
Comment 3 Chris Hamons 2015-04-15 08:40:44 UTC
Hmm. There were other changes, such as runtime changes unifying us more and more with iOS. Are you creating custom views defined in another assembly? Loading native libraries by hand?

Could you attach an example showing the problem?
Comment 4 Norbert Virth 2015-04-15 14:31:56 UTC
Created attachment 10775 [details]
Example project which shows the bug (results in empty window)
Comment 5 Norbert Virth 2015-04-15 14:33:15 UTC
Are you creating custom views defined in another assembly?
No
Loading native libraries by hand?
No

I've added an example project as an attachment - it is the same project in which the problem occured, only firm name and so kind of stuff got removed.
Comment 6 Chris Hamons 2015-04-15 15:10:39 UTC
Alright, it turns out the sample project is doing a few things "wrong", and enough runtime changes rearranged things enough for one of them to matter.

The important one for today's issue is in WindowBase.cs. You have:

		void Initialize()
		{
			BuildView();
		}

		protected abstract void BuildView();

It should be

		void Initialize()
		{
		}

		public override void AwakeFromNib ()
		{
			BuildView();
		}

		protected abstract void BuildView();

Once you do that, I get a login prompt. The reason Initialize is bad is that it is way too early in the life cycle of the Window to do things correctly. It isn't in the visual tree, etc. A good rule of thumb I use is:

Initialize / Constructors are for class invariants that must be setup right away. Something like a mutex or internal data structure. Realize that Initialize might be called if we lose all c# references to your view and have to resurface it. This is a rare use case, if you think you need it, you are probably wrong. Don't do anything here that messes with Cocoa is (overly)-safe rule.

AwakeFromNib is called when you are comfortably in the visual tree and you can do things you want. This is the 99% place you do things. Even when you don't use Nibs!

There are also some issues that need addressed, but aren't actively causing issues, right now:

- Not every NSView/NSWindow derived object has an IntPtr constructor. See PageBase/LoginPage. If you don't have one of these and you need to surface an instance to c#, you will crash in a giant fireball. Don't let that happen, just keep the IntPtr constructor.
- Not every NSView/NSWindow object is correctly daisy chaining constructors up to base. You should really have them do that, as we might have behind the scenes magic that is required.
- This line is cute, public MainWindowController() : base(typeof(MainWindow).Name) but if you ever rename MainWindow and forget to rename the xib, it will fail.

You can in theory get rid of MainMenu.xib (as your TODO asks), and people have:

http://stackoverflow.com/questions/6945872/cocoa-app-without-a-mainmenu-xib
http://lapcatsoftware.com/blog/2007/05/16/working-without-a-nib-part-1/

but you'll have to do even more heavy lifting (and if things break, you get to keep the pieces).

Since you see to have an interest in going off the beaten trail and go xib'less as much as possible, read http://developer.xamarin.com/guides/mac/advanced_topics/internals/ . You'll need to understand what is going on. The NSCoder constructor is gone in Unified, so you can skip that.
Comment 7 Norbert Virth 2015-04-16 05:59:38 UTC
Thank you very much for your help! Very very much! It helped me a lot :)
And sorry than for this bug report, it was indeed my fault, not the framework's
Comment 8 Chris Hamons 2015-04-16 09:30:38 UTC
No problem. Undefined behavior like this doesn't throw exceptions, it just mostly causes race conditions and things not working as expected, which is unfortunate.
Comment 9 Radu 2015-05-07 03:18:27 UTC
while the comments and comments are very useful, the bug is not resolved. We still get that the warning 
"MMP: Warning MM2006: Native library 'liboleaut32.dylib' was referenced but could not be found. (MM2006)"
And I am obsessed over having warning free builds, even if they are "cosmetic" or not. The bug should not be marked as resolved
Comment 10 Chris Hamons 2015-05-07 09:48:59 UTC
@Radu - Please file that as a separate issue (with a repro case please). This one implied (from the original comments) a behavior change in their code.

Please note - You can always use the additional mmp argument: ignore-native-library= to shut mmp up about a given library.
Comment 11 Rolf Bjarne Kvinge [MSFT] 2015-05-29 12:23:23 UTC
The warning about liboleaut32.dylib will be fixed for Xamarin.Mac 2.2.

maccore/master: 5ec8280f30fda46d9c879cacdc3355e0b994a111