Visual Studio:如何管理项目间共享的代码

正如其他人所说，您只需在解决方案资源管理器中右键单击解决方案，选择添加>现有项目，并浏览到公共项目的.csproj文件，它将从其原始位置包含在解决方案中。

然而，这有两个问题，这可能是一个问题，也可能不是一个问题，这取决于你的团队的规模:

1. 公共项目将包含在每个解决方案中，并提供解决方案文件的相对路径(即:…'CommonProject' common .csproj)。这意味着所有的开发人员必须有相同的工作文件结构，否则当他们试图打开主项目时，他们会得到错误。

2. 在公共项目被多个项目引用的情况下(比如两个- A和B)，并且在项目A上工作的开发人员必须对公共项目进行更改，作为其任务的一部分，开发人员没有办法知道他们所做的更改是否会破坏项目B，而没有他们实际检查项目B并编译它。随着越来越多的项目引用公共项目，发生这种情况的风险增加到无法管理的地步。

再一次，正如其他人所说，没有"正确"的方法来做这件事。然而，我采取的方法如下:

1. 使用持续集成(如Cruise Control)来管理项目的构建，并将公共项目作为独立项目放在服务器上。

2. 在源代码控制下创建一个目录来存放构建的通用dll。在构建机器上签出此目录，每当构建公共项目时，它将输出DLL复制到DLL文件夹中，并将这些更改提交到源代码控制。

3. 在所有开发人员的机器和构建服务器上使用环境变量来控制公共DLL文件夹的位置，并使用该变量而不是硬编码路径来引用DLL。(即:而不是C:'Source' mycommonprojectdll 'Common.dll，使用$(MyCommonLocation)'Common.dll并将变量'MyCommonLocation'设置为C:'Source' mycommonprojectdll)

4. 对于引用公共DLL的任何项目，在该项目的构建服务器上设置CI触发器以监视公共DLL文件夹。无论何时向它提交更改，构建服务器都应该构建所有使用它的项目。

这可以立即让您知道您是否正在为任何其他项目提交破坏性更改。唯一的缺点是，在这个模型中，消费项目被迫在公共DLL更新完成后立即对其进行更新。另一种方法是在构建通用DLL时根据源代码控制修订版本对其进行版本化，并将每个版本放在通用DLL文件夹下的子目录中。所以你最终会得到:

通用dll
1.0.0.1234
1.0.0.1235
1.0.0.1236

以此类推。这样做的好处是，每个项目都可以通过简单地引用新版本的代码来选择何时对公共DLL进行更新。然而，它有利有弊，因为这可能意味着一些项目使用旧版本的公共代码的时间比他们应该的要长，这可能会增加最终引入这些更改时所涉及的工作。

是

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

微软一直支持一个内置在VS中的开源项目，它叫做NuGet，你可以将你的共享项目作为NuGet文件输出，并在你的其他项目中使用它。

它将在构建时部署包中指定的所有文件。

这就是。net现在支持依赖的方式。您会注意到，即使是像EF这样的东西也是通过NuGet包来实现的。你甚至可以在MyGet.org这样的地方免费托管它。我使用这个，它工作得很好。

我使用git子模块来实现这一点。

1. 为每个你想在解决方案之间共享的模块(项目)创建一个新的git存储库。我通常也会将项目的单元测试包含在一个单独的项目中，但是在同一个git存储库中。
2. 在解决方案的git存储库中添加一个子模块，它将使用共享代码。添加子模块将创建到外部存储库的特定提交的链接。当子模块中的代码更新时，您将能够将更新拉到父解决方案中，这本质上与更新对子模块提交的引用相同。我发现使用SourceTree这样的应用程序更容易可视化这个过程。添加子模块并拉入最新的提交将在父解决方案文件夹中创建共享项目的副本。通过右键单击解决方案并选择"添加现有项目"，将项目导入父Visual Studio解决方案。
3. 通过右键单击项目并选择"添加引用"并在"解决方案"选项卡中找到共享项目，向将使用它的其他项目中的共享项目添加引用。

既然共享项目已经包含在解决方案中，那么您就可以将更改推入和拉入子模块，并且这些更改将自动合并到解决方案中。您还可以看到引用该子模块的其他git存储库中的更改。

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

最好将公共部分提取到单独的项目库中，并将该项目的引用添加到所有解决方案/相关项目中。