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.
*** Bug 1409 has been marked as a duplicate of this bug. ***
It looks looks like the projects have multiple types registered with the same obj-c name, which is incorrect code, but we should handle it more gracefully.
We could just use one silently, but then we'd be hiding problems and things would probably break later. I think we'd be better to flag it as ambiguous and show an error dialog during outbound sync.
FWIW I think we need a way to collect a set of errors and warnings when performing inbound & outbound syncs, then present the list of warnings/errors to the user, instead of throwing on the first one like we tend to do now.
The thing is, it used to work. I could edit these files in IB 3. but i suppose maybe because it only loads one at a time?
also, if they're ambiguous, how does it work at runtime?
It used to work because none of the type syncing code existed before :)
In MD 2.6 and earlier, Interface Builder and the MD codebehind generation only ever individually considered each xib file and the types defined in that file. They weren't aware of the context of the whole project. That meant you wouldn't actually see Objective-C name collisions until runtime.
Now MD syncs all the Obj-C types out to Xcode, so they collide. It's simply not possible for us to support it. On the flip side, the improved integration means you could now have both your xibs refer to the same actual class, like several of the Universal project templates do.
How the problems in your project would manifest depends on how MT registers the classes with the Objective-C runtime, and there are several ways it can do this depending on the options and whether you're on device or simulator. It's possible that you were depending on the classes being lazily registered when first instantiated, and one was only used on iPhone and the other on iPad. However, that's an implementation detail that isn't guaranteed to remain unchanged.
The error dialog now contains more useful info to explain what went wrong (explains which types collided)
*** Bug 1432 has been marked as a duplicate of this bug. ***