1、DLL 陷阱是一个恶梦， 是一种相当奇怪的问题。相信很多读者都有这样的经验，如果你的软体今天原本运作顺畅，当你安装某个新软体之后，突然间电脑就无法运作了。这绝对不是你的硬体有问题，也不是应用程序的问题，而是作业系统设计上的缺失，这样的问题层出不穷，这通常是因为新的应用程序版本覆盖掉共享的程序库(DLL)，而且往往修改了一些现存应用程序所必需的bug ，这个缺失有了一个名字叫做 DLL Hell (DLL 地狱)。开发人员与系统管理者(以及使用者)面临最大的挑战就是版本更新的问题 ，他们花很多时间在 Windows 登录档 (Regedit) 上试着解决其问题而吃尽苦头 。.在 Microsof
2、t .NET 的世界里，软体元件再也不需要登录(Registry)了！ NET Framework 包含了一些功能，可以实际消除DLL Hell的问题，一项称之为side-by-side 开发模式的新功能。DLL & DLL Hell为什么要使用 DLL (Dynamic Linking Library) - 动态链接库 ?微软当初为 Windows 设计动态链接库主要是撷取它的两项优点：一是动态连结、一是资源共享。资源共享的例子相当显而易见，例如之前曾经提过 Windows 有三个核心的动态链接库：Kernel 主要是负责系统和应用程序的记忆体、行程和执行绪等等的管理工作；User 主要负责
3、使用者介面和讯息的传递；GDI 则负责系统的任何图形绘制、显示等工作。而这些动态链接库所提供的任何函数都可以在必要的时候，让每一个 Windows 环境底下的执行档使用。因为DLL 具备节省记忆体的特性，因此自从 Windows 3.1版以来，它就逐渐成为 Windows 程序设计的主流动态链接库可以资源共享许多大型软体厂商的众多软体产品可能都会有许多可以共用的模组，如果每一套软体各自拥有一份这些可以共用的模组，不仅会造成磁碟空间的浪费，还会让维护这些模组的工作变的既复杂、又凌乱。最好的方法就是仅保持一份程序码，然后透过共享的方式让其他自家的应用程序也可以存取其中共用的模组。共用模组的方法之一
4、就是将模组制作成动态链接库，然后透过软体的安装程序复制到电脑，那么只要安装了其中一套软体之后，其他自家的产品就可以互相共用这一套动态链接库。假设有一函数库 X 供三个应用程序 A、B、C 使用，如果函数库为目的码或原始程序码，则程序编译之后，函数库 X 将会各自成为执行档 A、B、C 的一部份，而将来如果应用程序 A、B、C 同时执行，函数库 X 也会各自占用一份记忆体，显然这是比较浪费记忆体的方式。如果函数库为 DLL 形式，则编译之后，函数库并不会成为执行档的一部分，而将来如果应用程序 A、B、C 同时被执行，则系统只会载入一份函数库让程序 A、程序 B、程序 C 共用，如图。Figure
5、: 程序与 DLL 的共用架构图动态链接库节省记忆体空间动态链接库的资源共享可以节省磁碟空间，而动态载入的连结方式则可以节省记忆体空间。动态链接库采用动态载入的连结方式，动态载入让程序档在需要相关的函数或资源的时候，才载入放置在动态链接库里面的函数或资源，这种方式将可以有效地使用记忆体。不论是节省磁碟空间或记忆体空间，都是希望利用动态链接库所提供的共享函数与系统资源的方式，降低整个 Windows 环境对于硬体设备的需求。DLL 的问题 - DLL Hell动态链接库到底出了什么问题？其实 DLL 的优点( 程序码共用、节省记忆体)，正是其缺点的起源。原本是立意良好的DLL，有一天会变成 DL
6、L Hell，恐怕是当初 DLL 的设计者所始料未及的。而之所以会出现 DLL Hell，也是因为动态链接库可以与其他程序共用函数、共享资源所引起，可谓成也共用、败也共用 。此话怎讲呢？为了要让其他程序共用动态链接库所提供的函数或资源，动态链接库的设计者必须相当谨慎地、缜密地考虑到功能的一致性、回溯相容等细节问题，否则一旦程序所使用动态链接库没有提供所预期的功能，那么使用者就会为此而掉入地狱了。但是要完全考虑到一致性或回溯相容，实在是困难重重，就算真的要做到，也会让利用动态链接库的软体厂商付出相当的成本；但，有必要付出这些成本吗？想想现今的电脑执行环境，与当初微软设计动态链接库的时候已经有相当
7、、相当大的变化。现在的硬体比起当初已经便宜太多、太多了，个人电脑的记忆体都是从64MB 起跳，配备128MB 记忆体的电脑更是比比皆是，而硬碟容量更是以 GB 计算。在如此的硬体环境之下，Windows 程序设计师还需要这么刻苦地考虑共用的问题吗？而且动态链接库的动态载入，其实已经替 Windows 系统节省了不少系统资源，因此微软也重新调整动态链接库的设计理念，而且也针对作业系统进行改善，希望不要再有任何使用者掉入因为共用动态链接库而起的地狱深渊。数种 DLL Hell 的状况让我们想一想，如果某一副程序或物件类别有90%符合我们的需求，却有10% 不符合，怎么办呢？对副程序来说，大概只有修
8、改原始程序码一途。假设程序 A 会使用物件 X，在程序 A 安装到系统时，会同时安装物件 X，假设另一个程序 B 也会使用到物件 X，那么程序 B 直接复制到硬碟中即可正常运作，因为物件 X 已经存在于系统中，这听起来很好，因为程序 A 与程序 B 可以共用物件 X。然而对程序 A 来说，原本在安装后，执行得好好的，却可能在未知的一天变成无法执行，这就是所谓的 DLL Hell。以下为描述 DLL Hell 的两种状态。状况 1. 动态链接库没有善尽回溯相容的责任如果程序 A 使用的是1.0版的物件 X，而程序 B 使用的是 2.0 版的物件 X(通常是因为程序 B 开发的时间较晚，使用较新的
9、版本)，结果会怎样呢？结果在程序 B 被安装到系统时，物件 X 2.0版也必须安装到系统中，此时系统中 1.0 版的物件 X 将会被 2.0 版所取代。在大部分的情况下，物件 X 2.0版相容于1.0版，所以程序 A 依然可以正常运作，但有时候却会出现 2.0 版及 1.0 版不相容的情况，此时程序 A 便无法正常执行了。此种 DLL Hell的起因则是的设计者，原因在于动态链接库没有善尽回溯相容的原则。试着想想 A.exe 需要 X.dll 所提供的功能，但是在新版的 X.dl l 里面，功能竟然被取消了，这时候也极可能发生DLL Hell。但是诚如之前所讨论，有时往往很难保证百分之百的回溯
10、相容，而且目前个人电脑的硬体配备已经不再像以前简陋，因此微软也提出了所谓 Side-By-Side 的动态链接库，让程序都能拥有自己专属的动态链接库，进而减少共用动态链接库以避免这种 DLL Hell 的发生。状况 2. 动态链接库善尽回溯相容的责任, 但动态链接库本身出现 bug另一种情况，物件 X 的提供者确实考虑到版本相容的问题，而根据物件的规格来看，新旧版也的确相容，但程序 A 使用新版的物件 X 就是有问题，毕竟程序 A 并没有与新版的物件 X 一起运作过，谁知道会发生什么情况？ClientServer DLL (X.DLL)Server Codes程序 A 用 X (X 1.0)
11、(原始版 Public SetValue(ByVal Value As Integer)1.0 本) If Value 的标记用来指是 .NET 载入更新版的 Assembly 。例如以下范例设定档会载入 MarineCtrl 版本 5.0.0.1 而非版本 5.0.0.0SummaryThe .NET Framework NET Assembly 自我描述与版本管理功能让 zero-impact 的部署安装成为可能，同时也终结了 DLL Hell 。Application-Private Assemblies (or 被隔离的 assembly) 只能被一个应用程序所使用 - 它不会被其他的
12、应用程序所影响。 隔离的 assembly 让程序开发者对应用程序有着绝对的控制权，开发好的 Application-Private Assemblies 只要部署在和应用程序同一目录即可。透过 Side by side execution 的技术，应用程序只要安装成功之后，就不用担心 DLL 更新版本，或规格的改变， 它允许 一个 assembly 的多个版本在一个机器上同时被安装并执行，而且每一个应用程序都可以要求和不同的 Assembly 版本系结。The .NET Framework 纪录应用程序版本资讯，并在执行应用程序时使用此资讯载入应用程序所需依赖的正确版本的 Assemblies
