智能客户端体系结构与设计指南

 

智能客户端体系结构与设计指南 David Hill, Brenton Webster, Edward A. Jezierski, Srinath Vasireddy and Mohammad Al-Sabt, Microsoft Corporation; Blaine Wastell, Ascentium Corporation; Jonathan Rasmusson and Paul Gale, ThoughtWorks; and Paul Slater, Wadeware LLC 相关链接 Microsoft? patterns & practices 库 (http://www.microsoft.com/resources/practices/default.mspx) .NET 的应用程序体系结构：设计应用程序和服务 (http://msdn.microsoft.com/library/en-us/dnbda/html/distapp.asp) 摘要：本章介绍如何在智能客户端和 Windows 平台中最好地使用 .NET Framework 提供的部署功能，并且提供有关如何取舍可用的部署和更新机制的指导。 本页内容 部署 .NET Framework 预先安装 .NET Framework 部署智能客户端应用程序 部署智能客户端应用程序 选择正确的更新方法 智能客户端应用程序在客户端计算机上执行本地处理，因此需要将它们部署到这些计算机上。过去，在客户端计算机上长期部署、更新、维护和卸载应用程序非常困难而且存在很多问题。由于 COM 的缘故，几个问题使得向客户端计算机部署应用程序变得非常困难，包括： ? 与注册表紧密耦合的应用程序。安装 COM 应用程序要求在注册表中注册类和类型库。 ? 非独立的应用程序。除了必须在注册表中注册类和类型以外，应用程序通常还包括位于硬盘上的共享文件以及注册表中包含的配置设置。应用程序不是独立的；相反，它的构成部分分布在计算机中的不同区域。 ? 无法并列部署的组件。无法将同一 DLL 的两个不同版本部署到同一目录中。 这些问题构成了有效部署和维护客户端应用程序的巨大障碍。 Microsoft ? .NET Framework 具有一些能够简化部署 .NET Framework 应用程序的过程的功能。这些功能包括： ? 自我描述的程序集。.NET Framework 程序集包含元数据，以描述引用的所有程序集的版本信息、类型、资源和详细信息（以及其他内容）。这意味着它们不依赖于注册表。 ? 版本控制和并列支持。.NET Framework 对于版本控制具有大量的支持，允许您安装多个版本的应用程序和多个版本的 .NET Framework，以便它们能够并列运行。 ? 相互隔离的应用程序。可以将 .NET Framework 程序集部署到应用程序目录，以供该特定应用程序使用，并且默认情况下将其与其他应用程序单独保存并隔离。这意味着不需要将程序集部署到 Windows 目录或者将其显式注册到注册表中，从而降低了在安装其他应用程序时改写或删除这些程序集的可能性。 ? 全局程序集缓存。如果您希望在同一台计算机上的不同应用程序之间共享代码，则可以将组件部署到全局程序集缓存。全局程序集缓存允许同一程序集的不同版本共存。在引用全局程序集缓存中的程序集时，必须指定程序集的完全限定名，包括公钥标记和版本号。这有助于防止无意中使用组件的不同版本。 ? 针对具有强名称的程序集的编译时程序集的默认运行时绑定。默认情况下，如果程序集具有强名称，则 .NET Framework 会将其绑定到其从属程序集的确切版本。这会降低应用程序脆弱性，因为 .NET Framework 加载的是构建和测试该应用程序时的确切的程序集版本。如果需要，可以显式覆盖该行为。 总而言之，上述更改有助于解决许多过去曾经困扰胖客户端应用程序的部署和维护的基础问题。有关 .NET Framework 如何简化部署的详细信息，请参阅“Simplifying Deployment and Solving DLL Hell with the .NET Framework”，网址为：http://msdn.microsoft.com/library/en-us/dndotnet/html/dplywithnet.asp。 本章介绍用于部署 .NET Framework 本身的选择，然后分析如何部署基于 .NET Framework 的智能客户端应用程序。有许多用于部署应用程序的选择，本章讨论了每个选择，并随后讨论了如何选择最适合您的环境的方法。最后，本章比较详细地分析了用于部署应用程序更新的选择。 部署 .NET Framework .NET 智能客户端应用程序依靠 .NET Framework 工作，因此要求在客户端计算机上部署 .NET Framework。.NET Framework 是使用 .NET Framework Redistributable Package 部署的，后者可从 Microsoft MSDN? 或 Windows Update Web 站点获得。 您还可以从产品 CD 或 DVD 获得该 Redistributable Package。该软件包在 .NET Framework SDK 和 Microsoft Visual Studio? .NET 2003 DVD 上提供。 .NET Framework Redistributable Package 实际上是一个 Windows 安装程序软件包，它被包装到一个名为 Dotnetfx.exe 的自解压缩可执行文件中。Dotnetfx.exe 可执行文件启动 Install.exe，后者执行平台检查，根据需要安装 Windows 安装程序 2.0 版，然后启动 Windows 安装程序软件包（.msi 文件）。 有关使用 Dotnetfx.exe 的详细信息，请参阅“.NET Framework Redistributable Package 1.1 Technical Reference”，网址为：http://msdn.microsoft.com/library/en-us/dnnetdep/html/dotnetfxref1_1.asp。 返回页首 预先安装 .NET Framework 如今，许多企业都选择将 .NET Framework 作为其标准操作环境的一部分进行部署。您可以用两种方法在整个企业中部署 .NET Framework： ? 使用将软件“推”到客户端计算机的技术，如 Microsoft Active Directory? 目录服务的“组策略”功能或 Microsoft Systems Management Server (SMS)。使用“组策略”软件部署通过网络安装软件包，您可以确保用提升的特权安装该软件包。同样，使用企业“推”技术（如 SMS），您可以用必需的权限安装 .NET Framework。要使用“组策略”或 SMS 安装 .NET Framework，首先需要从 dotnetfx.exe 中解压缩 Windows 安装程序文件。有关如何完成该任务的详细信息，请参阅“Redistributing the .NET Framework”，网址为：http://msdn.microsoft.com/library/en-us/dnnetdep/html/redistdeploy.asp。 ? 要求最终用户自己部署 .NET Framework，方法是使用 Windows Update，或者从网络共享、内部 Web 站点或 Microsoft Web 站点下载 .NET Framework 。最终用户将需要在其计算机上具有管理特权才能部署 .NET Framework，这是因为 .NET Framework Redistributable Package 安装程序要求有管理特权才能安装。 随应用程序一起安装 .NET Framework 如果您无法确定哪些计算机预先安装了 .NET Framework，您可以选择仅在需要 .NET Framework 时（换句话说，就是在安装 .NET Framework 应用程序时）才安装它。当您不知道您将向其进行部署的计算机的确切软件配置（因此不知道是否预先安装了 .NET Framework）时，该方法尤其有用。例如，如果您是独立软件供应商 (ISV)，并且开发和打包智能客户端应用程序以便销售给形形色色的客户，则您可能不知道您的客户的计算机是否安装了 .NET Framework。 要确保 .NET Framework 随您的应用程序一起安装，可以使用 setup.exe 引导程序示例。该示例会检查是否已经安装了 .NET Framework，如果尚未安装，则会在安装应用程序之前安装 .NET Framework。 有关使用 setup.exe 引导程序示例的详细信息，请参阅 Deploying .NET Framework-based Applications 的第 3 章，网址为： http://www.microsoft.com/downloads/details.aspx?FamilyId=5B7C6E2D-D03F-4B19-9025-6B87E6AE0DA6&displaylang=en 。 返回页首 部署智能客户端应用程序 当您设计智能客户端应用程序时，应该考虑将如何部署这些应用程序。只要有可能，您都应该努力将任何安装的系统影响降至最低限度。这样做使您可以更紧密地跟踪对应用程序进行的任何更改，并且减轻更新和卸载应用程序的问题。但是，有时您将需要执行更为复杂的安装，例如，当您重用非托管代码组件时，或者当您需要在注册表中安全地存储敏感数据时。 当您部署智能客户端应用程序时，可以使用多种选择。这些选择包括： ? 无接触部署。使用该方法时，您可以将文件复制到 Web 服务器，然后当用户单击相应的链接时，.NET Framework 会自动将应用程序及其从属程序集下载到客户端。 ? 带有应用程序更新存根的无接触部署。使用该方法时，您可以使用无接触部署下载应用程序存根，该存根随后会将应用程序的其余部分下载到本地硬盘。 ? 从文件共享运行代码。使用该方法时，您可以将文件复制到文件共享，然后从该共享中运行应用程序。 ? Xcopy。使用该方法时，您可以将文件直接复制到客户端。.NET Framework 允许应用程序及其所有从属程序集位于单个目录结构中，因此您无须在客户端上注册任何组件。 ? Windows 安装程序软件包。使用该方法时，您可以将应用程序的文件打包到 Windows 安装程序软件包中，然后将该软件包安装到客户端上。 每种方法都有其自己的优点和缺点。要帮助确定最适合您的环境的部署方法，您应该更加详细地分析每种方法。 无接触部署 无接触部署使用户可以通过使用指向应用程序的 URL 链接来访问您的位于 Web 服务器上的应用程序。要使用无接触部署来部署应用程序，您只需要将适当的文件复制到 Web 服务器。当用户通过使用 URL 链接浏览到应用程序的位置时，Microsoft Internet Explorer 将下载并运行该应用程序。应用程序及其从属程序集将被使用 HTTP 下载到客户端，并且被存储在名为程序集下载缓存的特殊位置。当 .NET Framework 确定是否需要下载 Web 服务器上的程序集时，将只检查该文件上的日期-时间戳，而不会检查程序集版本号。如果服务器上的程序集所具有的日期-时间戳不比客户端上的晚，则不会下载这些程序集。 如果您使用无接触部署来部署您的智能客户端应用程序，则需要向用户提供指向 Web 服务器上的应用程序位置的 URL。使用该方法时，客户端计算机上不需要任何安装程序 — 所有代码都将根据需要下载。每当 Web 服务器上发生更改时，都会自动更新您的应用程序。如果文件已经更改，则会根据需要下载较新的版本，就像使用普通的 Web 浏览一样。 无接触部署依靠 .NET Framework 的能力与 Internet Explorer 5.01 或更高版本交互，以检查是否有所请求的 .NET 程序集。在请求期间，会将可执行文件下载到下载缓存中。然后，一个名为 IEExec 的进程将在 .NET Framework 的代码访问安全基础结构提供的安全隔离环境中启动应用程序。 注客户端只有在同时安装了 .NET Framework 以及 Internet Explorer 版本 5.01 或更高版本时，才会尝试运行该应用程序。 如果您决定利用无接触部署来部署使用应用程序配置文件的应用程序，则可能需要配置 Web 服务器目录以便允许下载该应用程序的配置文件，因为默认情况下未启用该功能。请确保仅启用从您的应用程序所在的目录下载配置文件的功能；否则，您可能启用下载专用配置文件的功能并且引入安全风险。 注在使用无接触部署时，实际上会下载配置文件两次：第一次是在检查有无绑定信息时（例如，为了控制应用程序使用的组件的确切版本），第二次是在查找用户特定的配置信息时。 您可以从已经部署的应用程序内使用无接触部署，通过 Assembly.LoadFrom() 方法下载并运行代码。该技术可用于下载频繁更改的代码（如频繁更改的业务规则），或者提供其他某种功能的按需安装。 您可以通过无接触部署运行应用程序的本地化版本。客户端计算机的当前区域性用于自动下载所需的适当资源程序集，以便提供应用程序的本地化版本。 您可以使用 Web 服务器提供的安全性机制来确保无接触部署应用程序的安全。例如，要将对应用程序的访问权限制到 Intranet 上的授权用户，您可以在 Web 服务器中的应用程序目录上启用 Windows 集成安全性。要允许所有用户访问该应用程序，您可以启用对应用程序的目录的匿名访问。 注如果您的 Web 服务器不允许匿名访问或者使用 Windows 集成安全性对客户端进行身份验证，则您的应用程序可能无法下载配置文件。 无接触部署的局限性 对于部署简单的应用程序或者部署更为复杂的应用程序的组成部分而言，无接触部署可能很有用。但是，对于更为复杂的智能客户端应用程序的完整安装而言，它并不是适当的部署方法，原因有以下几点： ? 受限制的默认安全设置 ? 不可靠的脱机功能 ? 没有事务性安装 注.NET Framework 版本 2.0 中的 ClickOnce 技术将无需在安装和运行应用程序之前手动对客户端进行安全策略更改。ClickOnce 将提供一种可配置的机制，以便在从 Web 服务器首次安装应用程序时，自动进行安全策略更改。ClickOnce 还将向智能客户端应用程序提供可靠的脱机功能，并且将使它们可以与 Windows 外壳程序完全集成。 ? 本节详细分析无接触部署的限制。 受限制的默认安全设置 代码访问安全根据应用程序提供的证据向应用程序授权。默认情况下，使用应用程序的位置（用于启动它的 URL）来确定授予它的权限。除非更改了客户端计算机上的本地安全策略，否则只在某种程度上信任无接触部署应用程序，这意味着只会将有限数量的权限授予它们。 默认情况下，使用无接触部署进行部署的智能客户端应用程序将无法执行下列操作： ? 向硬盘写（独立存储除外） ? 将程序集部署到全局程序集缓存 ? 部署或使用非托管代码 ? 部署要求注册或者进行其他注册表更改的组件 ? 与 Windows 外壳程序（具体说来，就是 Start 菜单上的安装图标以及 Control Panel 中的 Add or Remove Programs 项目）集成 ? 访问数据库 ? 与任何其他客户端应用程序（如 Microsoft Office 应用程序）交互 ? 访问 Web 服务或其他位于网络上但不位于部署应用程序的同一服务器上的资源 ? 执行在与部署位置相关联的区域中定义的安全操作以外的其他安全操作 如果您的应用程序要求比默认权限集更多的权限，并且您希望使用无接触部署，则您将必须修改客户端上的安全策略，以便授予应用程序正常工作所需的权限。在部署您的应用程序之前，需要将此类安全策略更改传播到客户端计算机（例如，使用“组策略”、Windows 安装程序软件包或批处理文件）。这些要求减少了无接触部署方法的一些好处。有关部署安全策略的详细信息，请参阅“.NET Framework Enterprise Security Policy Administration and Deployment”，网址为：http://msdn.microsoft.com/library/en-us/dnnetsec/html/entsecpoladmin.asp。 当您设计应用程序时，应该确定您是否能够满足您的智能客户端应用程序的设计规范，并且遵守无接触部署应用程序的不完全信任要求。通常，无接触部署以及从文件共享运行代码提供了易于部署的解决方案，但是可能在某种程度上限制应用程序的功能，以至于它们对于许多智能客户端应用程序而言并不实用。不过，如果您的应用程序不要求任何附加权限，则无接触部署可能是应用程序的理想部署机制。 有关完全受信任的应用程序和不完全受信任的应用程序的详细信息，请参阅第 5 章：安全性考虑事项。 不可靠的脱机功能 使用无接触部署来部署智能客户端应用程序的另一个问题是它们不能可靠地脱机工作。这一问题是由许多因素造成的： ? 程序集的延迟下载。程序集被按需下载并存储在程序集下载缓存（它被作为 Internet Explorer 缓存的一部分进行管理）中。在某些情况下，当您联机运行应用程序时，您可能没有下载该应用程序的所有部分，这将影响应用程序在脱机时完全发挥作用的能力。 ? 程序集可能被删除。因为程序集驻留在由 Internet Explorer 缓存管理的区域中，所以如果该缓存由于某种原因而被清除，则您的应用程序文件将被删除。 ? 应用程序依赖于 Internet Explorer 脱机设置。在尝试脱机运行应用程序时，您必须将 Internet Explorer 设置为在脱机模式下运行，即使您的应用程序不是在 Internet Explorer 内部运行。而且，如果您确实具有连接，但 Internet Explorer 被无意中设置为脱机模式，则不会对服务器进行更新检查。 没有事务性安装 在使用无接触部署时，根据需要将程序集下载到随时可能被清除的缓存中。因此，无法在任何时候都确保本地硬盘上装有所有必要的代码。对于许多组织而言，这种不确定性可能是业务线应用程序所不能接受的。 带有应用程序更新存根的无接触部署 使用无接触部署的主要问题之一是：默认情况下，应用程序从程序集下载缓存中运行，并且只受到不完全信任，除非修改了本地安全策略。这可能限制智能客户端应用程序的功能，包括它的在脱机环境下可靠工作的能力。一种避免该问题的方法是最初使用无接触部署来部署应用程序存根，后者接着自动将该应用程序的其余部分下载并安装到本地硬盘上。该存根将应用程序部署到硬盘上的指定位置，如“C:\Program Files”，因此不会受到 Internet Explorer 缓存的限制。当该应用程序运行时，因为它是从本地硬盘运行的，所以它将被授予完全信任权限，并且在工作时不会受到与不完全信任应用程序相关联的限制。应用程序更新存根还可用于确保在服务器上发生更改时可靠而自动地更新该应用程序。 如果您使用该方法部署您的应用程序，则需要确保修改客户端计算机的 .NET Framework 安全策略，使应用程序存根本身可以用足够的权限运行，以便将应用程序构件下载并存储到本地硬盘上。 设计应用程序更新存根可能非常复杂。为了帮助您，Microsoft 已经创建了 Updater Application Block，您可以将其用作设计您自己的自动更新解决方案的基础。设计 Updater Application Block 的目的是： ? 为 .NET Framework 应用程序实现基于“拉”机制的更新解决方案。 ? 使用加密验证技术，在使用应用程序更新之前验证它们的真实性。 ? 在没有用户干预的情况下执行后部署配置任务。 ? 帮助您编写能够自动将其本身更新为可用的最新版本的应用程序。 图 7.1 显示了 Updater Application Block 的体系结构。 图 7.1 Updater Application Block 体系结构 有关 Updater Application Block 的详细信息，请参阅“Updater Application Block for .NET”，网址为：http://msdn.microsoft.com/library/en-us/dnbda/html/updater.asp。 带有应用程序更新存根的无接触部署支持应用程序的事务性安装。Updater Application Block 可帮助确保应用程序成功地完整安装。要执行事务性安装，您将需要包含相应的代码，以便除了执行自动更新以外，还检查是否已经在本地硬盘上安装了所有代码。这些代码的形式可以是一个清单文件以及用于确定该清单中的每个文件都在本地硬盘上的代码。 通过将无接触部署与应用程序更新存根结合起来，您可以得到许多好处，如简化的部署和更新，以及在完全受信任的环境中运行您的应用程序的能力。上述好处使得这一混合式方法成为部署许多智能客户端应用程序的有用选择。但是，它并非在所有情况下都是理想的选择。您仍然需要向应用程序存根授予足够的权限，以使该存根能够下载应用程序的其余部分。而且，使用该方法安装的应用程序不提供 Windows 外壳程序集成（具体说来，就是与 Start 菜单或 Control Panel 中的 Add or Remove Programs 项目的集成），除非您将该功能构建到应用程序存根中。最后，部署和更新将仅发生在用户的安全上下文中。如果您的应用程序需要向注册表写入，或者需要向文件系统的某个您禁止用户访问的部分写入，则这一限制可能导致问题。 从文件共享运行代码 从文件共享运行代码类似于无接触部署，不同之处在于您向用户提供文件共享而不是 URL，以便其部署和运行应用程序。从文件共享运行的代码按需下载，并且在适当的时候执行。因为该代码是从网络运行的，所以它将作为不完全受信任的应用程序运行，而且，除非您更改了客户端上的安全策略，否则它通常从本地 Intranet 运行并且会获得本地 Intranet 权限集。 从文件共享运行代码具有无接触部署的许多优点和缺点，尽管代码不像无接触部署那样缓存在客户端上。因为从文件共享运行代码具有一些安全限制，所以该方法通常并不适合于部署智能客户端应用程序。 注像无接触部署一样，您可以采用将从文件共享运行代码与自动更新存根结合起来的混合式方法。有关详细信息，请参阅本章前面的“带有应用程序更新存根的无接触部署”。 Xcopy 部署 Xcopy 部署要求将应用程序包含的所有文件复制到客户端计算机，以便运行该应用程序。智能客户端应用程序通常只包含位于目录层次结构中的一个或多个可执行文件、一个或多个 DLL 以及一个或多个配置文件。通过将上述所有文件复制到另一台计算机，您就实质上安装了该应用程序。要卸载该应用程序，只需将所有文件从计算机中删除即可。 如果为安装应用程序只需要修改文件系统，则 Xcopy 方法可能是最佳选择。但是，因为您无法对安装过程进行编程控制，所以 Xcopy 方法不 允许您执行下列操作： ? 将程序集部署到全局程序集缓存（以及维护引用） ? 部署 COM 对象 ? 部署要求注册或者进行其他注册表更改的组件 ? 与 Windows 外壳程序集成 如果您的应用程序要求附加的安装步骤，则您或许会在复制文件之后手动执行上述步骤。例如，如果您需要修改注册表，则可以在目标计算机上编辑注册表或者导入 *.reg 文件，以确保使适当的设置就绪。如果您需要将程序集部署到全局程序集缓存，则可以使用带 /ir 开关的 Gacutil.exe 实用工具，以便将程序集安装到带有跟踪引用的全局程序集缓存中。可以通过使用 /ur 开关在卸载程序集时删除这些引用。 注您还可以在 Windows 资源管理器中使用拖放操作将共享程序集移动到全局程序集缓存文件夹中。但是，您应该避免使用该方法，因为该方法没有实现引用计数。没有引用计数，其他应用程序的卸载例程可能导致您的应用程序所需的程序集被从全局程序集缓存中删除。 Xcopy 部署适合于某些智能客户端应用程序，但是，在许多情况下，因为需要执行一些附加步骤才能使应用程序正常工作，所以使得这一看起来简单的方法变得过于费力。 Windows 安装程序软件包 您可以将要安装的应用程序打包为 Windows 安装程序软件包。该方法使您能够不受限制地在目标计算机上安装任何应用程序，尽管应用程序在运行时会受到安装它的最终用户的安全上下文的限制。 Windows 安装程序软件包十分灵活和强大，因此您可以使用它们安装那些对客户端进行大量配置更改的非常复杂的应用程序。然而，它们也适合于那些具有简单得多的安装要求的应用程序。即使您已经将应用程序设计为在安装时对客户端具有最低限度的影响，您也应该考虑使用 Windows 安装程序软件包，因为它们通过在 Start 菜单和桌面上添加图标以及向 Control Panel 中的 Add or Remove Programs 项目中添加应用程序，与 Windows 外壳程序集成。这一集成使您能够有效地控制安装以及在需要时卸载应用程序。 您可以将下列组件中的任意组件或全部组件添加到 Windows 安装程序软件包： ? 项目输出组 ? 服务文件和文件夹 ? 程序集 ? 应用程序资源 ? 合并模块 ? CAB 文件 ? 依赖项 ? 注册表设置 ? 项目属性 ? 自定义操作 ? 用户界面设计设置 在您创建 Windows 安装程序软件包之后，您会具有多种用于将它分发到客户端计算机的选择，包括： ? 使用企业“推”技术，如 SMS。 ? 使用 Active Directory 的“组策略”功能发布或分配该软件包。 ? 允许用户从媒体、文件共享或 URL 安装该软件包。 通过使用“推”技术来安装您的 Windows 安装程序软件包，您可以对安装何时发生以及在何处发生拥有某种集中式控制。它还使您能够控制企业内的哪些组应该拥有该应用程序或该应用程序的特定版本。例如，您可以确保安装针对特定的用户组在一天中的特定时间发生。但是，请记住，您可能需要大量的硬件和网络带宽（具体取决于应用程序的大小）来确保大规模部署能够高效进行。 Windows 安装程序软件包的最重要的优点之一是：如果您使用“组策略”或 SMS，则不需要用户具有管理权限就可以安装应用程序。Windows 安装程序软件包还自动支持事务性安装。只有两种可能：Windows 安装程序软件包将安装所有文件和配置更改；或者，如果出现了什么问题，则 Windows 安装程序将回滚整个安装。 Windows 安装程序软件包的灵活性意味着它适合于具有任何复杂性的安装：从简单地写文件系统以及与 Control Panel 中的 Add or Remove Programs 项目集成的应用程序，到那些对客户端进行许多重大配置更改的应用程序。 注如果您使用 Windows 安装程序软件包来部署您的应用程序，则无须使用同一方法来部署更新。在许多情况下，将您的应用程序设计为在安装后自动更新自身是比较好的做法。有关如何配置应用程序以便自动进行更新的详细信息，请参阅本章后面的“自动更新”。 选择正确的部署方法 既然有如此之多可用于智能客户端应用程序的部署选择，那么确定适合于您的环境的正确选择可能非常困难。但是，您的应用程序的要求以及您的用户的需要通常将决定最佳的方法。 下表概述了每种部署方法的特性。 表 7.1 智能客户端应用程序的部署方法 无接触部署 带有应用程序更新存根的无接触部署 从文件共享运行代码 Xcopy 部署 Windows 安装程序软件包 可靠的脱机访问 否 是 否 是 是 完全信任应用程序功能 要求客户端安全策略更改 是 要求客户端安全策略更改 是 是 非超级用户安装 是 取决于应用程序的要求 是 是 取决于应用程序的要求和应用程序分发机制 对系统影响小 是 取决于应用程序的要求 是 是 取决于应用程序的要求 Windows 外壳程序集成 否 否 否 否 是 无限制的安装 否 否 否 否 是 事务性安装 否 是 否 否 是 需要修改客户端的 .NET Framework 安全策略 是 — 如果客户端需要在提升的权限下运行 是 — 仅限于应用程序存根。 是 — 如果客户端需要在提升的权限下运行 否 否 在许多情况下，最简单的方法是使用 Windows 安装程序软件包将您的应用程序打包。Windows 安装程序软件包具有高度的灵活性，使您可以安装具有任何复杂性的应用程序。如果您使用企业“推”技术（如“组策略”或 SMS）来部署您的 Windows 安装程序软件包，则还可以在管理安全上下文中安装该应用程序，而无需考虑用户的安全上下文。当您希望使用户可以通过单击 URL 来安装他们的应用程序时，则带有自动更新存根的无接触部署也是一个可行的选择，但是您将必须对目标计算机的本地安全策略进行更改，以确保您的应用程序存根应用程序可以在完全信任权限下运行。 返回页首 部署智能客户端应用程序 在最初部署您的智能客户端应用程序之后，您的工作尚未完成。过一段时间之后，随着您升级应用程序功能并且修复缺陷或解决安全漏洞，应用程序将需要更新。 根据具体情况的不同，您可以使用也可以不使用与部署智能客户端应用程序的方法相同的方法来更新它。例如，如果您最初使用 Windows 安装程序软件包来部署应用程序，则可以使用自动更新来部署更新。您的环境的具体情况通常将决定哪种更新方法最为适合。 部署更新时的一个常见要求是能够联合更新基础结构，以便多个更新不用在由单个实体控制的单个服务器或服务器场上竞争。例如，如果某个 ISV 已经创建了一个在客户的整个企业中部署的智能客户端应用程序，并且该 ISV 发布了该应用程序的一个更新，则该企业可能希望首先在他们的标准操作环境中下载并测试该更新，然后再将其传播到整个企业中运行的所有计算机。通过联合更新基础结构，可以使这样做变得可能。例如，更新服务器可能位于负责从该 ISV 获取更新的客户站点上。在该企业内部运行的客户端可以从本地更新服务器获取更新，但前提是 IT 管理员予以批准。使用该方法，还可以通过减轻单个服务器或服务器场的负载，提高更新基础结构的性能和可伸缩性。 在部署应用程序的更新时，您具有下列选择： ? 无接触部署。更新的程序集被添加到 Web 服务器，以供客户端自动下载。 ? 自动更新。应用程序被配置为自动从服务器下载并安装更新。 ? 从文件共享获取更新。更新的程序集被添加到网络共享，以供客户端自动下载。 ? Xcopy 更新。更新被直接复制到客户端。 ? Windows 安装程序软件包部署。更新了 Windows 安装程序软件包，创建了新的软件包，或者使用修补软件包更新客户端。 对每个选择进行详细分析，以便您能够确定哪个选择最适合于您的环境，将是很有用的。 无接触部署更新 如果您已经使用无接触部署方法部署了简单应用程序或更为复杂的应用程序的组成部分，则通过在 Web 服务器上放置新文件即可更新这些程序集。在应用程序加载程序集之前，.NET Framework 会自动在本地以及在 Web 服务器上检查该程序集的时间戳，以便确定是否需要重新下载该程序集，或者是否可以只是从用户的程序集下载缓存中运行该程序集。 注无接触部署具有许多限制，使其不适合于部署大多数智能客户端应用程序。有关详细信息，请参阅本章前面的“无接触部署”。 尽管使用无接触部署方法发布更新通常非常简单，但您的客户端有可能在升级过程中由于缺少对事务性安装的支持而出现问题。如果您在客户端使用应用程序的过程中更新目录，则客户端最初可能下载旧代码，然后尝试下载自那时起已经更新的其他代码。这可能导致不可预知的结果，并且可能导致您的应用程序失败。该问题最简单的解决方案是将任何重要的更新都部署到 Web 服务器上的单独目录中，然后在部署完成后，将所有链接更改到这一新位置。 注如果您选择使用带有自动更新存根的无接触部署方法来部署您的应用程序，则请参阅下一节“自动更新”。 自动更新 在大多数情况下，修补、重新打包和更新应用程序的最佳方法是将更新基础结构构建到应用程序本身内。在此情况下，可以将客户端应用程序设计为自动从服务器下载并安装更新，并且由 IT 管理员将这些更新发布到服务器以供客户端获取。要达到此目的，您可以在应用程序中包含相应的代码以便该应用程序能够执行下列操作： ? 自动检查是否有更新。 ? 如果有更新则进行下载。 ? 通过应用这些更新来升级其自身。 当您配置您的应用程序以自动更新时，确保将所有已更新的文件下载到客户端十分重要。当您更新具有强名称的程序集时，这一点尤其重要。调用具有强名称的程序集的程序集必须指定具有强名称的程序集的版本，因此如果您更新具有强名称的程序集，您还必须更新任何调用它们的程序集。 在配置事务性更新时，您可以使用代码来检查是否在本地安装了这些更新，并根据清单来验证它们。通常，您将决定在单独的目录中安装更新，然后或者在成功安装之后删除原始目录，或者保留原始目录不动以提供后备应用程序。 有关自动更新以及 Updater Application Block 的用法的详细信息，请参阅本章前面的“带有应用程序更新存根的无接触部署”。 注自动更新将通过 .NET Framework 版本 2.0 中的 ClickOnce 功能进行简化。作为部署清单的一部分，您将能够指定应用程序是否检查更新以及何时应该检查是否有更新，并且能够指定备用的更新位置。 从文件共享获取更新 您将程序集复制到文件共享时，则应用程序每次运行时，这些程序集都会被下载到客户端并且不会缓存。像无接触部署一样，要更新原来通过从文件共享运行代码部署的应用程序，只需将新代码添加到文件共享。然后，客户端在下次运行时将下载新代码。 Xcopy 更新 如果您原来使用文件复制技术分发您的应用程序，则您可能希望以相同的方式部署更新。无论原来的部署机制如何，当更新比较简单（如对配置文件进行的修改）时，文件复制仍然可能是更新应用程序的最有效方法之一。在这样的情况下，在部署更新时，只需复制新文件，并且删除任何不再需要的旧文件。 通常，您只需通过复制新版本的程序集以覆盖旧版本，更新专用程序集。然而，尽管您可以使用简单的复制操作对具有强名称的程序集进行初始部署，但您无法以这种方式更新具有强名称的程序集并且让您的应用程序（或其他程序集）自动使用该程序集。程序集的强名称存储在引用它的任何程序集的清单中，并且公共语言运行库 (CLR) 将某个具有强名称的程序集的不同版本视为完全不同的程序集。除非您另外指定，否则 CLR 会加载原来构建应用程序时所依据的具有强名称的程序集的同一版本。 Windows 安装程序更新 Windows 安装程序提供了一种用于更新 .NET Framework 应用程序的全面解决方案。它的几项功能经过专门设计，以便解决应用程序更新问题。 Windows 安装程序软件包内置了对版本控制的支持。如果您正确地对应用程序进行版本控制，则 Windows 安装程序软件包能够自动确保更新正确发生，并且您可以指定在安装新的应用程序时是否要删除以前版本的应用程序。 如果您要使用“推”技术（如 SMS）来部署这些更新，则您还可以控制哪些用户将获得更新以及他们何时获得这些更新。如果您要在更广泛地部署更新之前通过特定的用户组测试这些更新，则该功能尤其有用。 如果您计划使用 Windows 安装程序技术升级您的应用程序，则您具有三个用于实现该升级的选择： ? 生成修补软件包 (.msp) 并将其应用于当前安装的应用程序。 ? 更新现有的 Windows 安装程序文件。 ? 创建全新的 Windows 安装程序文件。 通常，如果您要使用 Windows 安装程序来部署更新，则应该使用修补软件包或者更新现有的 Windows 安装程序文件。如果您创建全新的 Windows 安装程序文件，则 Microsoft Windows? 不会将该软件包识别为更新，并且 Windows 的升级管理功能将无法正常工作。但是，在某些情况下，更改是如此广泛，以至于您可能选择放弃该功能并创建新的 Windows 安装程序文件。 注有关使用 Windows 安装程序部署更新的详细信息，请参阅Deploying .NET-Framework-Based Applications，网址为：http://www.microsoft.com/downloads/details.aspx?FamilyId=5B7C6E2D-D03F-4B19-9025-6B87E6AE0DA6&displaylang=en。 返回页首 选择正确的更新方法 在某些情况下，您选择的更新方法由您为应用程序选择的部署方法限定。但是，最适当的方法通常由您要部署的更新的性质决定。例如，您可能只是复制新文件以覆盖旧文件，或者您可能希望更新的应用程序与旧应用程序并列运行。更新可能涉及到将新的程序集添加到全局程序集缓存，或者更改注册表中的配置信息。如果您要部署对具有强名称的程序集的更新，则更新将变得更为复杂，因为调用具有强名称的程序集的每个程序集都将在调用中使用版本号。 表 7.2 概述了可用于更新应用程序的选择以及每个选择所支持的功能。 表 7.2 智能客户端应用程序的更新方法 无接触部署更新 带有应用程序更新存根的自动更新 从文件共享获取更新 Xcopy 更新 Windows 安装程序更新 非超级用户更新 是 取决于应用程序的要求 是 否 取决于应用程序的要求和应用程序分发机制 集中式更新管理 是 是 是 否 取决于应用程序分发机制 在运行应用程序时下载更新 是 是 否 否 否 联合的更新基础结构 否 是 否 否 是 逐个用户/组进行更新 是 是 否 否 取决于应用程序分发机制 事务性更新 否 是 否 否 是 内置的版本控制支持 否 否 否 否 是 在许多情况下，自动更新是部署应用程序更新的最有效的方法。但是，在部署重大更新或涉及到对客户端进行复杂配置更改的更新时，您可能需要使用 Windows 安装程序（它也具有自动版本控制支持的好处）。 小结 部署智能客户端应用程序要比过去部署胖客户端应用程序容易得多，这要归功于 .NET Framework 所具有的功能。但是，要成功完成部署，您需要进行大量重要的选择，包括如何设计您的应用程序以便于部署，以及您为应用程序和 .NET Framework 本身选择哪种部署方法这两个方面。 在大多数情况下，部署应用程序的最佳选择是使用 Windows 安装程序软件包，或者使用无接触部署和应用程序更新存根的组合。您将需要考虑在部署应用程序之后如何有效地维护该应用程序以及部署更新。同样，在大多数情况下，最佳选择很可能是 Windows 安装程序或由应用程序本身控制的自动更新。