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.
There is an inconsistency with MonoTouch that drives me nuts as a developer:
1. I am able to reference an assembly built on .NET 4 in a MonoTouch application. It will work all the up until it doesn't (tries something not supported by MT).
2. I am UNABLE to reference a project built with .NET 4 in the solution.
This makes no sense, why should I be able to reference an assembly but not a project. They output the same thing.
Because of this inability to reference .NET 4 projects, I have to do some really wacky things:
1. I can reference the bin/Whatever.dll of the project. This works thanks to #1 above, but means my app is always using a library that it one step behind.
2. I can manually manage a plethora of file links and replicate the .NET 4.0's project structure in the app. This works but is hugely annoying and error prone.
3. I can manage an MT project that also replicate's the .NET 4.0's project structure. This double's the burden of project management, but is better than dealing with #2.
Cross platform development is critical part of Xamarin's user story. We have to improve the tools to make it easier.
This is an IDE restriction (which I believe is done to avoid building apps that will fail at runtime, instead than failing at build time).
mtouch itself will warn (MT0011), not fail, if it find assemblies that were compiled with .NET 4.0. Of course missing symbols (not in MT BCL) can result in error later (e.g. at link time) or broken binaries (once AOTed, which would fail at runtime if that code is reached during execution).
It seems reasonable then that the IDE could warn me, but still let me continue. It just seems so strange that I'm allowed to do it one way - that gives a bad user experience - but not the other with the good user experience.
It's just very difficult to create cross platform apps with shared libraries right now. We *need* to make this better.
I can let this bug slide if we improve Portable Library support. But having neither solution right now makes development a PITA.
IMHO we should disallow 4.0 (or 2.0, or 4.5, etc) references in both cases (but we should probably improve on the PLP support first).
PLP support has been improved to allow referencing/building against all PLP profiles now
I don't think we actually want to allow referencing a .NET 4.0 project