.net 如何为同一dll管理多个目标平台？

我们在TFS中有一个团队项目，专门用于通用代码，如通用扩展方法、实用程序类，以及可以与我们公司的每个团队共享的东西。在某种程度上，它就像.Net框架本身的扩展

目前有一组项目按区域分开，因此当团队想要部分功能时，他们不必每次都拖拽一组依赖项。这些项目的命名约定遵循格式

[OurCompany].Framework.[等效的.Net命名空间]

以下是我们在解决方案中使用的DLL的几个示例：

• Mobiltec.Framework.dll
• Mobiltec.Framework.Web.dll
• Mobiltec.Framework.Data.dll

当我们试图为不同的平台进行相同的扩展时，问题就出现了。例如，有一个针对Silverlight的Mobiltec.Framework.dll，也有一个针对WindowsMobile平台的。在生成服务器上生成解决方案时，每个输出都会转到同一文件夹，并且只保留具有相同名称的最后生成的dll（以前生成的dll将被覆盖）。这显然会导致依赖于被覆盖文件的下一个项目出现错误

我认为不在dll名称上指定平台是一种很好的做法，似乎是第三方库甚至.Net framework dll的标准。Nuget软件包似乎也鼓励这样做（我想到的是log4net），不同的版本由文件夹分隔，这些文件夹指示它们在哪个平台/.net版本中工作，而dll名称本身是相同的

我是否应该为该框架的每个平台和/或每个.Net版本创建不同的解决方案？我们目前有两个解决方案，因为Visual Studio 2012不支持智能设备项目。有一个Framework.Legacy.sln文件，其中包含所有针对Windows Mobile SDK的项目，还有一个包含所有其他项目（desktop、Silverlight等）

理想情况下，我真的希望在同一个解决方案上共享尽可能多的项目，因为通过这种方式重构任务要容易得多（一些功能通过链接的.cs文件在平台之间共享）

因为我刚刚在TFS上为这个项目创建了一个构建（因此才意识到这个问题），所以我将框架的Silverlight版本分离到一个不同的解决方案中，并在构建定义中将“特定于解决方案的构建输出”选项设置为“true”。我们现在有3个解决方案（一个用于WindowsMobile，另一个用于“normal.Net4”，还有一个用于Silverlight 5）。目前，一切似乎都按预期运行，但我觉得我们正在失去重构的潜力，考虑到我们可以在不久的将来添加另一个版本（例如windows RT），我想知道是否有更好的方法来解决这个问题

---

我想知道的是，我们应该如何正确地管理它，以便它与TFS构建系统一起工作，同时易于一起维护？我肯定还有其他人不得不处理同样的问题。您是如何处理的？

您有一个独特的情况，即您希望瞄准许多主流产品，但同时也要瞄准传统产品。我看你有两个主要的选择

可移植类库（PCL） 理想情况下，您希望创建一个（PCL）。PCL允许您在一个项目中针对多个不同的平台。因此，在您的示例中，您只需要一个Mobiltec.Framework项目，它可以跨多个应用程序使用。对于您想要支持的大多数平台，这仍然是一个选项。PCL是伟大的，只要他们。PCL不允许一切，但您可以使用其他PCL绕过这些限制，构建自己的对象表示，或通过依赖项注入

针对不同平台的多个项目 使用此选项，您可以为要支持的每个平台向解决方案中添加一个csproj（您可以通过编辑项目属性来避免程序集的生成位置问题。在“生成”选项卡上，您可以指定生成程序集的位置。将其设置为特定于平台）。在您的示例中，您将有一个针对Silverlight的Mobiltec.Framework、一个针对.Net3.5的Mobiltec.Framework、一个针对Windows Phone的Mobiltec.Framework等。将每个项目文件命名为不同的名称（例如：Mobiltec.Framework、Mobiltec.Framework.Silverlight等），但程序集名称保持不变（项目属性的“应用程序”选项卡）

每个项目都会使用相同的文件。这允许您在一个文件中进行更改，但会影响每个项目。这些项目为您的目标平台提供了充分的支持，但并非所有的平台都是一样的。您将发现自己不得不在代码文件中使用if语句

public void Foo()
{
#if SILVERLIGHT
        // do something
#else
        // do something else
#endif
}

---

这两种方法都有很大的优点和缺点。理想情况下，您将能够为所有较新的平台提供一个PCL库和一个针对Windows Mobile的项目。如果你不能做到这一点（你的新项目需要一些不可用的东西），那么第二种方法仍然是一种很好的方法。在任何情况下都不需要代码重复。

回答得很好！我知道便携式图书馆的存在，但从未深入研究过它的实际工作原理。我认为这是一个非常巧妙的解决方案，我将进一步调查，看看我们项目中包含的所有内容是否在某种程度上与它兼容。我怀疑项目中至少有一些名称空间会导致pinvoking之类的问题，但我可以尝试在不同的、更具体的项目中分离它们。但我仍然想知道，如何在同一个解决方案上管理具有相同输出的多个项目？您能解决这个问题吗？每个项目都应该配置为构建到自己的平台目录中。因此，您可以使用和bin/Silverlight/Debug和bin/x86/Debug（针对特定于桌面的）这个wo