这可能之前已经发布过，但我不确定要查找哪些搜索词！
快速解释。
我有几个项目之间共享的代码。此代码本身仍在进行中。问题是每当我需要更新这段代码时，我不想做 3 次，这将成为一场噩梦。
有没有办法将它添加到项目中，而无需将其复制到项目文件夹中？即我希望将共享类链接到我的 3 个项目中
C:\code repository\sharedclass.cs 不是 \eachproject\bin\sharedclass.cs
我必须将它创建为它自己的库项目吗？如果编译器可以将其编译为“外部”代码会更好。
干杯。
正如其他人所说，您只需在解决方案资源管理器中右键单击您的解决方案，选择添加 > 现有项目，然后浏览到通用项目的 .csproj 文件，它将从其原始位置包含在解决方案中。
但是，这有两个问题，这可能是也可能不是问题，具体取决于您团队的规模：
公共项目将包含在每个解决方案中，并带有解决方案文件的相对路径（即：...\CommonProject\Common.csproj）。这意味着所有开发人员必须具有相同的工作文件结构，否则他们在尝试打开主项目时会出错。
在公共项目被多个项目（例如两个 - A 和 B）引用并且从事项目 A 的开发人员必须对公共项目进行更改作为其任务的一部分的情况下，该开发人员无法知道如果他们所做的更改会破坏项目 B，而他们没有实际检查项目 B 并对其进行编译。随着越来越多的项目引用通用项目，发生这种情况的风险增加到无法管理的程度。
同样，正如其他人所说，没有“正确”的方法可以做到这一点。但是，我采取的方法如下：
使用 Cruise Control 等持续集成来管理项目的构建，并将公共项目作为独立项目放在服务器上。
在您的源代码管理下创建一个目录来存放构建的常用 DLL。在您的构建机器上签出此目录，每当构建公共项目时，它会将输出 DLL 复制到 DLL 文件夹并将这些更改提交到源代码管理。
在所有开发人员的机器和构建服务器上使用环境变量来控制公共 DLL 文件夹的位置，并使用该变量而不是硬编码路径来引用 DLL。（即：而不是 C:\Source\MyCommonProjectDLLS\Common.dll，使用 $(MyCommonLocation)\Common.dll 并将变量 'MyCommonLocation' 设置为 C:\Source\MyCommonProjectDLLS）
对于任何引用公共 DLL 的项目，请在构建服务器上为该项目设置 CI 触发器以监视公共 DLL 文件夹。每当向它提交更改时，构建服务器就应该构建所有正在使用的项目。
这会立即让您知道您是否正在为任何其他项目提交重大更改。唯一的缺点是，在此模型中，使用项目被迫在生成公共 DLL 后立即对其进行更新。另一种方法是在构建时从源代码控制修订版中对 Common DLL 进行版本化，并将每个版本放在 common DLL 文件夹下的自己的子目录中。所以你最终会得到：
常用 DLL
-1.0.0.1234
-1.0.0.1235
-1.0.0.1236
等等。这样做的好处是每个项目都可以通过简单地引用新版本的代码来选择何时对公共 DLL 进行更新。然而，这两种方式都被切断了，因为这可能意味着一些项目使用旧版本的公共代码的时间比他们应该的要长，这可能会增加最终引入这些更改时所涉及的工作。
是的。
您可以从硬盘驱动器上的任何位置将项目添加到解决方案中。因此，将共享代码放入类库并将其添加到您的三个项目中。
微软一直在支持一个开源项目，它现在内置在 VS 中，它称为 NuGet，您可以将共享项目输出为 nuget 文件并在其他项目中使用它。
它实际上会在构建时部署您在包中指定的所有文件。
这就是 .Net 现在支持依赖项的方式。您会注意到，即使是像 EF 这样的东西也是通过 NuGet 包实现的。您甚至可以在 MyGet.org 之类的地方免费托管它，我使用它，而且效果很好。
我使用git 子模块来实现这一点。
现在共享项目已包含在解决方案中，您将能够推送和拉取对子模块的更改，这些更改将自动合并到解决方案中。您还可以看到引用子模块的其他 git 存储库中的更改。
是的，将需要共享的代码放在一个单独的类库项目中，构建它并将从此构建创建的 DLL 引用到您的其他项目中。
最好将公共部分提取到单独的项目库中，并将该项目的引用添加到所有解决方案/依赖项目中。
否则，您可以将代码/文件/项目添加为 Link。