Home/ Questions/Q 8618015
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-12T06:00:37+00:00

I’ve seen a few discussions regarding this issue, but I’ve yet to see clear-cut

  • 0

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:

  1. Is the above approach valid when my “common” projects reference only assemblies which are supported by Mono* targets?
  2. 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?
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0