你为什么不直接控制你的参考？

Question

我正在为我的组织建立一些新的源代码控制最佳实践，所以过去几天我一直沉浸在像TreeSurgeon这样的事情中。

我看到的一件事是，最好的做法是将您的引用包含在源代码控制树中，但是在一个单独的目录（lib / in tree surgeon）中，而不是直接使用代码，因为它们自然出现在ASP中。 NET项目。

我知道为什么直接在bin文件夹中对它们进行控制是很糟糕的一些原因，但是我想了解大局，包括在下拉代码之后如何将这些引用反馈到ASP.NET项目中来自新机器上的源控制。

提前致谢！

Brian

Answer 1

您希望外部依赖项位于单独的文件夹中，原因如下：

• 您已明确了解该特定外部依赖项中包含的内容
• 您可以添加非构建相关的内容，例如网站链接，文档，示例和其他内容，而不会污染您的项目
• 您可以在多个项目之间共享该依赖关系
• 你不想把构建文物与源混合，因为它不清楚你/你的团队拥有什么以及什么不是
• 您希望在构建期间有明确的步骤来引入外部依赖关系，以确保您可以控制最终包中的内容
• 分支源将创建依赖项的多个副本（如果它们在那里混合）
• 一些新手意外检查另一个版本的文件并弄乱你的外部依赖关系，从而破坏你的项目稳定性的可能性较小

回答你的第二个问题：

我们通常在单独的文件夹中有外部依赖项的副本，但仍在源代码管理下。所有项目引用都使用相对路径指向该文件夹。因此，当人们在新机器上登记时，他们会获得一整套资源以及外部依赖关系，以便为构建产品做好准备。

此外，我们的构建还有一个额外的步骤，可以在源树之外生成干净的drop文件夹。这是我们的部署副本，它包含所有构建工件以及最终产品工作所需的所有源（如.aspx）的副本。这迫使人们真正思考最终产品中需要包含哪些内容。