Bug 7159 - Should be able to reference .NET 4 projects in a solution
Summary: Should be able to reference .NET 4 projects in a solution
Status: RESOLVED NOT_ON_ROADMAP
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: iOS add-in ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Jeffrey Stedfast
URL:
Depends on:
Blocks:
 
Reported: 2012-09-13 13:59 UTC by Frank A. Krueger
Modified: 2012-12-06 17:19 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:
Status:
RESOLVED NOT_ON_ROADMAP

Description Frank A. Krueger 2012-09-13 13:59:15 UTC
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.

-or-

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.

-or-

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.
Comment 1 Sebastien Pouliot 2012-09-13 15:43:58 UTC
-> MonoDevelop

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).
Comment 2 Frank A. Krueger 2012-09-13 15:54:07 UTC
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.
Comment 3 Rolf Bjarne Kvinge [MSFT] 2012-09-13 17:25:52 UTC
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).
Comment 4 Jeffrey Stedfast 2012-12-06 17:19:56 UTC
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