借助 Microsoft .NET Framework，编程人员便可轻松获取由不同开发人员和公司构建的组件，并将这 些组件集成到自己的应用程序中。但仅当已知哪些组件是构建基础时才能轻松实现上述过程。如果在构建 时对所需组件一无所知（对于加载项，通常会遇到这种情况），那么事情就会变得更加困难。开发人员在 扩展其应用程序时经常会遇到问题。例如，应将加载项存储在数据库中还是磁盘上？开发人员应考虑已知 接口的加载项以获得激活类型吗？使用 AppDomain、AppDomainManager 和 AppDomainSetup 的最佳方法 是什么？
我们将在 CLR 全面透彻解析的两部分内容中解决上述问题及其他问题，方法是在基类库 (BCL) 中引 入新的 System.AddIn 命名空间，我们将在 Visual Studio（代号为“Orcas”）的下一 版本中推出该基类库。您可在 Visual Studio“Orcas”的完全版本发布之前通过社区技术预 览下载此基类库。也可在 公共语言运行库 (CLR) 加载项小组博客中找到这方面的信息。
在本系 列专栏中，我们将向您介绍有关将可扩展性添加到应用程序并随时间推移逐渐将其版本化的开发生命周期 。本月专栏将涵盖开发人员首次将可扩展性添加到其应用程序时所面临的种种挑战，以及 API 如何简化 他们的工作等内容。下个月，我们将集中探讨当宿主更换时仍保持加载项正常运行方面的长期问题：我们 将使用在本专栏中创建的示例应用程序，针对其下一版本对该应用程序做较大改动，然后向您介绍保持原 始加载项正常运行所需的各个步骤。
那么现在就让我们开始探讨可扩展性方面的挑战以及 API 的 优点吧。通过添加 System.AddIn 命名空间和提供有关构建托管加载项模型的指导，CLR 提供了一种解决 方案，不仅可解决编写第一版应用程序时遇到的常见问题，还可为相关人员提供指导以确保应用程序将来 的兼容性。为更好地理解我们将要使用的术语，请参阅“可扩展性术语”提要栏。
可 扩展性术语
宿主 支持可扩展性的应用程序。宿主可以是客户端，也可以是服务器（例如，Excel 、Word、Paint.NET、SQL Server 和 Exchange Server）。
可扩展性 操纵宿主应用程序对象或扩 展宿主功能的机制，有时将其称为自动控制。通常，可通过作为宿主 SDK 一部分发布的对象模型实现上 述机制。
软件开发工具包 (SDK) 一组公共接口 (API) 和相关文档。允许宿主应用程序向加载项 提供服务，反之亦然。该 SDK 可由多种环境中的各方提供。例如，宿主可提供 SDK 以启用特定于宿主的 加载项，而加载项可提供 SDK 以让各种不同的宿主使用该加载项（例如，Windows Media Player） ，此外第三方也可提供 SDK 以让各种不同的宿主和加载项进行通信。
加载项（也称为附件、扩展 件、插件或管理单元） 自定义项；由宿主加载的程序集。也是可自动执行宿主应用程序的某种事物（如 客户端）。可向宿主（服务端）提供附加功能。加载项是自定义代码，通常由第三方编写，可通过宿主应 用程序并根据某个上下文环境（如宿主启动或文档加载）对其进行动态加载和将其激活。加载项通过宿主 公共 API（例如，对象模型或托管类库）扩展宿主应用程序，加载项可通过 SDK 使用该 API。
管 道 使宿主和加载项能够跨版本并通过安全协议进行通信的机制。