如果您试图在两个不同的项目类型(即:桌面项目和移动项目)之间共享代码，您可以查看共享解决方案文件夹。我必须为我当前的项目这样做，因为移动和桌面项目都需要相同的类，只在一个文件中。如果您采用这种方法，任何链接了该文件的项目都可以对其进行更改，并且所有项目都将根据这些更改重新构建。

一个项目可以被多个解决方案引用。

将库或核心代码放入一个项目中，然后在两个解决方案中引用该项目。

现在您可以使用共享项目了

Shared Project is a great way of sharing common code across multiple application We already have experienced with the Shared Project type in Visual Studio 2013 as part of Windows 8.1 Universal App Development, But with Visual Studio 2015, it is a Standalone New Project Template; and we can use it with other types of app like Console, Desktop, Phone, Store App etc.. This types of project is extremely helpful when we want to share a common code, logic as well as components across multiple applications with in single platform. This also allows accessing the platform-specific API ’s, assets etc.

更多信息请看这个

创建一个包含所有常用功能的dll类库是个好主意。无论其他解决方案如何，每个解决方案都可以独立地引用此dll。

事实上，在我的工作中，这就是我们资源的组织方式(我相信在许多其他地方也是如此)。

顺便说一下，解决方案不能显式地依赖于另一个解决方案。

将一个项目包含在多个解决方案中是一个非常糟糕的主意。

假设您在SolutionA和SolutionB中都包含了一个共享类库项目。

现在，如果您在解决方案a中工作，并在共享中进行了突破性更改，会发生什么?然后您将在解决方案a中得到一个构建错误，这可能很容易修复。但是你不会注意到你在solutionb中也弄坏了一些东西。您的构建服务器可能会告诉您—但这已经太迟了。在发布代码之前，您需要知道这些。

只有两个好的解决方案:

让Shared成为一个可以实际共享的nuget包，并使用semver来控制破坏性更改的影响。这可能会产生一些您不想要的开销。 创建一个单独的解决方案，其中包含来自solutiona和SolutionB的Shared和所有依赖的项目。如果您有许多不相关的项目依赖于sharedd，那么这可能不是最好的解决方案，然后您应该使用nuget方法。

您可以使用以下技术(这是@Andomar的解决方案保存在.csproj中的方法)内联通配符

<Compile Include="..\MySisterProject\**\*.cs">
  <Link>_Inlined\MySisterProject\%(RecursiveDir)%(Filename)%(Extension)</Link>
</Compile>

投入:

    <Visible>false</Visible>

如果你想隐藏文件和/或防止通配符包括被扩展，如果你添加或删除一个项目从“虚拟现有项目”文件夹，如上面的MySisterProject。