Duncan Mackenzie
Microsoft Developer Network
2003 年 10 月 PDC
摘要：本文是将由 Addison Wesley 出版的《Essential ClickOnce》一书中一章的草稿，在本文中，Duncan Mackenzie 介绍了“ClickOnce”如何简化了 Whidbey 应用程序的客户端部署。
目录
简介
.NET 下现有部署的改进
ClickOnce 的基本概念
生成一个简单的 ClickOnce 示例
Longhorn 中的 ClickOnce
小结
简介
虽然 Web 应用程序在许多方面都存在限制，但是在过去的几年中仍然生成了大量的 Web 应用程序，而且将来还会继续开发更多的 Web 应用程序。与 Rich Client 体验相比，为什么公司要选择基于 Web 的解决方案呢？有多种原因，但是我听到的最主要原因是部署。
当公司决定为其职员创建新的应用程序时，不管设计何种类型的系统，讨论的话题最终会转到部署问题上。需要将系统分发给目标用户，并且需要有一个合适的计划来处理持续更新问题（错误修复、新功能发布等）。多年的桌面应用程序分发经验使大多数开发人员和 IT 人员对客户端部署所带来的痛苦都深有感触，最后认为 Web 应用程序是一种比较简单的途径。当然，使用基于浏览器的 Web 应用程序与使用 Rich Client 应用程序相比是要付出一些代价，但是对部署的恐惧通常使得这些代价变得可以接受。我们真正需要的是这样一种用于部署客户端应用程序的模型，即，它像部署 Web 应用程序一样简单和安全，并且无需以降低应用程序的功能作为代价。“ClickOnce”就具有这样的功能。
“ClickOnce”是下一版的 Microsoft® Visual Studio® .NET 和 Microsoft® .NET Framework 中的一组功能的开发代号。它使我们可以创建桌面应用程序，能够通过安全的、系统控制的安装程序来部署创建的应用程序，并且可以根据需要通过某个中央位置自动对其进行更新。在开始介绍 ClickOnce 的功能并引导您逐步生成一个示例之前，我将讨论一些当前在客户端部署中存在的问题以及使用基于 Web 的解决方案的不利方面。
为什么客户端部署这样困难？
ClickOnce 可以简化客户端部署，但这意味着什么？ClickOnce 可以使我们避免什么问题？客户端部署是很困难的，因为它发生在众多客户端的每一个上，并且可能在很多位置发生，而在所有的目标计算机上，您的代码和所有相关组件都必须工作。
以一个具有 10,000 个座位的中等规模的应用程序部署（对于公司内部的业务应用程序来说，这很平常）为例。对于桌面应用程序，这意味着有 10,000 台不同的计算机，每台都可能包含略微不同的软件配置组合。对于 Web 应用程序，可能部署在一台服务器上，也可能部署在一组小规模的计算机“Web 区”上，也就是说，部署的范围存在很大差异。因此，在每种情况下，您都需要确保您的代码：
- 运行在每台目标计算机上。
- 不会在安装时破坏任何现有软件。
- 不会在将来安装任何软件时被破坏。
如果要处理 10,000 台计算机，则这一任务是很恐怖的。它对于为了包含所有可能的软件组合而进行的测试会产生什么影响？我最后想到了两个单词，就是广为人知的“DLL Hell”，安装或删除一个应用程序的 DLL 会破坏另一个应用程序。虽然有许多方法可以降低应用程序之间出现冲突的可能性，但是在部署到客户端计算机上时仍然存在这种可能。所有这些问题都使得 Web 应用程序看上去非常引人入胜。毕竟，Web 应用程序上一次破坏您的桌面是在什么时候？
第一次安装软件或者将来安装任何更新也是一种挑战。对于 Web 服务器，您可以手动进行安装，指定某人在每台计算机上运行安装程序（对于 10,000 个客户端来说，这是不可行的）。处理大量客户端时，您可能需要依赖用户，由他们执行某些操作来运行初始安装，并在应用程序的生命周期内为每次更新运行新的安装程序。虽然已经在无数场合成功使用了这种方法，但是它增加了应用程序发布和每次更新时的复杂性。
安全性也是应用程序安装中的一个问题。根据本文所讨论的公司的策略，普通用户可能没有足够的权限来运行传统的应用程序安装文件。
注意：Microsoft® System Management Server 和其他类似系统可以帮助缓解在公司范围内部署应用程序的困难，但是它们没有消除我们不希望的客户端安装的不利方面。此外，这类系统一般在高度管理的环境中性能最好，在这种环境中，桌面将按照精确的规范来创建，并且更新将遵循严格的发布过程。
基于浏览器的应用程序的限制
我每天都使用 Web，它在很多方面都是非常出色的，但是基于 Web 的应用程序存在一些限制。基于浏览器的系统具有一些明显的问题。缺少脱机支持本身意味着 Microsoft® Outlook® 的 Web 版对于我来说是不够完善的，并且即便是在最受欢迎的站点上也会看到 Web 应用程序的许多问题。
以这种情况为例：在某个在线购物站点上输入信用卡信息后单击“结帐”或“提交”。我有好多次在这个时候收到一个浏览器错误“无法找到页面”或“服务器不响应”。这会对订单造成什么影响？是成功了还是没有成功？这种问题在 Web 应用程序中是难免的（虽然可以通过电子邮件确认或其他方法来缓和这种问题），因为它不是开发人员的错，而是 Web 的 Thin Client 体系结构存在缺陷。
客户端应用程序也会出现这种问题，但是，大多数情况下我们应该将其视为限制或错误；可以对其进行改进。客户端应用程序的开发人员可以选择在本地保存您的订单并定期重试该交易，或在断开网络连接后查询该交易的状态；而 Web 应用程序没有提供这些选择。本文不准备花更多的时间讨论 Web 应用程序。我确信您有自己的理由要开发和部署 Microsoft® Windows® 应用程序，因此，将着重介绍 ClickOnce 如何使您能够更容易地完成该目标。
ClickOnce 提供了两种模型的优点
针对 Web 进行开发而不是针对客户端计算机进行开发有两个主要原因：
- 第一个原因是需要将您的应用程序限制为具有最基本的常用特性（Web 浏览器），以便适用于几乎任何可以访问网络的设备。Web 应用程序的目标是“普适性”而不是“功能强大”，以牺牲一定的功能为代价换来尽可能多的客户端支持。
- 第二个原因是容易安装和持续更新。在应用程序的维护中，如果能够向单台计算机或一小组计算机应用错误修复，而不是需要将新代码应用在每个客户端上，则可以大大节省时间。
如果您的目标是确保几乎任何设备都可以连接到 Web，则寻求“普适性”是非常重要的；但是，如果您要处理的是一个较窄范围内的目标用户，例如“我公司的职员和合作伙伴”，则“普适性”并不是什么问题。当将目标用户缩减到略低于“任何事物及任何人”范围时，便可以限制目标平台（能够支持 .NET Framework 的 Windows 计算机），然后通过生成完全的桌面应用程序来充分利用该平台。ClickOnce 通过提供上述第二个原因中所述的功能使您可以做到这一点，即易于安装和自动更新应用程序。
在本书的后面内容中，将介绍三种不同的部署模型（Web、ClickOnce 和使用 MSI 的完全客户端安装）之间的关系，以及如何为您的特定应用程序确定最佳选择。而现在，通过下表列出了每个部署模型的功能，并显示了 ClickOnce 如何在传统的 Web 和客户端世界之间充当桥梁作用。
| 功能 | Web | ClickOnce | MSI/客户端 |
| 普适性 | Y | ||
| 自动部署 | Y | Y | |
| 较低的系统影响 | Y | Y | |
| 每个用户都安装/运行 | Y | Y | |
| 丰富的/交互式体验 | Y | Y | |
| 脱机 | Y | Y | |
| Windows Shell 集成 | Y | Y | |
| 安装不受限制 | Y |
.NET 下现有部署的改进
虽然 ClickOnce 是下一版的 CLR 和 .NET Framework 中的新功能，但是托管代码的许多现有方面已经使之成为可能。即使在最初的 1.0 版本的 .NET 中，也已经为应用程序的隔离和零影响部署（通常称为 XCOPY 部署）设计了托管应用程序，使得应用程序的安装和更新比过去更方便。
.NET 第一次发行后，还可以直接从 Web 站点 (http://mysite/myapp.exe) 运行应用程序，从而确保了应用程序始终是最新的。但是，这种方法存在很大的技术限制。Href 式可执行程序（即从某个 HTTP 地址运行的应用程序）经常要求更改客户端的安全性策略（这意味着必须先运行一个 .MSI，应用程序才能工作）。它们也比安装在本地的相同应用程序的运行速度慢，用户的体验也不是很好（当需要从 Web 服务器下载新程序集时，UI 会冻结一段时间），并且它们没有真正的脱机模型。
可供使用的两种自动更新解决方案（Jamie Cool 的“AppUpdater”和 MSDN 上发布的 Updater Application Block）为开发人员和最终用户提供了更好的体验。在这两种解决方案中，应用程序被安装到本地计算机上，因此它们没有 Href 式可执行程序的性能或安全性问题，并且有可能使应用程序支持脱机使用。
本书的附录 A 详细介绍了在仍然使用 .NET Framework 版本 1.1 的情况下所能采用的部署方法。ClickOnce 建立在这一支持层次上，并且使它更简单。
ClickOnce 的基本概念
我们已经讨论了需要更好的 Windows 应用程序部署模型的部分原因，下面将介绍 ClickOnce 如何为此提供一种解决方案。ClickOnce 是 .NET 运行库 (CLR) 中的一组功能与 Visual Studio .NET 中集成的 design-time support（设计时支持）功能的组合。总体上讲，使用该功能以及 IDE 工具可以创建可自动安装和更新的应用程序。您在部署、启动和更新应用程序方面具有很大的灵活性。我将在以后的章节中详细讨论这些主题，在这里也简短介绍一下这些选项。
部署选项
可以从某个 Web 位置、UNC 共享、甚至某个文件位置（例如 CD）将 ClickOnce 应用程序部署到客户端计算机上。当从某个 Web 位置以这种方式部署应用程序时，用户将单击 Web 页上的链接，这将导致下载应用程序并自动安装在客户端计算机上（完成后“开始”菜单中添加有快捷方式而且“添加/删除程序”对话框中添加有一个对应行）。安装完成后，将显示该应用程序，表明经过一段时间后已下载并安装了该应用程序。
或者，也可以运行 ClickOnce 应用程序而不将它们部署到客户端计算机上；可以从某个网络位置（例如 UNC 路径或 http URL）直接启动它们而不影响客户端。以这种方式启动的应用程序将缓存在本地，但是没有对其进行传统意义上的安装。本书的第 3 章“ClickOnce' Scenarios”详细讨论了各种部署选项。
如果您需要进行影响客户端计算机的安装（以便创建文件关联、安装 MSDE 或执行其他类似操作），则仍然可以通过 .MSI 文件处理安装方面的问题。当然，您在常规 ClickOnce 部署过程以外所做的任何事情都会削弱 ClickOnce 的功能，但是如果需要，则确实是合适的。
要使启动的或部署的应用程序能够工作，目标计算机上需要具有 .NET Framework。有多种方式可以在安装之前将 Framework 放到计算机上，或者将其作为安装的一部分，这取决于您的特定情况。第 4 章“Advanced Deployment Concepts”讨论了部署 .NET Framework 的特定主题以及高级安装的一般概念。
更新应用程序
更新与部署选项一样灵活，这使您可以在特定时间（例如应用程序启动时）进行更新，也可以在应用程序开发人员选择调用相应的更新 API 时进行更新。还可以指定某个特定更新是必需的，从而使用户不能忽略可用的更新。这种必需更新功能对于管理持续更新以及确保可以按照一定时间将整个用户库更新为一个新版本是非常重要的。
该更新进程的其他主要功能包括能够在客户端或服务器上进行应用程序版本的回滚。对于服务器回滚，使用此管理功能可以快速删除有缺陷的更新并自动将客户端降级为以前的版本。客户端一侧的回滚对于偶尔连接的客户端来说是一项重要功能；如果这些客户端在连接、更新、断开连接后，只是发现新应用程序版本在其计算机上失败了，则它们可以回滚到以前的版本而不必重新连接。借助所有可用的选项，您可以获得所需的任何特定更新功能，但是这些概念非常复杂，所以我们专门为其准备了一章（第 6 章“Application Updates”）。
清单文件
部署和更新活动可以通过使用一对 XML 清单文件来控制，这些文件说明了系统的组件以及应当发生的部署活动。应用程序清单由开发人员编写（借助于 Visual Studio .NET），其中详细说明了应用程序的文件、相关性以及基本安全性要求。部署清单应由管理员创建（尽管开发人员一定会在开发的早期阶段创建此清单），它详细说明了要如何部署和更新应用程序。每个 ClickOnce 应用程序都涉及到这两个清单文件，因此您在本书的各处都会看到它们及其所有选项，但是第 8 章“Digging into the Manifest files”专门对其进行了详细介绍。
图 1：清单文件一起工作以启用 ClickOnce 应用程序的安装和更新
在本章的后面，当介绍生成一个简单的 ClickOnce 应用程序时，您将看到通过 Visual Studio .NET 创建的基本清单文件对的内容。请注意，清单文件没有在名为“Whidbey”的下一版 Visual Studio .NET 代码的 PDC 版本中出现，但是该功能将存在于将来的版本中。
安全性概念
在 ClickOnce 以前，安全性是 Href 式可执行程序在客户端计算机上正确运行时面临的最大障碍之一，而且对于 ClickOnce 应用程序，它仍然是一个重要概念。幸运的是，应用程序所允许使用的安全性“沙箱”的大小已经增加了，此沙箱的边界也更易于理解和浏览。由于 ClickOnce 应用程序的自动安装和自动更新功能，它们可以支持安全的部署模型。部署的或自动下载的代码在其可以访问的信息以及可以执行的操作方面受到限制。不管应用程序是从 URL 启动的还是从 CD 部署的，都不能认为它对目标计算机具有完全信任。
虽然自动更新应用程序的默认沙箱的限制已经减少，但是直到现在为止，仍然很难解决仅发生在降低了安全性的情况下的问题。Visual Studio .NET 的 Whidbey 版本使您可以在 IDE（附加了调试工具）中降低了安全性的情况下运行您的应用程序。这一新功能使您可以在开发应用程序时模拟各种安全性设置和限制，而不必将应用程序部署在一台测试计算机上来查看任何安全性问题。
第 5 章“Security in 'ClickOnce' Applications”介绍了不同部署选项的默认安全性限制，并对如何在这些限制范围内进行编程给出了一些指导信息。如果您的应用程序无法在默认限制集中运行，第 5 章还讨论了如何调整安全性策略并由管理员将其分发给客户端计算机。对于不可能进行或部署安全性策略更改的那些情况，提供了称为 Permission Elevation（提升权限）的新安全性功能，第 5 章也介绍了该功能。它使用户可以对特定的应用程序做出信任判定。
Visual Studio 集成
ClickOnce 是 Whidbey 的主要功能，这意味着除了说明和支持它外，还将其紧密集成到 Visual Studio .NET 的 Whidbey 版本中。使用属性对话框，可以指定各种 ClickOnce 信息（这些信息将用于创建前面讨论过的两个清单文件），包括发布细节（请参阅图 2）。
图 2：您可以在此属性对话框中或作为发布应用程序时运行的向导的一部分来指定文件应当发布到（以及用来进行访问）的位置。
Visual Studio .NET 集成所扩展的不仅仅是在 IDE 中配置您的发布和更新细节。您还可以从 IDE 中直接发布应用程序，即，从 Project（项目）菜单中单击 Publish（发布），然后通过一个快速向导设置各个选项。将在本章的后面逐步介绍此过程，但使用起来非常简单。
Visual Studio .NET 还有另一项强大功能，虽然不是专为 ClickOnce 用户设计的，但是通过它也可以在您所希望的任何安全性上下文的 IDE（附加有调试器）中运行您的应用程序。此功能可以真正帮助您理解应用程序将在什么样的安全性限制下运行。它还可以帮助您使用 Visual Studio .NET IDE 的整套工具正确调试与安全性相关的问题。
生成一个简单的 ClickOnce 示例
我们已经介绍了 ClickOnce 的基本概念，下面将给出一个示例。本书的后面将有更高级的示例，但是现在，我将着重介绍一个比较简单的应用程序，它的任何实质要求都没有超出 .NET Framework。
注意：要提醒的是，这些指令、屏幕快照和其他详细信息是基于 Whidbey 的 PDC 2003 版和 .NET Framework 的对应版本。用户界面元素和实际的详细步骤可能会随时间发生变化。
对于该示例的第一个“版本”，我将从一个完全空的应用程序开始。（不可能找到比这更简单的，对吧？）然后，对于第二个版本，我将添加一些简单的功能，以便您可以看到自动更新功能和分发更新的基本过程。
要求
此示例的实际要求仅为：
- 开发计算机上具有 Visual Studio .NET 的 PDC 版本。
- 一台可以在其上放置文件和创建目录的可用 Web 服务器。
- 一台安装了 .NET Framework 的 PDC 版本的客户端计算机。
如果仅使用一台计算机实现所有操作，则其上应当具有您所需的一切。如果您的 Web 服务器为 Microsoft® Windows Server™ 2003，则可能需要进行一项很小的配置更改。默认情况下，Windows Server 2003 会禁止下载任何具有已知文件扩展名的文件。如果准备使用此服务器来发布 ClickOnce 应用程序，则您应当更改 Microsoft® Internet 信息服务 (IIS) 的设置以允许下载具有 .deploy 和 .manifest 扩展名的文件。Microsoft Knowledge Base 文章 327283（英文）中论述了此问题，其中讨论了如何向您的 IIS 设置中添加新的文件类型（以及关联的扩展名）。对于 .deploy 文件类型，建议使用一种 MIME 类型“application/deployment”来注册它。
创建应用程序
正如前面提到的那样，对于第一个版本，我只是生成并发布了一个空应用程序。您可以通过单击 New Project（新项目）并选择 Windows Application（Windows 应用程序）项目类型来创建自己的空应用程序（请参阅图 3）。此时，您选择的语言并不重要，我将为第二个版本提供用 C# 和 Microsoft® Visual Basic® .NET 编写的代码，所以您可以选择自己喜欢的语言。
图 3：创建一个新的空 Windows 应用程序项目
现在，不添加任何内容，我将为新应用程序配置部署设置。
配置部署选项
Project Properties（项目属性）对话框与 Visual Studio .NET 2003 中的对话框相比已经有了很大变化，其中包含为您的应用程序的 Publishing （发布）设置添加了一个属性页。通过 Project（项目）菜单中的 <name of your project> Properties（<您的项目名称> 属性）菜单项打开属性对话框，或者在解决方案浏览器中您的项目上单击鼠标右键，然后单击 Properties（属性）菜单项。单击左侧的 Publish（发布），您将看到一组非常有趣的 alpha 版选项（如前面的图 2 中所示）。
注意：通常不会使用此属性对话框进行基本的 ClickOnce 设置，而是将部署位置和安装模式选项作为发布向导的一部分进行设置，您选择发布应用程序时该向导将运行（如稍后的图 6 中所示）。需要使用此 Project Properties（项目属性）对话框来设置高级选项，因此我决定在此对话框中设置我的所有属性，以便可以一次完成所有设置。
指定您的应用程序的部署位置（在 Publish my application to ... [将应用程序发布到] 提示下的文本框中），默认位置为 http://localhost/...。如果您的 Web 服务器不支持通过其 Web 地址进行连接，则还可以指定一个与同一 Web 文件夹 (\\duncanmawhidbey\wwwroot$\sampleapp) 相对应的文件位置，或者指定一个 FTP 地址。对于实际项目，我建议您考虑一下要在此设置中使用的服务器名称，因为它是存储在项目文件中的，并且将随项目一起移动到不同的计算机上。如果使用服务器的真实名称，则即使它恰好是安装 Visual Studio .NET 的计算机，您也可以继续指向同一 Web 服务器，哪怕您要在不同的开发计算机之间移动。或者，如果操作的项目具有多个开发人员，则您可能不希望使用共享的 Web 位置。通过指定基于本地主机的 URL，每个开发人员都可以运行自己的 IIS 实例，而无需在每次发布应用程序更新时更改 URL。
下一步，请确保将 Install Mode（安装模式）单选按钮（它反应了在以下两种情况之间做出的选择：从某个网络位置启动应用程序和在本地安装应用程序并从某个 Web 位置自动进行更新）设置为 Install the application...（安装应用程序）。对于本示例应用程序，我希望显示一个以常规“Windows 应用程序”样式安装的系统。确保选中为发布的应用程序创建 Web 页的选项，并且在 Web 页名称文本框中输入适当的名称。我喜欢使用“default.htm”，以使其成为发布文件夹的默认页面，但您可以输入自己希望使用的任何文件名。
单击 Application Updates...（应用程序更新）按钮以设置所需的更新频率和选项（请参阅图 4）。
图 4：Application Updates（应用程序更新）对话框使您可以指定应用程序何时以及采用何种频率检查源位置处的新版本。
两个按钮设置 Required update（必需的更新）和 Update from...（更新自）分别用于将应用程序的更新配置为强制性的以及使用与以前的版本不同的更新位置。请按照图 4 进行设置（如果尚未设置成这些值）并关闭 Application Updates（应用程序更新）对话框。
通过单击 Prerequisites（前提条件）按钮，您可以指定应用程序运行所需的基本组件（请参阅图 5）。如果将组件指定为前提条件，这会导致将它们编译到安装程序中，这些安装程序会在运行应用程序之前先在目标计算机上运行。对于本示例，我们只选择 .NET Framework 并关闭 Prerequisites（前提条件）对话框。
图 5：在 Prerequisites（前提条件）对话框中指定应用程序的基本要求。
Application Files（应用程序文件）按钮使您可以指定应用程序所需的文件。对于本示例，唯一列出的文件是 our .exe，因此此时它并不是最有趣的选项。
发布应用程序
配置完所有设置后，可以从 IDE 中开始发布该应用程序，方法为从 Project（项目）菜单中单击 Publish（发布）。当然，也可以通过在解决方案浏览器中的项目上单击鼠标右键来发布。此时将启动一个向导（请参阅图 6），该向导使您可以指定或更改已经在 Project Properties（项目属性）对话框中设置的若干选项。
图 6：Publish Wizard（发布向导）使您可以更改在 Project Properties（项目属性）对话框中设置的某些发布选项。
此向导包含三个步骤：一个用于指定位置，另一个用于指定部署类型（启动或安装），最后一个步骤是给出摘要信息。因为已经在 Project Properties（项目属性）对话框中设置了发布选项（请参阅图 2），所以我只是单击 Finish（完成），并观察 Visual Studio 连接到我的 Web 服务器、创建一个新目录和上载一组文件。部署清单放在指定目录的根目录下，其中还有自动创建的 Web 页 (publish.htm) 和 setup.exe 程序（它可以安装我的应用程序的前提条件）。在顶级目录之下，为我的应用程序的当前版本创建了一个目录（/WindowsApplication1_1.0.0.0/，其中包含我的 .exe 文件和应用程序清单），另外还创建了一个目录，用于存储供前提条件安装程序使用的 .NET Framework 可再分发文件。
当 Publish Wizard（发布向导）完成时，将自动启动自动生成的 Web 页（请参阅图 7）。该页面提供了一个指向 .deploy 文件的方便链接，最终用户单击它可以安装/启动 ClickOnce 应用程序。
图 7：自动生成的 Web 页，它看上去与为 ASP.NET Web 服务创建的页面类似，其中提供了指向应用程序的部署清单（.deploy 文件）和应用程序前提条件的安装程序的链接。
如果从某个未安装 .NET Framework 的计算机访问该 Web 页，则应当先单击 click here to install prerequisites（单击此处安装前提条件）链接，再尝试安装实际的应用程序。请注意，如果未安装 Framework，客户端系统将不会知道如何处理 .deploy 文件类型，而只是询问是否要打开或保存该清单。
运行应用程序
为运行该应用程序，我单击了指向 WindowsApplication1.deploy 文件的链接。这时，.NET 运行库开始工作并提示我（请参阅图 8）确认将进行应用程序的安装。
图8：当应用程序需要在您的计算机上进行某些修改时，会提示您确认安装。
注意：之所以需要此确认对话框，只是因为在此情况下应用程序将被添加到“开始”菜单中，而此操作需要得到用户的同意。如果该应用程序不需要添加到“开始”菜单中，则它将运行而不会给出任何提示。
当确认要安装应用程序后，就启动了安装进程，向“开始”菜单中添加了一个快捷方式（请参阅图 9），然后启动该应用程序。“开始”菜单中的快捷方式位于名称 Microsoft 下，因为我从未更新过该示例应用程序的各种属性来提供一个更适当的公司名称，您当然不必局限于此安装位置。
图 9：当配置一个要安装（而不仅仅是启动）的应用程序时，它将在“开始”菜单中创建一个快捷方式。
既然已经成功部署了该应用程序，现在可以进行更改并观察自动更新功能如何工作。
发布应用程序更新
回到示例应用程序，我进行了一个简单的更改，以便清楚地区分初始版本和更新的版本。几乎任何更改都可以显而易见，但是我决定添加一个按钮，它将显示一条简单的消息。如果正在按照本示例进行操作，请对您的应用程序进行一个类似的明显添加，或者使用以下代码片段进行完全相同的添加。
'Visual Basic .NET 代码
Private Sub Button1_Click( _
ByVal sender As System.Object, _
ByVal e As System.EventArgs) _
Handles Button1.Click
MessageBox.Show( _
"祝贺您！", "新版本", _
MessageBoxButtons.OK, _
MessageBoxIcon.Information)
End Sub
//Visual C# 代码
private void button1_Click(
object sender,
System.EventArgs e)
{
MessageBox.Show("祝贺您！",
"新版本",
MessageBoxButtons.OK,
MessageBoxIcon.Information)
}
完成添加后，我进入到 AssemblyInfo 文件中并将应用程序的版本增大为 1.1.0.0。然后，使用 Publish（发布）菜单项为此应用程序启动新的发布进程，同样使用了完全相同的选项。当向导完成时，Web 服务器上将创建有新文件夹来保存此新版本（请参阅图 10），并且部署清单现在将表明每个用户都应当运行 1.1.0.0 版本。
图 10：新应用程序版本要求更改 .deploy 文件并添加新的子文件夹，但是自动生成的 Web 页不需要更新。
当新版本在服务器上可用时，客户端应用程序将开始自动更新自己（基于它们的 Application Update [应用程序更新] 设置）。
客户端更新
由于已经有了可用的新 .deploy 文件，如果运行我们的原始示例，则会发生自动更新。指定更新设置（所选中的当应用程序启动时要更新的项）后，将提示用户确认要升级到新版本（请参阅图 11）。请注意，有关客户端更新的 UI 完全处于测试状态，将来的版本中会将它们替换掉。
图 11：当有可用的更新时，将会通知用户，用户可以选择接受或忽略新版本。
如果用户单击 Yes（是），则会出现一个进度栏（由于这是一个很小的应用程序，因而进度栏显示和消失的速度非常快，您几乎注意不到它），下载并执行新版本。当然，此更新只是使用默认设置执行的；如果您考虑可供使用的所有不同选项，则会具有更多的控制。
注意：如果您在部署 ClickOnce 应用程序时遇到问题，应当利用在目标计算机上创建的日志。查看当前用户的个人设置文件夹（例如，c:\documents 和 settings\duncanma），您会在 \Local Settings\My Applications\ 文件夹下找到该日志。
Longhorn 中的 ClickOnce
下一版本的 Windows 客户端（开发代号为“Longhorn”）将包含应用程序部署的许多更改。但是，如果您使用 ClickOnce 进行开发，则会发现大多数更改都是非常熟悉的，因为 Longhorn 应用程序具有许多与 ClickOnce 应用程序相同的特征和行为。
首先，Longhorn 应用程序要使用的应用程序和部署清单模型与我们所讨论的 ClickOnce 应用程序相同。它们支持的两种部署方法也与 ClickOnce 应用程序相同（部署到本地计算机或从远程位置启动）。ClickOnce 部署的另一个主要方面是使用安全性“沙箱”供部署或启动的应用程序在其中运行，Longhorn 同样提供了这方面的功能。实际上，Longhorn 扩展了这一概念，它的沙箱称为“安全执行环境”，并且默认情况下所有应用程序都可以使用。
Longhorn 将以多种方式扩展 ClickOnce 的当前功能集，其中包括在仍然使用自动部署和更新的同时，使安装能够执行 .MSI 部署的某些更传统的操作。例如，从某个 Web 站点自动部署到用户桌面的 Longhorn 应用程序可以创建文件关联（将自己注册为特定文件类型的处理程序），而无需请求“安全执行环境”以外的附加权限。Longhorn 还添加了保密信息概念（作为应用程序清单的一部分），从而使应用程序的创建者能够说明其信息存储、重复使用以及其他方面的保密策略。当然，在尚未发布“Longhorn”之前，提供的详细信息非常有限，但是显然，使用 ClickOnce 的应用程序（以及开发人员）应当会很容易地转换到 Longhorn。
图 12：运行在 Longhorn 的 PDC 版本上的简单 ClickOnce 应用程序。
如果您希望转到“Longhorn”，则创建一个示例 ClickOnce 应用程序（如图 12 中所示）的步骤并没有什么不同，因此您应当能够按照本章前面所示的相同过程编写并部署一个 Windows 窗体应用程序（假定您同时具有 Longhorn 和 Whidbey）。有一点值得注意，与 Windows Server 2003 一样，您需要将 .deploy 和 .manifest 文件类型添加到 IIS 的 MIME 类型集中，以便能够正确下载。
小结
在本书余下的内容中，您将更详细地了解 ClickOnce，其中包括可能的更新和部署方案、在 ClickOnce 应用程序的安全性限制内工作以及有关开发和管理一个自动更新系统的高级主题。本文是介绍性的一章，希望它能够让您很好地了解 ClickOnce 的基本概念，并使您能够一定程度地了解此技术如何能够帮助您解决自己应用程序的部署问题。
作者简介
Duncan Mackenzie 白天是 Microsoft Visual Basic .NET（英文）和 Microsoft Visual C#（英文）的 MSDN 内容策划，夜晚则是一个孜孜不倦的代码编写人员。据说没有 Earl Grey 茶他就无法做任何工作，希望这不是真的。有关 Duncan 的更多信息，请访问他的站点。