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

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

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

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

在跨项目重用代码时，使用“添加现有文件链接”是一个很好的例子，那就是当您需要引用和支持不同版本的依赖库时。

使用不同外部程序集的引用创建多个程序集，如果不重复代码或利用源代码控制的技巧，就不容易做到这一点。

我相信维护一个用于开发和单元测试的项目是最简单的，然后当您需要创建引用这些外部程序集的不同版本的程序集时，使用现有的文件链接创建“构建”项目。

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

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

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

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

您可以在多个解决方案中包含一个项目。我不认为一个项目有属于哪个解决方案的概念。然而，另一种替代方法是将第一个解决方案构建到一些众所周知的地方，并引用已编译的二进制文件。这样做的缺点是，如果您想根据您构建的是发布配置还是调试配置来引用不同的版本，那么您将需要做一些工作。

我不相信您可以让一个解决方案依赖于另一个解决方案，但是您可以通过自定义脚本以适当的顺序执行自动构建。基本上把你的公共库当作另一个第三方依赖，比如NUnit等。