.net 如何组织多框架WCF服务的解决方案

我想知道为WCF服务组织文件的最佳方式是什么。该服务应针对.NET Framework 3.5和4.5的两个版本进行编译。它与不同版本的第三方资源调配一起使用

第一个想法是创建如下文件结构：

WcfProject
  |-File1.cs
  |-File2.cs
  |-MyWcfService.Net35.csproj
  |-MyWcfService.Net45.csproj
  |-??? Web.config ???
|-MySolution.Net35.sln
|-MySolution.Net45.sln

为不同的框架版本配置项目文件。但是我不知道如何处理Web.config文件，这对于3.5和4.5应该是不同的

我看到的另一种方法是为包含代码文件的3.5和4.5创建不同的项目文件夹。在这种情况下，公共文件将作为链接添加到项目中：

WcfProject.Net35
  |-File1.cs
  |-File2.cs
  |-MyWcfService.csproj
  |-Web.config
WcfProject.Net45
  |-File1.cs (link to ..\WcfProject.Net35\File1.cs)
  |-File2.cs (link to ..\WcfProject.Net35\File2.cs)
  |-MyWcfService.csproj
  |-Web.config
|-MySolution.Net35.sln
|-MySolution.Net45.sln

你们觉得呢，伙计们？有另一种方法可以解决我的问题，或者第二种方法已经是我能做的最好的了？

我会这样做：

创建一个私有文件。 对于每个公共依赖项，创建一个将程序集打包并发布到NuGet的生成。 将所需的依赖项整合到完全独立的3.5和4.5解决方案中。 将它们作为单独的关注点进行部署和管理。 或者，跳过第一步和第二步，只管理源代码管理中的依赖项

这些解决方案可以共享一些C文件吗

是的，如果使用NuGet，则可以指定要打包的静态内容，然后在抓取包时自动添加这些内容。请看，它告诉您如何使用节点

如果不打算使用nuget，还可以将文件作为链接从某个公共位置链接到VisualStudio。使用添加为链接。。。在“添加现有项”对话框中：

---

这意味着该文件将在编译期间作为源文件包含，但可以保存在实际解决方案文件夹之外

汤姆，谢谢你！还有一个问题。将所需的依赖项整合到完全独立的3.5和4.5解决方案中。这些解决方案可以共享一些C文件吗？例如，某些类帮助器可以编译为3.5或4.5而无需修改。