第3章 共享程序集和强命名程序集

本章内容：

• 两种程序集，两种部署
• 为程序集分配强名称
• 全局程序集缓存
• 在生成的程序集中引用一个强命名程序集
• 强命名程序集能防范篡改
• 延迟签名
• 私有部署强命名程序集
• “运行时”如何解析类型引用
• 高级管理控制（配置）

　　第2章讲述了生成、打包和部署一个程序集所需的步骤。我将重点放在所谓的私有部署（private deployment）上。进行私有部署时，程序集是放在应用程序的基目录（或者它的一个子目录）中的，是这个应用程序专用的。以私有方式部署程序集，可以对程序集的命名、版本和行为进行最全面的控制。

　　本章的重点是如何创建可由多个应用程序访问的程序集。Microsoft.Net Framework配套提供的程序集就是典型的全局部署的程序集，因为所有托管应用程序都要使用Microsoft在.NET Framework Class Library（FCL）中定义的类型。

　　第2章讲过，Microsoft Windows在稳定性上的口碑较差，主要原因是应用程序要用别人实现的代码来生成和测试。为Windows写应用程序时，它最终要调用由Microsoft开发人员写的代码。另外，许多公司都在制作软件，便于开发人员嵌入他们自己的应用程序中。事实上，.NET Framework鼓励这样做，而且以后将出现越来越多的控件开发商。

　　随着时间的推移，Microsoft开发人员和控件开发人员会修改他们的代码：修改bug、修复安全漏洞、添加功能等。最终，新的代码会进入用户的机器。所以，以前安装好的、正在良好工作的应用程序现在面对的是“陌生”的代码，不再是应用程序最初生成和测试时使用的那些代码。因此，应用程序的行为不再是可以预测的，这造成了Windows的不稳定性。

　　文件的版本控制是一个很难解决的问题。事实上，如果取得其他代码文件正在使用的一个文件，并只是修改其中的一个比特--将某个0变成1，或者将某个1变成0--那么就像使用文件的一个新版本那样，根本无法保证正在使用该文件的代码还能不能正常工作。之所以会那样，一个原因是许多应用程序都在有意或无意地使用了bug。如果一个文件的新版本修复了一个bug，应用程序或许就不能像预期的那样运行。

　　所以，现在的问题是：如何在修复一个文件的bug并添加新功能的同时，保证不会中断一些应用程序的正常运行？我曾对这个问题进行了大量思考，最后的结论是完全不可能！当然，这是一个无法令人满意的答案。分发出去的文件总是含有bug，而公司总是希望推陈出新。必须有一种方式在分发新文件的同时，尽量保证应用程序良好工作。假如应用程序不能良好工作，必须有一种简单的方式将应用程序还原到上一次已知良好的状态。

　　本章将解释.NET Framework为了解决版本控制问题而建立的基础结构。事先提醒一句：要讲述的内容比较复杂。我要讨论CLR集成的大量算法、规则和策略。还要提到应用程序开发人员必须使用的大量工具和实用程序。这些东西之所以复杂，是因为如前所述，版本控制本来就是一个很难应付和解决的问题。