.NET框架与DLL Hell问题的示例分析

这篇文章给大家介绍.NET框架与DLL Hell问题的示例分析，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。

.NET框架与DLL Hell问题：版本问题

从客户的角度，最常见的版本问题就是我们所说的 DLL Hell 问题。简单地讲， DLL Hell 是指当多个应用程序试图共享一个公用组件（如某个动态连接库（DLL）或某个组件对象模型（COM）类）时所引发的一系列问题。最典型的情况是，某个应用程序将要安装一个新版本的共享组件，而该组件与机器上的现有版本不向后兼容。虽然刚安装的应用程序运行正常，但原来依赖前一版本共享组件的应用程序也许已无法再工作。在某些情况下，问题的起因更加难以预料。比如，当用户浏览某些 Web 站点时会同时下载某个 Microsoft ActiveX? 控件。如果下载该控件，它将替换机器上原有的任何版本的控件。如果机器上的某个应用程序恰好使用该控件，则很可能也会停止工作。

在许多情况下，用户需要很长时间才会发现应用程序已停止工作。结果往往很难记起是何时的机器变化影响到了该应用程序。用户可能会回忆起一周前安装了一些东西，但安装与目前看到的状态并没有任何明显的关联。 更糟的是，现在很少有诊断工具帮助用户（或帮助他们的技术支持人员）确定有什么问题。

这些问题的原因是应用程序不同组件的版本信息没有由系统记录或加强。而且，系统为某个应用程序所做的改变会影响机器上的所有应用程序—现在建立完全从变化中隔离出来的应用程序并不容易。 

很难建立一个隔离应用程序的一个原因是当前运行时环境只允许单独版本组件或应用程序的安装。这个限制意味着组件的编写者必须以向后兼容的方式编写他们的代码，否则当他们安装新组件的时候会有终止已有应用程序的风险。实际上，如果可能的话，编写永远向后兼容的代码是非常难的。在 .NET 中，side by side 概念是版本问题的核心。"Side by side" 是在同一台机器上同时运行不同版本的相同组件的能力。使用支持并列的组件，编程人员不必努力维护严格的向后兼容，因为不同的应用程序自由使用某个共享组件的不同版本。

.NET框架与DLL Hell问题：发布和安装

现在安装应用程序是多步过程。一般，安装一个应用程序包括复制许多软件组件到磁盘，和在系统中进行一系列描述那些组件的注册项。 

注册表中的项和磁盘上文件的分隔使复制应用程序和卸载他们非常困难。而且，在注册表中完全描述某个 COM 类所需的许多项之间关系非常松散。这些项常常包括联合类、接口、类型库和 DCOM app ID 的项，不涉及任何放在注册表文档扩展或组件类别的项。要时常手工保持这些项的同步。

***，需要该注册足迹激活任何 COM 类。这极大地复杂了发布分布式应用程序的过程，因为必须到每个客户端的机器进行适当的注册项。

如今另一个共同问题是：对一个正在运行的应用程序进行更新是不现实的。这是 Web 应用程序***的问题，Web 应用程序必须停止工作然后重启动以更新应用程序使用的 COM 类。 

这些问题主要由从组件自己分离传来的组件描述引起的。换句话说，应用程序不是自描述的和独立的。

关于.NET框架与DLL Hell问题的示例分析就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。