添加对 C# 项目的引用以使其与版本控制兼容的正确方法

Posted 2023-02-19

【中文标题】添加对 C# 项目的引用以使其与版本控制兼容的正确方法

【英文标题】：Correct way to add references to C# project such that they are compatible with version control

【发布时间】：2016-03-23 16:50:55

【问题描述】：

在将第三方库或内部开发的库添加到 C# 项目时，我通常只在 Visual Studio 解决方案浏览器中添加引用。但是，这会创建对库的绝对路径引用。当另一台计算机上的其他开发人员检查代码时，他们可能不会在这些确切的文件夹位置中拥有这些库。

Where do you put your 3rd party libraries? 建议将第 3 方库保存在解决方案文件夹（即存储库文件夹）内的文件夹中。这对我来说很有意义。但是，当我添加引用时，它们仍然是绝对路径引用。 Changing C# .dll references from absolute to relative 提供了一个解决方案，但是，手动编辑 .csproj 文件真的可行吗？我读过不建议乱用 .csproj 文件。另外，我在该问题的 cmets 中看到，如果您的库不在项目文件夹之上（所以在我的情况下，我在项目文件夹中创建了一个依赖项文件夹，而不是解决方案文件夹），那么 VS 应该使路径引用相对于默认，但在我的情况下没有发生。

然后是关于内部开发库的问题。就我而言，我有一个实用程序项目，该项目具有我需要在多个解决方案中使用的功能。我宁愿不必手动更新依赖它的每个项目中的库。如果我使用引用的绝对路径，这不是问题，但是使用版本控制会发生什么？在我链接到的第一个问题中，一个较低的答案建议使用一个名为Sync Toy 的程序来确保将库复制到引用它的依赖项文件夹的所有项目中。这是一个明智的选择吗？

最后，当我添加参考时，最后一点可能与适合同一个问题无关，但默认情况下它将库连接到构建时的输出目录。但这意味着当我部署项目时，我必须复制所有这些额外的 dll 文件。有没有办法避免这种情况并将库嵌入到输出 .exe 中？

【问题讨论】：

“当我添加引用时，它们仍然是绝对路径引用” 你是如何添加它们的？在项目中我引用位于解决方案根目录中的 DLL 时，该引用被添加为相对路径 (../Libraries/SomeLibrary.dll)，而不是绝对路径。

@Albireo 我在解决方案资源管理器中右键单击引用，选择 Add Reference，选择 browse，然后导航到 .dll 文件并选择并添加它

这很奇怪，我现在尝试确认它（在 VS 2015 和 2008 中）并且它有效，库的路径是相对的。你在哪里检查路径？ Properties 窗口还是 .csproj XML 内容？前者始终显示绝对路径，即使后者将其存储为相对路径。

@Albireo 我正在检查 Properties 窗口。让我推送项目，看看它是否在另一台计算机上是相对的......

您不需要在另一台计算机上进行检查，只需在文本编辑器中打开 .csproj 并检查引用的 HintPath，它应该以..\ 或.\ 开头。

【参考方案1】：

参考路径，绝对的还是相对的？

当您通过References > Add Reference > Browse > Browse...添加引用时，Visual Studio 会将库的相对路径保存在.csproj 中。 p>

但是，如果您查看 Properties 窗口中的引用属性，Visual Studio 会向您显示库的绝对路径（我不知道为什么有人认为这样做是个好主意）：

这已在 Visual Studio 2008 和 2015 中进行了测试。

公共库，如何分享？

如果您有一个需要在解决方案（而不是项目）之间共享的公共库，我建议尽可能创建your own NuGet feed 并加以利用。

您可能需要远程供稿，而不是本地供稿；有很多工具可以创建和维护一个（例如TeamCity）。

图书馆更新了吗？将其推送到您的内部 NuGet 服务器并享受更新。

移动组件

当我添加引用时，默认情况下它将库连接到构建时的输出目录

嗯，这就是它在 .NET 中的工作方式。

这意味着当我部署项目时，我必须复制所有这些额外的 dll 文件。有没有办法避免这种情况并将库嵌入到输出 .exe 中？

虽然合并一切是可能的（检查ILMerge），但我不推荐它，这不值得麻烦，因为：

如果您必须手动复制内容以进行部署，那么您做错了。您应该创建一个脚本或安装程序（取决于项目类型和您必须执行的操作）以将部署的应用程序作为一个整体移动。

【讨论】：

谢谢，这解决了处理第 3 方库的问题。但是对于多个项目访问的内部开发的库，最佳实践是什么？而且，嵌入库的问题还是这还没有完成？

@Dan 我已经添加了缺失的部分。

看起来像设置一个远程提要 NuGet 服务器需要 IIS，它需要 Windows Server，我认为我们没有...我的假设是对的吗？

NuGet 源是 OData 终结点。任何公开 OData 端点并遵守架构的东西都可以是提要。

我想我几乎可以使用 NuGet。我已经使用 TeamCity 设置了一个服务器，并且能够将我的库安装为一个包。当我将更改推送到我的库存储库时，我看到 TeamCity 确实会自动提取更改并进行新的构建和包。但是，现在当我构建一个使用该包的项目时，我没有看到更改通过（我也尝试拉，但它说它是最新的）。最后有没有我遗漏的步骤？我需要（可以吗？）手动告诉 NuGet 更新我的包？