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

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

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

只有两个好的解决方案:

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

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

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

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

您可以托管一个内部NuGet服务器，并共享将在其他项目内部和外部共享的公共库。

再往下读

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

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

投入:

    <Visible>false</Visible>

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

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

您只需创建一个单独的Class Library项目来包含公共代码。它不需要成为任何使用它的解决方案的一部分。从任何需要它的项目引用类库。

唯一的技巧是，您将需要使用文件引用来引用项目，因为它不会是引用它的解决方案的一部分。这意味着实际的输出程序集必须放置在任何构建引用它的项目的人都可以访问的位置。例如，这可以通过将程序集放在共享上来实现。