摘要
.NET框架组件和Windows有一些有趣的API，它们能够建立通过网络自动更新的应用程序。像Windows一样把应用程序编写为自动更新有很多好处，包括方便了用户，减轻网络管理员的维护工作量。自动更新需要注意一些因素，例如发现、安全和文件更替。本文使用了BITS API和一些.NET框架组件的特性，使应用程序可以像Windows一样自动更新。
我喜欢Windows更新特性。我的计算机开启后，85％的时间连接着Internet，象很多人一样，我并没有那么多时间使用网络。Windows XP利用未使用的带宽来比较网络上可用的最新服务包和补丁与本机安装的补丁包，如果发现需要更新，就在后台下载它们，下载完成后它提示有新的内容需要安装。
如果我有选择，客户端的每个应用程序都应该允许自动更新。如果你要应用程序自动更新，必须编写代码来处理发现、下载、安全和替换。
为了处理实际的下载，我将使用Windows的后台智能传输服务（Background Intelligent Transfer Service，BITS）特性。我将使用.NET框架组件的特性来解决自动更新应用程序的安全和更新问题。
困难
为了查找远程服务器上的更新，应用程序必须有查询网络的途径，这需要网络编程、简单的应用程序与服务器通讯的协议。这将在后面的"发现"节中讲到。
下一步是下载。下载看起来不需要考虑联网的问题，但要考虑下载用户请求的文件，以及在没有用户同意时下载大文件。友好的自动更新应用程序将使用剩余的带宽下载更新。这听起来简单，但却是一个技术难题，幸运的是已经有了解决方法。
安全也许是最关键的考虑因素。考虑一下Windows更新特性，它的主要目的是获取安全补丁，想象一下如果Windows更新本身不能验证是否安装了安全的代码。很明显任何从Internet下载并执行代码的应用程序必须有最高的安全级。因此我将讨论怎样使自动更新的应用程序更安全。
最后的考虑因素是使用新版应用程序更换原应用程序的过程。这个问题比较有趣，因为它要求代码运行时将自己从系统删除，有多种办法可以实现该功能。
BITS基础
BITS是一个新的Windows文件传输特性，它通过HTTP异步从远程服务器下载文件。BITS可以使用专门的空闲带宽管理多个用户的多个下载。尽管BITS的使用不限于自动更新应用程序，但是它是Windows更新使用的低层API。由于它对于任何应用程序都是可用的，因而用于做许多实际的工作，包括建立自动更新的应用程序。
以下是基本的想法。应用程序请求BITS管理文件的下载。BITS将工作添加到它的队列并将它与应用程序运行的用户环境关联。一旦用户登录，BITS就使用空闲带宽通过网络慢慢下载文件。实际上BITS技术的代码名称是Drizzle，它描述BITS做什么。
这是怎么实现的呢？这项技术相当复杂。首先，BITS的实现方式与维护按优先级（前台、高、正常、低）队列组织的工作集的Windows服务一样。相同优先级的工作按时间片给定五分钟带宽。队列中一旦没有工作了，就检查下一优先级队列的工作。
前台队列中的工作使用尽可能大的网络带宽，由于这个原因前台优先级只用于响应用户请求的代码。其它的优先级--高、正常和低--都是后台优先级，它们只利用空闲的网络带宽。
为了获得后台特性，BITS监视网络数据包，并不处理自己的包。剩余的包用于计算带宽的活动负载。BITS利用活动负载信息与连接速度和一些静态信息来决定是否继续下载文件，或者为了提高活动用户的流量停止。由于这个原因，用户不会遭遇带宽问题。
对于BITS来说一旦注意到就停止工作的能力非常重要。在很多情况下BITS在下载了文件的一部分后就要放弃网络，甚至连接也一起丢失了。文件下载的部分被保存了，但是当BITS再次使用网络时它从断点开始。恢复的能力是有效果的。
BITS用于从HTTP服务器传输文件。服务器必须与HTTP 1.1兼容，或者至少支持在GET方法中包含Range头，这是因为BITS需要请求文件的一部分。此外，下载的内容必须是静态内容，例如标记文件、代码文件、位图或声音。包含Range头的请求在请求动态内容如CGI、ISAPI或ASP.NET时不做任何操作。
目前BITS有两种版本：1.0和1.5。BITS 1.0随Windows XP发布，有以下特性：可中断的文件下载、下载优先级、可选择的工作完成通知和错误情况、可选择使用对话框或者其它UI元素进行过程通知。BITS 1.5 与Windows .NET Server一起发布，除了有BITS 1.0的特性外，还有可中断的文件上载以及使用Basic、 Digest、 NTLM、 Negotiate（Kerberos） 或Passport认证连接，它与Windows 2000以上版本兼容。
