Visual Studio为什么在Azure DevOps签入中排除BIN和OBJ文件夹

Question

我想知道从Visual Studio或已在Visual Studio中编码的Git-Bash在Azure DevOps上检入代码的通用方法是什么。发生的问题是bin文件夹包含许多第三方dll，这些第三方dll在构建项目之前保留在源代码中。这些第三方dll是必需的。但是，在签入Azure DevOps之后，bin和obj不存在。这是由于.gitignore和.gitattribute文件导致的。到目前为止，我已经删除了这两个文件并检查了bin文件夹。这两个文件的目的是什么。有人可以提出解决方法的建议吗？

Answer 1

.gitignore旨在从源代码管理中排除某些内容。例如，如果您的开发文件夹中有一个带有连接字符串的文件，则您不希望将密码签入源代码管理中。将二进制文件检入到存储库中是一种不好的做法。您应该使用依赖项管理系统（例如Nuget，Chocolately，Maven，npm等）来指定您的依赖项并下载它们。现在，您将把它们的多个副本检入到多个项目中，而无法在一个地方进行管理。正确的依赖项管理可能是.gitignore的默认版本排除某些文件夹的原因。您还希望重新生成obj文件夹的所有内容。如果您有旧副本，则时间戳会变得奇怪。每次进行干净的构建都意味着从没有任何编译工件的全新副本开始。

Answer 2

.gitignore文件指定未跟踪的文件。 .gitattributes定义每个路径的属性。它们是Git的配置文件。

在Visual Studio中，bin和obj文件夹用于存储编译器生成的输出（请参见here）。由于这些输出文件是由编译器生成的，因此您不想在源代码管理中跟踪它们。

如果您的项目需要引用某些第三方dll，则最好的方法是，如果有适用于dll的Nuget软件包，则将它们称为Nuget软件包。如果没有，您可以将它们放在bin或obj以外的其他文件夹中，以便可以在Git中对其进行跟踪。您不应更改.gitignore来跟踪bin或obj文件夹。

Answer 3

要继续努力：即使您确实想签入bin文件夹（并且正如其他人提到的那样，也不要这样做），也不要通过删除.gitignore和{{ 1}}个文件。

.gitattributes包含不应不添加到存储库中的文件列表。这些文件不应与团队共享，例如本地配置数据。如果您在.gitignore目录中提交SQLite数据，则将发生无数冲突并且无法拉动，因为Visual Studio将锁定该文件。

.vs包含一组配置，尤其是对于行尾。存储库中必须存在此文件，所有开发人员都必须同意该设置，否则您将在空白处产生冲突。

如果您确实必须（也不必）将文件检入到.gitattributes目录中，请还原bin和.gitignore。然后使用否定模式在.gitattributes中明确列出它们：

.gitignore

但是-正如其他人所评论的-这仍然不是一个好主意。

Answer 4

因为大多数人已经提供了很好的答案。我会为您提供一些有关如何处理第三方DLL（程序集）的想法

请记住，使用第三部分库的理想/最佳方法是通过NuGet Feed / Packages

在某些情况下，这些DLL在Nuget.org中将不可用。在这种情况下，您可以按照以下步骤在项目中添加引用。

1. 在项目中创建一个名为lib的文件夹

1. 在该文件夹中添加DLL

1. 右键单击DLL->转到Properties，然后将DLL的BuildAction更改为None，将Copy to Output Directory更改为Do not copy

1. 最后，从lib文件夹添加引用

因此，当您将项目检入任何版本控制时，lib文件夹也将被检入，并且在构建过程中，引用也将从lib文件夹中获得。

请再次记住不要使用bin / obj文件夹来引用您的DLL，也不要签入bin和Obj文件夹。因为这些文件夹将在构建过程中自动生成。

Answer 5

bin文件夹绝对是存储第三方dll的错误位置。将它们存储在其他地方，并在构建过程中将它们复制到bin文件夹中，或者使用NuGet软件包（如果可用）。 它是一种广泛使用的标准过程，用于将bin文件夹排除在检入源代码管理之外。 另外，如果您决定清理解决方案，则bin文件夹将被清空，并且您的第三方dll也将消失。

另一方面，由于您使用azure-devops标签发布了问题，因此azure-devops提供了强大的构建和测试管道。这意味着您可以检入代码，托管的构建服务器（标准方案 IF 以这种方式设置）将从源代码管理中提取代码并进行构建，运行一些测试，如果一切正常可以压缩您的二进制文件，并将它们放在可以下载它们的位置。现在，您签入的bin中的自己的dll发生了什么？服务器构建您的代码时，它们将被覆盖。那么，为什么要首先检查它们呢？如果服务器进行清理（不必进行清理），则您的第3方dll将丢失。