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.
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:
I believe this is a cosmetic issue. Have you been seeing any actual differences in your program's execution?
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.
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?
Created attachment 10775 [details]
Example project which shows the bug (results in empty window)
Are you creating custom views defined in another assembly?
Loading native libraries by hand?
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.
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:
protected abstract void BuildView();
It should be
public override void AwakeFromNib ()
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:
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.
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
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.
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
@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.
The warning about liboleaut32.dylib will be fixed for Xamarin.Mac 2.2.