别再掉进D_LL地狱的陷阱里(DLL Hell)~.NET解决之道.docVIP

DLL 陷阱是一个恶梦， 是一种相当奇怪的问题。 相信很多读者都有这样的经验，如果你的软体今天原本运作顺畅，当你安装某个新软体之后，突然间电脑就无法运作了。这绝对不是你的硬体有问题，也不是应用程序的问题，而是作业系统设计上的缺失，这样的问题层出不穷，这通常是因为新的应用程序版本覆盖掉共享的程序库(DLL)，而且往往修改了一些现存应用程序所必需的「bug」，这个缺失有了一个名字叫做DLL Hell (DLL地狱)。开发人员与系统管理者(以及使用者)面临最大的挑战就是版本更新的问题 ，他们花很多时间在 Windows 登录档 (Regedit) 上试着解决其问题而吃尽苦头 。.在Microsoft .NET的世界里，软体元件再也不需要登录(Registry)了！ NET Framework包含了一些功能，可以实际消除「DLL Hell」的问题，一项称之为「side-by-side」开发模式的新功能。DLL DLL Hell 为什么要使用 DLL (Dynamic Linking Library) - 动态链接库 ? 微软当初为Windows设计动态链接库主要是撷取它的两项优点：一是动态连结、一是资源共享。资源共享的例子相当显而易见，例如之前曾经提过Windows有三个核心的动态链接库：Kernel主要是负责系统和应用程序的记忆体、行程和执行绪等等的管理工作；User主要负责使用者介面和讯息的传递；GDI则负责系统的任何图形绘制、显示等工作。而这些动态链接库所提供的任何函数都可以在必要的时候，让每一个Windows环境底下的执行档使用。因为DLL具备节省记忆体的特性，因此自从Windows 3.1版以来，它就逐渐成为Windows程序设计的主流 ˙动态链接库可以资源共享 许多大型软体厂商的众多软体产品可能都会有许多可以共用的模组，如果每一套软体各自拥有一份这些可以共用的模组，不仅会造成磁碟空间的浪费，还会让维护这些模组的工作变的既复杂、又凌乱。最好的方法就是仅保持一份程序码，然后透过共享的方式让其他自家的应用程序也可以存取其中共用的模组。共用模组的方法之一就是将模组制作成动态链接库，然后透过软体的安装程序复制到电脑，那么只要安装了其中一套软体之后，其他自家的产品就可以互相共用这一套动态链接库。 假设有一函数库X供三个应用程序A、B、C使用，如果函数库为目的码或原始程序码，则程序编译之后，函数库X将会各自成为执行档A、B、C的一部份，而将来如果应用程序A、B、C同时执行，函数库X也会各自占用一份记忆体，显然这是比较浪费记忆体的方式。 如果函数库为DLL形式，则编译之后，函数库并不会成为执行档的一部分，而将来如果应用程序A、B、C同时被执行，则系统只会载入一份函数库让程序A、程序B、程序C共用，如图。 Figure: 程序与DLL的共用架构图 ˙动态链接库节省记忆体空间 动态链接库的资源共享可以节省磁碟空间，而动态载入的连结方式则可以节省记忆体空间。动态链接库采用动态载入的连结方式，动态载入让程序档在需要相关的函数或资源的时候，才载入放置在动态链接库里面的函数或资源，这种方式将可以有效地使用记忆体。不论是节省磁碟空间或记忆体空间，都是希望利用动态链接库所提供的共享函数与系统资源的方式，降低整个Windows环境对于硬体设备的需求。 DLL的问题 - DLL Hell ˙动态链接库到底出了什么问题？ 其实DLL的优点(程序码共用、节省记忆体)，正是其缺点的起源。原本是立意良好的DLL，有一天会变成DLL Hell，恐怕是当初DLL的设计者所始料未及的。 而之所以会出现DLL Hell，也是因为动态链接库可以与其他程序共用函数、共享资源所引起，可谓「成也共用、败也共用」。此话怎讲呢？为了要让其他程序共用动态链接库所提供的函数或资源，动态链接库的设计者必须相当谨慎地、缜密地考虑到功能的一致性、回溯相容等细节问题，否则一旦程序所使用动态链接库没有提供所预期的功能，那么使用者就会为此而掉入地狱了。 但是要完全考虑到一致性或回溯相容，实在是困难重重，就算真的要做到，也会让利用动态链接库的软体厂商付出相当的成本；但，有必要付出这些成本吗？想想现今的电脑执行环境，与当初微软设计动态链接库的时候已经有相当、相当大的变化。现在的硬体比起当初已经便宜太多、太多了，个人电脑的记忆体都是从64MB起跳，配备128MB记忆体的电脑更是比比皆是，而硬碟容量更是以GB计算。在如此的硬体环境之下，Windows程序设计师还需要这么刻苦地考虑共用的问题吗？而且动态链接库的动态载入，其实已经替Wi