【问题标题】:Why does visual studio exclude BIN and OBJ folders at Azure DevOps checkin为什么 Visual Studio 在 Azure DevOps 签入时排除 BIN 和 OBJ 文件夹
【发布时间】:2019-04-14 05:27:30
【问题描述】:
我想知道从 Visual Studio 或 Git-Bash 签入在 Visual Studio 中编码的 Azure DevOps 代码的通用方法是什么。出现的问题是 bin 文件夹包含许多第三方 dll,这些 dll 在构建项目之前保存在源中。那些第三方 dll 是项目所必需的。但是,在签入 Azure DevOps 后,bin 和 obj 不存在。这是由于 .gitignore 和 .gitattribute 文件而发生的。到目前为止,我已经删除了这两个文件并签入了 bin 文件夹。这两个文件的目的是什么。有人可以建议一种解决方法吗?
【问题讨论】:
标签:
.net
visual-studio
azure-devops
azure-pipelines
git-bash
【解决方案1】:
.gitignore 文件指定未跟踪的文件。 .gitattributes 定义每个路径的属性。它们是 Git 的配置文件。
在 Visual Studio 中,bin 和 obj 文件夹用于存储编译器生成的输出(请参阅here)。由于这些输出文件是由编译器生成的,因此您不想在源代码管理中跟踪它们。
如果您的项目需要引用某些 3rd 方 dll,最好的方法是将它们作为 Nuget 包引用(如果有可用于 dll 的 Nuget 包)。如果没有,您可以将它们放在 bin 或 obj 以外的文件夹中,以便在 Git 中跟踪它们。您不应更改 .gitignore 来跟踪 bin 或 obj 文件夹。
【解决方案2】:
.gitignore 旨在从源代码控制中排除事物。例如,如果您在开发文件夹中有一个包含与数据库的连接字符串的文件,您不希望将密码签入源代码管理。将二进制文件签入存储库是一种不好的做法。你应该使用依赖管理系统(如 Nuget、Chocolately、Maven、npm 等)来指定你的依赖并下载它们。您现在这样做的方式是将它们的多个副本签入多个项目,并且无法在一个地方管理它们。正确的依赖管理可能是 .gitignore 的默认版本排除某些文件夹的原因。您还想重新生成 obj 文件夹的所有内容。如果您有旧副本,时间戳会变得奇怪。每次都进行干净的构建意味着从没有任何已编译工件的新副本开始。
【解决方案3】:
继续:即使您确实想签入您的bin 文件夹(正如其他人所提到的,您不想签入),也不要通过删除.gitignore 和.gitattributes 文件来执行此操作。
.gitignore 包含应该不添加到您的存储库的文件列表。这些是不应与团队共享的文件,例如本地配置数据。如果您在.vs 目录中提交 SQLite 数据,您将遇到无数冲突并且无法拉取,因为 Visual Studio 将锁定该文件。
.gitattributes 包含一组配置,尤其是对于行尾。这必须存在于存储库中,以便所有开发人员就设置达成一致,否则您将在空格周围发生冲突。
如果您确实必须(而且您不能)将文件检入您的bin 目录,请恢复您的.gitignore 和.gitattributes。然后用否定模式在.gitignore 中明确列出它们:
!bin/foo.dll
但是 - 正如其他人所评论的 - 这仍然是一个坏主意。
【解决方案4】:
因为他们中的大多数人已经提供了很好的答案。我会为您提供一些关于如何处理 3rd 方 DLL(程序集)的想法
请记住,使用第 3 部分库的理想/最佳方式是通过 NuGet Feed/Packages
在某些情况下,这些 DLL 在 Nuget.org 中不可用。在这种情况下,您可以按照以下步骤在项目中添加引用。
- 在您的项目中创建一个名为
lib 的文件夹
- 在该文件夹中添加 DLL
- 右键单击DLL->转到
Properties,然后将DLL的BuildAction更改为None,将Copy to Output Directory更改为Do not copy
- 最后,添加
lib 文件夹中的引用
因此,当您将项目签入任何版本控制时,lib 文件夹也会被签入,并且在构建期间,引用也会从 lib 文件夹中获取。
再次记住不要使用 bin/obj 文件夹来引用您的 DLL,并且永远不要签入 bin 和 Obj 文件夹。因为这些文件夹将在构建过程中自动生成。
【解决方案5】:
bin 文件夹绝对是存储第 3 方 dll 的错误位置。将它们存储在其他地方并在构建期间将它们复制到 bin 文件夹,或者如果可用,请使用 NuGet 包。
这是一种广泛使用的标准程序,可将 bin 文件夹排除在源代码管理之外。
此外,如果您决定清理您的解决方案,您的 bin 文件夹将被清空,您的第 3 方 dll 将消失。
另外一点,由于您使用azure-devops 标签发布问题,azure-devops 提供了强大的构建和测试管道。这意味着您可以签入您的代码,并且托管的构建服务器(标准场景,IF 您以这种方式设置它)将从源代码管理中提取您的代码并进行构建,运行一些测试,如果一切正常可以压缩你的二进制文件并将它们放在你可以下载它们的地方。现在,您签入的 bin 中自己的 dll 会发生什么情况?当服务器构建您的代码时,它们将被覆盖。那么,为什么要首先检查它们呢?如果服务器进行了清理(它不一定会这样做),那么您的第 3 方 dll 将丢失。