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

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

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

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

提前致谢!

布赖恩

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

您清楚地了解该特定外部依赖项中包含的内容

您可以添加非构建相关的内容,例如站点链接,文档,示例和其他内容,而不会污染您的项目

您可以在多个项目之间共享该依赖项

你不想把构建文物与源混合,因为它不清楚你/你的团队拥有什么以及什么不是

您希望在构建期间有明确的步骤来引入外部依赖关系,以确保您可以控制最终包中的内容

如果它们在那里混合,分支源将创建依赖项的多个副本

一些新手偶然检查另一个版本的文件并弄乱你的外部依赖关系的可能性较小,从而破坏了你的项目的稳定性

回答你的第二个问题:

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

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