什么是在.NET应用程序中处理引用的最佳方法

最近在工作中，我们遇到了一个问题，我们标记/分支了一个项目，并且由于指向旧文件夹结构的dll /项目引用而遇到了一些编译问题。

我们为每个项目创建了一个“外部bin”文件夹，并将引用的dll复制到这些文件夹中。这是最好的方法还是有专门的行业标准来处理？

我想说nuget是处理依赖关系的最佳方法。

nuget可以管理版本并自动从本地 nuget服务器下载依赖项。

创建/配置本地服务器非常容易。只需创建一个新的空ASP.NET项目并安装nuget-servernuget包（使用nuget;）。

这也意味着您不必使用TFS检入所有依赖项和/或管理其版本。

事实并非如此-微软表示，处理引用的最佳方法是在一个大型解决方案中构建项目。是的，我知道，他们的确也确实如此。

模式和实践团队将有关TFS 的最佳实践放在一起，但是它适用于一般构建。解决方案设置共有3种类型，“ 1大解决方案”是一种分区方法，这与大多数人习惯于通过依次构建并将工件复制到公共目录来管理构建的方式（.NET并没有帮助）具有服务器范围的“包含”或“库”引用路径），以及“多解决方案”设置，这是“分区解决方案”的更复杂版本。

他们说

In general you should:

    Use a single solution strategy unless the resulting solution is too large to load into Visual Studio.
    Use multiple solutions to create specific views on sub-systems of your application.
    Use multiple solutions to reduce the time it takes to load a solution and to reduce build time for developers.

对于TFS，他们建议在项目中分支任何外部项目，而不是依赖更类似于Subversion外部的工作区映射。就个人而言，我认为他们的建议没有最佳实践，但是我想他们正在尝试最大程度地减少使用引用时遇到的任何构建问题。

我遇到了.NET版本的问题，这些版本试图通过仅构建所需内容来缩短系统快捷方式，每晚执行一次所有工作，并将每个新程序集都复制到目录中，这是每个人（尤其是测试人员）保持同步的最佳方法。请注意，这实际上仅适用于.NET应用程序，C ++应用程序仍可以工作，因为它们没有版本化程序集或类似的方面，这些组件可能导致调用组件出现问题。这种方法效果很好，但是您不能总是假设部分构建是可行的，将整个过程都蒸发掉，然后重建是最安全的。

这取决于解决方案的结构以及版本控制软件的功能。以前，我们曾经在解决方案中保留未建/跳过的项目，该项目中包含文档和专门用于任何第三方引用库的文件夹。由于这是解决方案的一部分，因此可以使用相对路径引用这些文件的路径。在我们移至TFS 2010之后，摆脱了这个项目，只需在团队项目中与主分支平行的解决方案文件夹中添加“支持”目录即可。在这两种情况下，无论开发人员如何配置他们的计算机，库的源代码控制版本最终都位于同一位置。

当使用Subversion进行版本控制时，可以为此目的使用“ externals”属性。这使您可以在当前项目附近的相对路径中保留共享DLL的本地副本。这样，即使您将项目的主目录更改为其他文件夹，也可以通过不变的相对文件路径轻松引用该DLL。外部变量还允许您定义要包括的特定版本。