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.
Classes that derive from UIViewController often have redundant "UIView view" outlets to work around issues in IB3 integration. The issues no longer existing in Xcode4, and the outlets can conflict with the base view outlet after MD updates the designer files to use the new property-based outlets. We should fix this by ignoring view outlets when parsing old outlets from controller classes.
Unfortunately I have no testcase for the issue and I don't understand exactly what needs to be done.
Is this additional property defined in user code or is it autogenerated by MonoDevelop after xcode syncing? If it's the latter, it should be easy to special case it and ignore it when syncing out to xcode. That way when we sync back it will just vanish. Is this what you're describing?
It originates from custom classes defined in the xib file in IB3, which resulted in MD <= 2.6 generating the outlet in the *.xib.designer.cs file. MD 2.8 parses those outlets (which are different from the MD 2.8 outlets) and syncs them out to Xcode. When the class is synced back, the outlets are regenerated as 2.8 outlets.
See also http://support.xamarin.com/customer/portal/questions/40506-view-outlet-was-not-set-when-using-xcode-4
The error appears to be a result of the base UIViewController's view outlet not being connected. It seems that when deserializing the nib, Cocoa Touch would connect both identically-named outlets: the user's ivar and the framework property. Now that the (redundant) user outlet is also a property, it hides the framework property.
This has been fixed in git. If we detect a property which has an [Outlet] or [Connect] attribute and it links to the obj-c 'view' property and the base class is UIViewController, we explicitly do not sync that property to xcode. That way when we sync back it will vanish.
To be honest this is something which I suppose can potentially hit us anywhere. As such, would it make sense to do a validation pass at compile time and emit warnings for user properties which shadow properties in monotouch?
It should be possible to iterate over all subclasses of NSObject and verify that none of them try to register an objective-c property using the [Connect] or [Outlet] attribute which has already been registered by one of its super classes.
I'm not sure. They're less likely to be created in xcode 4 since there's no need, and the user can connect to the base outlets, and also xcode warns about the conflict. This kind of advanced check would probably be better handled as a gendarme rule.
This should be implemented now. We no longer sync the outlet to xcode so if there is any modification, the outlet will vanish when the file is synced back to MD.