.net – 为什么不直接控制你的引用？

发布时间：2020-12-16 06:40:54 所属栏目：asp.Net 来源：网络整理

导读：我正在为我的组织建立一些新的源代码控制最佳实践,所以过去几天我一直沉浸在像TreeSurgeon这样的事情中. 我看到的一件事是,最好的做法是将您的引用包含在源代码控制树中,但是在一个单独的目录(lib / in tree surgeon)中,而不是直接使用代码,因为它们自然出现

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

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

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

提前致谢！

布赖恩

解决方法

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

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

回答你的第二个问题：

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

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!