将公共代码提取到类库项目中，并将该类库项目添加到解决方案中。然后，您可以通过向该类库添加项目引用来添加对来自其他项目的公共代码的引用。与二进制/程序集引用相比，拥有项目引用的优势在于，如果您将构建配置更改为调试、发布、自定义等，公共类库项目也将基于该配置构建。

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

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

您可以在多个解决方案中包含相同的项目，但是您一定会在某个时候遇到问题(例如，当您移动目录时，相对路径可能会失效)。

经过多年的努力，我终于提出了一个可行的解决方案，但它要求您使用Subversion进行源代码控制(这并不是一件坏事)

在解决方案的目录级别，添加一个svn:externals属性，指向您希望包含在解决方案中的项目。Subversion将从存储库中提取项目，并将其存储在解决方案文件的子文件夹中。解决方案文件可以简单地使用相对路径来引用项目。

如果我有更多的时间，我会详细解释这一点。

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

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

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

只有两个好的解决方案:

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

您可以在两个项目之间“链接”代码文件。右键单击项目，选择“添加->现有项目”，然后单击“添加”按钮旁边的向下箭头:

根据我的经验，链接比创建库简单。链接代码会产生一个版本的单一可执行文件。

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

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

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