DLL地狱-Redux？

Patrick Cauldwell said something very wise today at work.  Here's the gist:

帕特里克·考德威尔(Patrick Cauldwell)今天说的很明智。 这是要点：

Sure, there's no more DLL Hell for the end user.  It's that they've made it hell for the developer.

当然，最终用户不再需要DLL Hell。 这是因为他们让开发人员为难。

It was immediately funny, but a few hours later, it was profoundly true. 

这立刻很有趣，但是几个小时后，这是真的。

He and I are working on a really cool subsystem for our developers that offers a them clean SOA. 

他和我正在为我们的开发人员开发一个非常酷的子系统，为他们提供干净的SOA 。

As an aside, it also uses NAnt 0.8.4 for its builds.  I know I said I was doing command-line builds with DevEnv, but both Patrick and Chris Kinsman insisted I give it another look.  I was HUGE into NAnt a year ago, but got lazy and floated away.  I'm back with a vengance.  The mess of -contribs and bugs is gone and it's fantastic.  It includes a whole series of great new Tasks.  My favorites are foreach, nunit2 and the invaluable solution task.  I'm also using nunit2report which is great, but needs to support multiple input files.

顺便说一句，它还使用NAnt 0.8.4进行构建。 我知道我说过我正在使用DevEnv进行命令行构建，但是Patrick和Chris Kinsman都坚持要给我另一种外观。 一年前，我进入了南特，但是变得懒惰并飘走了。 我回来了。 -contribs和bug的混乱一去不复返了，这太棒了。 它包括一系列很棒的新任务。 我最喜欢的是foreach ， nunit2和无价的解决方案任务。 我也在使用nunit2report ，它很棒，但是需要支持多个输入文件。

Anyway, so this build of NAnt uses and includes assemblies for log4net and NUnit 2.1.3.  I also use log4net and have referenced NUnit 2.1.4 in our project.  We automated the entire build: codegen>build>test>report>email results.  We have a bootstrapper that gets the project into an empty dir and forks to the build file that just came out of CVS.  It's gloriously command-line and marginally Rube Goldbergian. ;)

无论如何，因此此NAnt构建使用并包括log4net和NUnit 2.1.3的程序集。 我也使用log4net并在我们的项目中引用了NUnit 2.1.4。 我们将整个构建过程自动化：codegen> build> test> report> email结果。 我们有一个引导程序，可以将项目放入一个空的目录中，并分叉到刚从CVS中生成的构建文件。 这是光荣的命令行，而Rube Goldbergian则微不足道。 ;)

However, a few weird things happened.  First, these NAnt binaries were compiled on the 1.0 framework, but the NAnt.exe.config was set to allow it to run on Framework 1.1.  However, the lib directory for NAnt had MULTIPLE directories (clever) with different versions of log4net, NUnit, etc, in each directory (frustrating).  I didn't notice this until NAnt tried to run the tests.  NAnt loaded a non-strongly-named NUnit 2.1.3, and by the time my tests tried to request my strongly named 2.1.4 I was getting all kinds of binding errors and stuff.  Same thing happened when my non-strongly-named build of log4net (compiled on 1.1 as version 1.0.13704 something) tried to load into the process space of NAnt's version of log4net (compiled on 1.0 as version 1.0.13704 ALSO). 

但是，发生了一些奇怪的事情。 首先，这些NAnt二进制文件是在1.0框架上编译的，但是将NAnt.exe.config设置为允许其在Framework 1.1上运行。 但是，NAnt的lib目录具有MULTIPLE目录(聪明)，每个目录中都有不同版本的log4net，NUnit等(令人沮丧)。 直到NAnt尝试运行测试，我才注意到这一点。 NAnt加载了一个名称不严格的NUnit 2.1.3，而当我的测试试图要求使用我的强命名的2.1.4时，我遇到了各种各样的绑定错误和问题。 当我的名字不太明确的log4net版本(在1.0上编译为1.0.13704版本)试图加载到NAnt的log4net版本(在1.0上编译为1.0.13704 ALSO版本)的进程空间中时，发生了同样的事情。

Needless to say, this all sounds obvious after the fact, but I needed to sync up my versions.  Certainly I could strongly name things and GAC them, but that kind of is orthogonal to the goal of a build-anywhere-relative-paths-xcopy kind of project.  So, the easiest and safest thing to do in order to maintain my goal of minimal dependancies was to rebuild NAnt on 1.1 with my preferred minor versions of log4net and NUnit via a shared lib.

不用说，这一切在事实之后听起来都是显而易见的，但是我需要同步我的版本。 当然，我可以强烈地命名事物，并用GAC命名它们，但是这种类型与构建build-anywhere-relative-paths-xcopy类型的项目的目标正交。 因此，要维持我的最小依赖关系目标，最简单，最安全的方法是通过共享的lib使用我喜欢的log4net和NUnit的次要版本在1.1上重建NAnt。

So, back to Patrick's point.  The CLR offers some amazing improvements over COM-style and LoadLibrary/GetProcAddress DLL Hells.  Truly.   We have side-by-side assemblies, the GAC, and strong naming.  However, it does put increasing logistical pressure on the developer to define appropriate policies and procedures to balance ease of development with ease of deployment. 

所以，回到帕特里克的观点。 CLR对COM样式和LoadLibrary / GetProcAddress DLL地狱提供了一些惊人的改进。 真的我们有并行的程序集，GAC和强大的命名功能。 但是，这确实给开发人员带来了越来越大的后勤压力，它们要求他们定义适当的策略和过程，以平衡开发的简便性和部署的便利性。

It takes some serious thought to plan this stuff, and arguably it's not possible to get it right the first time. Or the third.  While the underlying support is there in the CLR, certainly the complex issues around dependancy management, both at compile-time and run-time are not going to be solved anytime soon with a nice Visual Studio.NET Add-In.  "File|New|Enterprise-Wide Dependancy, Version Control, and Deployment Management Project", anyone?

计划这些东西需要认真思考，并且说不可能第一次就将其正确。 还是第三。 尽管CLR中提供了基础支持，但肯定不会很快通过好的Visual Studio.NET加载项解决围绕依赖项管理的复杂问题，无论是在编译时还是在运行时。 “文件|新建|企业范围的依赖性，版本控制和部署管理项目” ，有人吗？

翻译自: https://www.hanselman.com/blog/dll-hell-redux