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.
(Also see discussion at http://forums.xamarin.com/discussion/27307/assembly-for-xmlns-locate-not-found-forms-project-with-xaml.)
When using classes defined in the shared project, you have to explicitly reference the assembly in the namespace declaration in XAML. Since the shared code is built into the platform-specific assembly, this in turn requires that the assembly name be the same for each platform. In addition to being confusing because you then have potentially three different DLLs floating around with the same name, this triggers bug 24407 on iOS, because the app name automatically has iOS appended to it, while we clearly don't want iOS in the generic name we choose for all of the platform assemblies.
According to the MSDN docs (https://msdn.microsoft.com/en-us/library/ms747086(v=vs.110).aspx) WPF/XAML allows for not specifying the assembly and instead inferring it from the currently running assembly. This seems like an ideal solution if it's technically possible for Xamarin.Forms.
This is fixed in master