logo标签列表

Visual Studio：如何管理在多个项目之间共享的代码

c#visual-studio-2010
11

这可能已经有人发布过，但我不确定要搜索什么关键字！

简单解释一下。

我有一些代码是在几个项目之间共享的。这些代码本身仍然在开发中。问题在于，每当我需要为任何原因更新这些代码时，我不想重复3次，这将成为一场噩梦。

有没有办法将其添加到项目中，而不将其复制到项目文件夹中？ 也就是说，我希望将共享类作为链接到我的3个项目中的

C:\code repository\sharedclass.cs 而不是 \eachproject\bin\sharedclass.cs

我必须将其创建为自己的库项目吗？如果编译器可以将其编译为“外部”代码，那将更好。

谢谢。

你是指类似于Visual Studio中的“添加文件作为链接”选项吗？http://support.microsoft.com/kb/306234（编辑：这是假设您不想使用共享项目的情况下）？ - Chris Sinclair
1
只需在您的解决方案中包含不同的项目，并添加对项目的引用，而不是编译后的.dll文件。我们的源代码存储库有一个包含共享代码（主要是类库项目）的文件夹，并且我们从树的完全不同区域的解决方案中引用这些项目。困难的事情在于如何安排源代码控制中的代码，以使您的团队感到直观。（并且没有“正确”的方法。设置它的方式取决于许多因素，可能需要一些时间来正确规划它。） - David
http://msdn.microsoft.com/en-us/library/1xhzskbe.aspx - user1621465
添加链接是首选解决方案。我将编辑来自三个不同项目的代码。只需打开文件并随着最新版本的演变即可完成所需操作。我知道共享项目和将库项目添加为引用。在这种情况下太复杂了，奥卡姆剃刀原理 ;) - Craig Hall
6个回答
7
正如其他人所说，您可以在解决方案资源管理器中右键单击您的解决方案，选择添加>现有项目，并浏览到公共项目的.csproj文件，它将从其原始位置包含在解决方案中。
然而，这种方法存在两个问题，这可能是一个问题，也可能不是，这取决于您的团队规模：
1. 公共项目将以相对路径（即：...\CommonProject\Common.csproj）的方式包含在每个解决方案中。这意味着所有开发人员必须拥有相同的工作文件结构，否则当他们尝试打开主项目时，他们将会遇到错误。
2. 在公共项目被多个项目引用的情况下（比如A和B），如果正在处理项目A的开发人员需要更改公共项目作为任务的一部分，则该开发人员无法知道他们所做的更改是否会破坏项目B，除非他们实际检出项目B并编译它。随着越来越多的项目引用公共项目，这种情况发生的风险增加到无法管理的程度。
同样，正如其他人所说，没有“正确”的方法来解决这个问题。但是，我采取的方法如下：
1. 使用持续集成（例如Cruise Control）来管理项目的构建，并将公共项目作为独立的项目放在服务器上。
2. 在源代码控制下创建一个目录来存储已构建的公共DLL。在您的构建机器上检出此目录，并且每当公共项目构建时，它将输出的DLL复制到DLL文件夹中，并将这些更改提交到源代码控制。
3. 在所有开发人员的机器和构建服务器上使用环境变量来控制公共DLL文件夹的位置，并使用该变量引用DLL，而不是硬编码的路径（即：使用$(MyCommonLocation)\Common.dll而不是C:\Source\MyCommonProjectDLLS\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的更新。 然而，它有两面性，因为这可能意味着某些项目比应该更长时间地使用旧版本的公共代码，当最终引入这些更改时，可能会增加工作量。

谢谢你的提示，我遇到了你上面描述的问题，你的答案非常有帮助！ - QtRoS
5

可以的。

您可以将硬盘上任何位置的项目添加到解决方案中。因此，将共享代码放入类库中，并将其添加到您的三个项目中。

这也是我处理事情的方式。我有一个通用的工具库，其中包括许多我在任何代码部分中都会使用的有用工具，因此我会将该项目添加到我正在处理的任何其他项目中。当您在那里修改代码时，它将在使用此项目的任何其他应用程序中进行修改。而且，当您需要发布时，有时最好只从DLL中工作并将其保留为“正确版本”，因为有时在其他程序中工作一段时间后，您可能会破坏事物的工作方式，从而破坏旧程序。如果您在发布时保留了DLL，则会使事情变得更简单。 - Joe
3
微软一直在支持一个开源项目，现在它已经内置于VS中，称为NuGet，您可以将共享项目输出为nuget文件，并在其他项目中使用它。实际上，它会在构建时部署您在包中指定的所有文件。这就是.Net现在支持依赖项的方式。您会注意到，即使像EF这样的东西也通过NuGet包进行传递。您甚至可以在像MyGet.org这样的地方免费托管它，我使用它并且效果非常好。 http://nuget.org/
2
我使用 git 子模块 来实现这一点。
  1. 为每个想要在解决方案之间共享的模块（项目）创建一个新的 git 仓库。我通常还会在同一个 git 仓库中的另一个项目中包含该项目的单元测试。
  2. 将 子模块 添加到将使用共享代码的解决方案的 git 仓库中。添加子模块会创建到外部仓库特定提交的链接。当子模块中的代码被更新时，您将能够将更新拉到您的父级解决方案中，这本质上等同于更新对子模块提交的引用。我发现使用像 SourceTree 这样的应用程序更容易可视化这个过程。
  3. 添加子模块并拉取最新提交将在父级解决方案文件夹中创建共享项目的副本。通过右键单击解决方案并选择“添加现有项目”将该项目导入到父级 Visual Studio 解决方案中。
  4. 通过右键单击项目并选择“添加引用”，在“解决方案”选项卡中找到共享项目，向其他将使用它的项目添加对共享项目的引用。
现在，共享项目已包含在解决方案中，您将能够推送和拉取子模块的更改，并自动将这些更改合并到解决方案中。您还将能够在引用子模块的其他 git 仓库中看到更改。
0

是的，将需要共享的代码放在一个单独的类库项目中，构建它并将从此构建创建的DLL引用到您的其他项目中。

-1

最好将共同部分提取到一个单独的项目库中，并将该项目的引用添加到所有解决方案/依赖项目中。

否则，您可以作为链接添加代码/文件/项。

3
链接损坏。 - benderto
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接