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

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

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

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

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

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

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

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

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

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

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

File > Add > Existing Project…将允许您向当前解决方案添加项目。只是加上这个，因为上面的帖子都没有指出这一点。这允许您在多个解决方案中包含相同的项目。

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

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

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

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

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

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

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

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

投入:

    <Visible>false</Visible>

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

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

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

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

在另一个项目中包含一个项目的类文件的一个更简单的方法是在现有解决方案中添加该项目，然后在现有项目中添加新项目的DLL引用。最后，您可以通过在任意类的顶部声明using指令来使用添加的类的方法。

涉及的两个主要步骤是

1-创建c++ dll

在visual studio

New->Project->Class Library in c++ template. Name of project here is first_dll in 
visual studio 2010. Now declare your function as public in first_dll.h file and 
write the code in first_dll.cpp file as shown below.

文件代码

// first_dll.h

using namespace System;

namespace first_dll 
{

public ref class Class1
{
public:
    static double sum(int ,int );
    // TODO: Add your methods for this class here.
};
}

Cpp文件

//first_dll.cpp
#include "stdafx.h"

#include "first_dll.h"

namespace first_dll
{

    double Class1:: sum(int x,int y)
    {
        return x+y;
    }

 }

检查这个

**Project-> Properties -> Configuration/General -> Configuration Type** 

这个选项应该是Dynamic Library(.dll)，现在就构建解决方案/项目。

在Debug文件夹中创建first_dll.dll文件

2-在c#项目中链接它

开放c#项目

Rightclick on project name in solution explorer -> Add -> References -> Browse to path 
where first_dll.dll is created and add the file.

在c#项目的顶部添加这一行

Using first_dll; 

现在可以在某些函数中使用下面的语句访问dll中的函数

double var = Class1.sum(4,5);

我在VS2010的c++项目中创建了dll，并在VS2013的c#项目中使用。它工作得很好。

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

再往下读

从VisualStudio 2015开始，如果您将所有代码保存在一个解决方案中，您可以通过添加共享项目来共享代码。 然后为您想在其中使用代码的每个项目添加对该共享项目的引用，以及适当的使用指令。

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

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.

更多信息请看这个

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

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

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

只有两个好的解决方案:

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