I've seen a few discussions regarding this issue, but I've yet to see clear-cut answers, certainly not for MonoTouch / Mono for Android.
I'm developing a Xamarin-based multi-target solution and naturally I have a lot of common code. Ideally, this code will reside in a "common" standard .NET class library project (or project). When I reference this project in platform-specific project, I do get the warning "The project 'Common' cannot be referenced. The referenced project is targeted to a different framework family (.NETFramework)", but the solution is still compiled successfully.
Essentially, I'm asking if I must use the file links approach when my common code is addressing multiple targets. In more detail, my questions are:
- Is the above approach valid when my "common" projects reference only assemblies which are supported by Mono* targets?
- If the answer to the above is yes: Say I reference a 3rd party .NET library (in a form of a DLL, not a project) in my "common" project, and this library does have different assemblies for different targets (but it doesn't reference an assembly not supported by Mono*), can I still reference the Windows version of the assembly and get away with it?
There is something called Portable Class Libraries that have been on its way for some time. Starting with Visual Studio 2012 (released 2012-09-12), it is now a first class citizen of Visual Studio so that you can share libraries between Windows 8, Windows Phone, Silverlight, Windows <8 etc.
I expect MonoDevelop to follow this track so that portable libraries can be sharable even with Mono for Android and MonoTouch.
In the mean time, you should create one project for each platform, even though the link to the same source files. I have found this to be the best solution:
The project files named like this
MyCompany.MyProduct.MyModule.Ios.csproj
MyCompany.MyProduct.MyModule.Android.csproj
MyCompany.MyProduct.MyModule.WinPhone.csproj
The namespaces in all the projects are only MyCompany.MyProduct.MyModule.
You link to the same cs files from the projects to a "Shared" folder.
If you need to expose some extra class in the Ios version, you simply add that file to the Ios project (not linked) and you add .Ios to the namespace since you want the cross platform namespace to not be cluttered with platform specific stuff.
Here is a folder structure that wont break the Windows Path Length Issue:
/MyCompany/MyProduct/
Here you put the solution files for all target platforms, named like this:
MyCompany.MyProduct.Ios.sln
MyCompany.MyProduct.Wpf.sln
...
Folder for each assembly:
/MyCompany/MyProduct/MyModule/
Here you put one "Shared" folder and one folder for each platform, so:
/MyCompany/MyProduct/MyModule/Shared/
Cross platform code only (linked to from each project file)!!!
/MyCompany/MyProduct/MyModule/Android/
/MyCompany/MyProduct/MyModule/Ios/
/MyCompany/MyProduct/MyModule/WinPhone/
/MyCompany/MyProduct/MyModule/Wpf/
/MyCompany/MyProduct/MyModule/Mac/
...
This is where you put the project files for each platform for the module and also where you put any platform specific cs files that is needed to implement the module on the specific platform.
This works very well for us.
MonoTouch, like Mono for Android, provides a subset of the regular (desktop) .NET framework.
This subset is actually a superset of the base class libraries (BCL) shipped for Silverlight (what we called FX 2.1 at the time).
You'll have issues with either 1 or 2 if your binaries are referencing types, methods (any metadata) that does not exists in MonoTouch (or Mono for Android).
With MonoTouch you'll find such issues when building for devices, since AOT (ahead of time) compilation is used. IOW missing symbols will be find at build time. Note the the JIT is used for the iOS simulator so missing symbols won't be found until they are required at runtime.
Mono for Android is using the JIT (both on devices and emulators) so any missing metadata is more likely to be found at runtime - i.e. the managed linker will also find missing members and won't be able to create new, smaller, assemblies if symbols can't be resolved.
So no the approach is not valid (as in 100% safe) unless you re-compile your code using the SDK assemblies (BCL) shipped with the products.
