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