我已经看到了关于这个问题的一些讨论，但我还没有看到明确的答案，当然不是的MonoTouch /单声道为Android。

我正在开发一个Xamarin为基础的多目标的解决方案，自然我有很多共同code。理想情况下，code将驻留在一个共同标准.NET类库项目（或项目）。当我引用这个项目在特定平台的项目中，我得到了警告，该项目的共同不能被引用。引用的项目针对的是一个不同的框架家族（.NETFramework），但解决的办法仍然是成功编译。

从本质上讲，我问，如果我必须使用文件链接的方式，当我共同code为解决多个目标。更详细地说，我的问题是：

是上述方法无效时，我的共同项目只引用这是由单声道*的目标？支持配件 如果答案以上是肯定的：说我引用第三方.NET库（DLL中的，而不是一个项目的形式），在我的普通项目，该库确实有不同的组件为不同的目标（但不引用不支持单声道*组装），我仍然可以参考Windows版本的组件，并摆脱它？ 解决方案

还有一种叫做对已在它的途中有一段时间了便携式类库。使用Visual Studio 2012（发布2012-09-12）开始，现在是Visual Studio中的一等公民，让您可以在Windows 8之间共享库，Windows手机，的Silverlight，Windows和LT; 8等

我期望的MonoDevelop遵循这一轨迹，使便携式库可以共享也支持Mono Android和MonoTouch的。

在此同时，你应该创建一个项目，每一个平台，即使的链接的同一个源文件。我发现这是最好的解决办法：

命名为这样的项目文件

  MyCompany.MyProduct.MyModule.Ios.csproj
MyCompany.MyProduct.MyModule.Android.csproj
MyCompany.MyProduct.MyModule.WinPhone.csproj
 

在所有的项目的命名空间是唯一MyCompany.MyProduct.MyModule。

您的链接的从项目中的相同CS文件到共享文件夹。

如果您需要公开的IOS版本一些额外的类，您只需将该文件添加到了iOS项目（不链接），并添加.IOS的命名空间，因为你要跨平台的命名空间不能与平台混乱具体的东西。

下面是不会打破的Windows路径长度问题的文件夹结构：

  / MyCompany的/ myProduct的/
 

在这里，您将解决方案文件的所有目标平台，命名是这样的：

  MyCompany.MyProduct.Ios.sln
MyCompany.MyProduct.Wpf.sln
...
 

文件夹，每个组件：

  / MyCompany的/ myProduct的/ MyModule的/
 

在这里，你把一共享文件夹，一个文件夹为每个平台，所以：

  / MyCompany的/ myProduct的/ MyModule的/共享/
 

只有

跨平台code（每个项目文件链接到）！

  / MyCompany的/ myProduct的/ MyModule的/安卓/
/ MyCompany的/ myProduct的/ MyModule的/依奥斯/
/ MyCompany的/ myProduct的/ MyModule的/ WinPhone /
/ MyCompany的/ myProduct的/ MyModule的/ WPF /
/ MyCompany的/ myProduct的/ MyModule的/苹果/
...
 

这是你把项目文件为每个平台的模块，并在那里你把任何平台来实现特定的平台模块是需要特定的CS文件。

这工作对我们非常好。

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.