[推荐]DotNet应用自动部署技术详解
NET框架提供了一些新的工具简化.NET胖客户端程序的部署，本文阐述了.NET自动部署技术的基础知识，以及防止用户错误下载黑客程序和病毒代码的安全机制。
.NET的自动部署技术构造在.NET框架之中，它使得应用程序能够通过HTTP连接从远程服务器按需下载程序集。有了这个功能，我们可以把胖客户端应用程序发布到一个Web服务器，确保用户下一次使用应用程序时总是自动得到程序的最新版本。设想一下吧：再也不必用CD来发布升级软件，再也不必在电话中向用户反复解释因版本冲突引起的问题！
.NET提供了大量用于实现自动部署机制的功能，例如，.NET知道如何从一个远程服务器下载程序集并把它保存到用户的磁盘缓冲区，而且只有当远程服务器上又有了新的版本时才再次下载——所有这些功能都已经构建到了.NET框架之中。
一、自动部署执行文件
自动部署.NET Windows窗体应用程序的机制可分为两部分，第一部分是自动部署主执行文件，第二部分是允许用户使用应用程序时下载应用的其余部分。
首先我们来看看第一部分。让用户访问主执行文件很简单，只要把执行文件发布到Web服务器，然后把URL告诉用户。例如，假设执行文件的名字为loader.exe，我们可以在企业的Web服务器上创建一个虚拟目录，然后把执行文件的位置
http://192.168.0.1/myapp/loader.exe告诉每一个用户。
用户只要用浏览器打开这个URL，或者在“开始”菜单“运行”输入框输入这个URL，就可以运行loader.exe执行文件。另外，我们还可以创建一个Web页面，加入一个指向loader.exe的HTML HREF标记。
本帖包含图片:
515)this.width=515" border=0>
图1：从Web服务器发布执行文件
下面我们运行一下本文下载包中的一个.NET执行文件。
⑴ 从本文最后下载文件，将文件解压缩到C:\CodeDownloadDemo文件夹。
⑵ 在IIS中创建一个虚拟文件夹CodeDownloadDemo。
⑶ 将虚拟文件夹映射到C:\CodeDownloadDemo\Loader\Bin文件夹。
⑷ 启动IE浏览器，输入下面的URL：http://localhost/CodeDownloadDemo/loader.exe。
看到loader应用程序在浏览器外面运行了吗？应用程序一旦开始运行，即使关闭了浏览器，我们仍可以访问应用程序。对于任何其他.NET应用程序，我们都可以照此办理，只要将它放到Web服务器上，然后用浏览器启动即可 二、UrlScan工具的影响
只要Web服务器上没有安装UrlScan工具，上面的例子就可以毫无问题地运行。UrlScan工具随同IIS Lockdown工具一起发行
，它的功能是禁止向Web服务器发送非法的请求。默认情况下，UrlScan工具认为包含执行文件的URL都是非法的，因此如果Web服务器上安装了UrlScan，对http://localhost/CodeDownloadDemo/loader.exe的访问将被禁止。要检查系统中是否已经安装了UrlScan工具，可以在控制面板中打开“添加或删除程序”，查看“当前安装的程序”清单。
另外，我们还可以修改UrlScan的默认配置，使其允许对执行文件的请求，即修改一下UrlScan用来检测合法/非法请求的INI配置文件。UrlScan的配置文件保存在c:\windows\system32\inetsvr\urlscan\urlscan.ini，下面是该文件的一个片断：
本帖相关代码
[DenyExtensions]
; Deny executables that could
; run on the server
.was_exe
.bat
.cmd
.com
这个配置文件片断中，.exe文件扩展名已经改成了.was_exe，表示.exe扩展名不再被禁止。但必须注意的是，这是解除UrlScan限制的一种简便方法，可能带来安全风险。对于正式为用户提供服务的Web服务器，修改配置之前务必阅读UrlScan的文档或询问网络管理员。
修改UrlScan的INI配置文件之后，必须重新启动IIS服务器，才能让修改生效。例如，在命令行环境中执行IISRESET.exe就可以重新启动IIS服务器。
三、自动部署应用程序的其余部分
前面我们了解了如何自动部署一个执行文件，这种办法对于loader（约45 KB）之类的小型应用程序有效，但通常的应用程序都要大于45 KB，例如，如果应用程序有3 MB，我们不应该让用户每次运行时都重新下载一个3 MB的文件。解决这个问题需要用到.NET自动部署机制的第二部分技术。
和前面的办法相比，一种更好的办法是将主执行程序安装到用户的硬盘上，让这个主执行程序按需下载应用程序的其余部
分。例如，当用户要用到应用程序的Invoicing模块时就下载Invoicing部分，要用到Employees模块时就下载Employees部分（参见图2）。
本帖包含图片:
图2：自动部署一个应用程序
这种类型的部署通常称为“滴流”部署（Tickle Down Deployment）。.NET框架提供了支持滴流布署技术的必要工具类，即System.Reflection名称空间中的Assembly。Assembly类能够从远程服务器下载一个程序集，并在本地缓冲以供以后引用。例如，利用下面的代码可以从http://localhost/CodeDownloadDemo/Loader/下载ModuleA.dll程序集，然后从该程序集创建
EmployeeForm类的实例：
本帖相关代码'指定URL
Dim URL As String
URL = _
"http://localhost/CodeDownLoadDemo/ModuleA.DLL"
'从指定的URL装入程序集
Dim a As [Assembly]
a = [Assembly].LoadFrom(URL)
'获得一个EmployeeForm类的引用
Dim t As Type = a.GetType("ModuleA.EmployeeForm")
'创建窗体的实例，并显示出窗体
Dim o As Object = Activator.CreateInstance(t)
o.Show()
这个代码片断虽然简单，却用到了.NET框架许多值得关注的特性。下面我们就来逐一分析这些特性。
首先，[Assembly].LoadFrom这行代码利用HTTP协议下载一个DLL。在本例中，URL指向localhost，但它同样也可以指向一个远程服务器，例如http://127.0.0.1/myapp。这就是说，我们只要一行代码，并指定一个适当的URL，其余工作就全交给.NET了，不管程序集是本地的还是远程的。
其次，从远程服务器下载得到一个DLL之后，a.GetType这行代码从该DLL提取一个类的引用。注意，类的名称以字符串的形式指定，这意味着，我们可以在运行时临时决定要引用的类的名称。这一点非常重要，因为现在我们可以在运行时决定要引用的是ModuleA.EmployeeForm，还是ModuleA.InvoiceForm。对于VB.NET和C#之类强类型的语言，这一特性显得尤其宝贵，它提供的灵活性是这类语言中非常罕见的。
最后，Activator.CreateInstance(t)这行代码实际创建了EmployeeForm类的一个实例。有了类的实例之后，接下来就可以调用它的方法，设置它的属性。在上面的例子中，我们调用了EmployeeForm类的Show方法。
四、localhost与127.0.0.1的区别
当我们指定的URL是“http://localhost”形式时，前面两节介绍的办法都不会出现问题。但是，如果我们改用http://127.0.0.1形式的URL，就会遇到问题。例如，如果用http://127.0.0.1/CodeDownloadDemo/loader.exe这个URL来打开loader.exe，就会看到类似图3的错误信息：
本帖包含图片:
图3：用127.0.0.1访问时出现的错误
系统的配置不同，具体的错误信息也不同，但不管错误信息到底是什么，用http://127.0.0.1总是可以看到与安全有关的错误信息。
当我们通过一个URL来运行应用程序时，应用程序可能来自一个远程服务器。但是，.NET不能肯定我们想要运行的代码是来自一个可信任的服务器，还是一个受限制的站点。.NET对远程代码采用的安全策略相当复杂，简单地说，.NET把那些不包含句点符号（“.”）的URL视为本地Intranet的URL。默认情况下，.NET允许运行来自Intranet站点的代码。另一方面，.NET把那些包含了句点符号的URL（例如http://127.0.0.1）视为Internet地址，除非明确地设定某个URL是一个安全的位置，否则.NET默认不允许运行Internet URL的程序代码。
安全策略是.NET框架必不可少的组成部分，如果没有安全策略，允许用户将浏览器指向任何URL下载.NET执行文件并自动运行，那只会把网络变成病毒编写者的天堂。有了.NET安全策略，我们就可以保护用户，避免用户下载和运行来源不明的代码。
也许大家已经知道，.NET框架是一个与操作系统紧密集成的系统，安全机制是这种紧密集成特别明显的领域之一。.NET安全策略不仅强大，而且具有高度可配置的特点。下面我们就来了解一下这些安全策略的基本组织，以及如何配置安全策略允许用户从可信任的URL下载执行文件。
五、.NET和IE安全配置
显然，要想让用户通过HTTP协议运行某个执行文件，第一个可以配置安全选项的位置应该是IE浏览器。具体的操作步骤是，启动IE浏览器，转到“工具”菜单，打开“Internet选项”，选择“安全”选项卡，再依次点击“受信任的站点”、“站点”。
我们可以把http://127.0.0.1作为一个受信任的站点加入。注意，必须清除了“对该区域中的所有站点要求服务器验证
（https:）”选项之后，才能将http://127.0.0.1作为可信任站点加入。
本帖包含图片:
图4：添加一个信任站点
现在http://127.0.0.1已经是一个可信任的站点了，如果我们再次用http://127.0.0.1/CodeDownloadDemo/Loader.exe这个
URL来执行loader.exe，应用程序可以启动，不过.NET仍会提示还有一些安全问题有待解决（如图5）。
本帖包含图片:
图5：应用程序在部分受信任的安全上下文中运行
这一次我们看到loader应用程序正式运行了，但有一则提示信息告诉我们应用程序当前在一个部分受信任的安全上下文中运行
，因此应用程序的某些功能可能无法使用。例如，如果我们试图从Employees窗体装入数据，就会看到一个安全错误（如图6所示），这是因为该窗体试图从localhost上SQL Server的Northwind数据库读取数据，但我们还没有授权它可以执行这一操作。
本帖包含图片:
图6：试图访问指定站点之外的资源时.NET提示错误信息
另外请注意，应用程序的标题条上自动加上了表示来源的“127.0.0.1”。
.NET的自动部署技术构造在.NET框架之中，它使得应用程序能够通过HTTP连接从远程服务器按需下载程序集。有了这个功能，我们可以把胖客户端应用程序发布到一个Web服务器，确保用户下一次使用应用程序时总是自动得到程序的最新版本。设想一下吧：再也不必用CD来发布升级软件，再也不必在电话中向用户反复解释因版本冲突引起的问题！
.NET提供了大量用于实现自动部署机制的功能，例如，.NET知道如何从一个远程服务器下载程序集并把它保存到用户的磁盘缓冲区，而且只有当远程服务器上又有了新的版本时才再次下载——所有这些功能都已经构建到了.NET框架之中。
一、自动部署执行文件
自动部署.NET Windows窗体应用程序的机制可分为两部分，第一部分是自动部署主执行文件，第二部分是允许用户使用应用程序时下载应用的其余部分。
首先我们来看看第一部分。让用户访问主执行文件很简单，只要把执行文件发布到Web服务器，然后把URL告诉用户。例如，假设执行文件的名字为loader.exe，我们可以在企业的Web服务器上创建一个虚拟目录，然后把执行文件的位置
http://192.168.0.1/myapp/loader.exe告诉每一个用户。
用户只要用浏览器打开这个URL，或者在“开始”菜单“运行”输入框输入这个URL，就可以运行loader.exe执行文件。另外，我们还可以创建一个Web页面，加入一个指向loader.exe的HTML HREF标记。
本帖包含图片:图1：从Web服务器发布执行文件
下面我们运行一下本文下载包中的一个.NET执行文件。
⑴ 从本文最后下载文件，将文件解压缩到C:\CodeDownloadDemo文件夹。
⑵ 在IIS中创建一个虚拟文件夹CodeDownloadDemo。
⑶ 将虚拟文件夹映射到C:\CodeDownloadDemo\Loader\Bin文件夹。
⑷ 启动IE浏览器，输入下面的URL：http://localhost/CodeDownloadDemo/loader.exe。
看到loader应用程序在浏览器外面运行了吗？应用程序一旦开始运行，即使关闭了浏览器，我们仍可以访问应用程序。对于任何其他.NET应用程序，我们都可以照此办理，只要将它放到Web服务器上，然后用浏览器启动即可 二、UrlScan工具的影响
只要Web服务器上没有安装UrlScan工具，上面的例子就可以毫无问题地运行。UrlScan工具随同IIS Lockdown工具一起发行
，它的功能是禁止向Web服务器发送非法的请求。默认情况下，UrlScan工具认为包含执行文件的URL都是非法的，因此如果Web服务器上安装了UrlScan，对http://localhost/CodeDownloadDemo/loader.exe的访问将被禁止。要检查系统中是否已经安装了UrlScan工具，可以在控制面板中打开“添加或删除程序”，查看“当前安装的程序”清单。
另外，我们还可以修改UrlScan的默认配置，使其允许对执行文件的请求，即修改一下UrlScan用来检测合法/非法请求的INI配置文件。UrlScan的配置文件保存在c:\windows\system32\inetsvr\urlscan\urlscan.ini，下面是该文件的一个片断：
本帖相关代码
[DenyExtensions]
; Deny executables that could
; run on the server
.was_exe
.bat
.cmd
.com
这个配置文件片断中，.exe文件扩展名已经改成了.was_exe，表示.exe扩展名不再被禁止。但必须注意的是，这是解除UrlScan限制的一种简便方法，可能带来安全风险。对于正式为用户提供服务的Web服务器，修改配置之前务必阅读UrlScan的文档或询问网络管理员。
修改UrlScan的INI配置文件之后，必须重新启动IIS服务器，才能让修改生效。例如，在命令行环境中执行IISRESET.exe就可以重新启动IIS服务器。
三、自动部署应用程序的其余部分
前面我们了解了如何自动部署一个执行文件，这种办法对于loader（约45 KB）之类的小型应用程序有效，但通常的应用程序都要大于45 KB，例如，如果应用程序有3 MB，我们不应该让用户每次运行时都重新下载一个3 MB的文件。解决这个问题需要用到.NET自动部署机制的第二部分技术。
和前面的办法相比，一种更好的办法是将主执行程序安装到用户的硬盘上，让这个主执行程序按需下载应用程序的其余部
分。例如，当用户要用到应用程序的Invoicing模块时就下载Invoicing部分，要用到Employees模块时就下载Employees部分（参见图2）。
本帖包含图片:
图2：自动部署一个应用程序
这种类型的部署通常称为“滴流”部署（Tickle Down Deployment）。.NET框架提供了支持滴流布署技术的必要工具类，即System.Reflection名称空间中的Assembly。Assembly类能够从远程服务器下载一个程序集，并在本地缓冲以供以后引用。例如，利用下面的代码可以从http://localhost/CodeDownloadDemo/Loader/下载ModuleA.dll程序集，然后从该程序集创建
EmployeeForm类的实例：
本帖相关代码'指定URL
Dim URL As String
URL = _
"http://localhost/CodeDownLoadDemo/ModuleA.DLL"
'从指定的URL装入程序集
Dim a As [Assembly]
a = [Assembly].LoadFrom(URL)
'获得一个EmployeeForm类的引用
Dim t As Type = a.GetType("ModuleA.EmployeeForm")
'创建窗体的实例，并显示出窗体
Dim o As Object = Activator.CreateInstance(t)
o.Show()
这个代码片断虽然简单，却用到了.NET框架许多值得关注的特性。下面我们就来逐一分析这些特性。
首先，[Assembly].LoadFrom这行代码利用HTTP协议下载一个DLL。在本例中，URL指向localhost，但它同样也可以指向一个远程服务器，例如http://127.0.0.1/myapp。这就是说，我们只要一行代码，并指定一个适当的URL，其余工作就全交给.NET了，不管程序集是本地的还是远程的。
其次，从远程服务器下载得到一个DLL之后，a.GetType这行代码从该DLL提取一个类的引用。注意，类的名称以字符串的形式指定，这意味着，我们可以在运行时临时决定要引用的类的名称。这一点非常重要，因为现在我们可以在运行时决定要引用的是ModuleA.EmployeeForm，还是ModuleA.InvoiceForm。对于VB.NET和C#之类强类型的语言，这一特性显得尤其宝贵，它提供的灵活性是这类语言中非常罕见的。
最后，Activator.CreateInstance(t)这行代码实际创建了EmployeeForm类的一个实例。有了类的实例之后，接下来就可以调用它的方法，设置它的属性。在上面的例子中，我们调用了EmployeeForm类的Show方法。
四、localhost与127.0.0.1的区别
当我们指定的URL是“http://localhost”形式时，前面两节介绍的办法都不会出现问题。但是，如果我们改用http://127.0.0.1形式的URL，就会遇到问题。例如，如果用http://127.0.0.1/CodeDownloadDemo/loader.exe这个URL来打开loader.exe，就会看到类似图3的错误信息：
本帖包含图片:
图3：用127.0.0.1访问时出现的错误
系统的配置不同，具体的错误信息也不同，但不管错误信息到底是什么，用http://127.0.0.1总是可以看到与安全有关的错误信息。
当我们通过一个URL来运行应用程序时，应用程序可能来自一个远程服务器。但是，.NET不能肯定我们想要运行的代码是来自一个可信任的服务器，还是一个受限制的站点。.NET对远程代码采用的安全策略相当复杂，简单地说，.NET把那些不包含句点符号（“.”）的URL视为本地Intranet的URL。默认情况下，.NET允许运行来自Intranet站点的代码。另一方面，.NET把那些包含了句点符号的URL（例如http://127.0.0.1）视为Internet地址，除非明确地设定某个URL是一个安全的位置，否则.NET默认不允许运行Internet URL的程序代码。
安全策略是.NET框架必不可少的组成部分，如果没有安全策略，允许用户将浏览器指向任何URL下载.NET执行文件并自动运行，那只会把网络变成病毒编写者的天堂。有了.NET安全策略，我们就可以保护用户，避免用户下载和运行来源不明的代码。
也许大家已经知道，.NET框架是一个与操作系统紧密集成的系统，安全机制是这种紧密集成特别明显的领域之一。.NET安全策略不仅强大，而且具有高度可配置的特点。下面我们就来了解一下这些安全策略的基本组织，以及如何配置安全策略允许用户从可信任的URL下载执行文件。
五、.NET和IE安全配置
显然，要想让用户通过HTTP协议运行某个执行文件，第一个可以配置安全选项的位置应该是IE浏览器。具体的操作步骤是，启动IE浏览器，转到“工具”菜单，打开“Internet选项”，选择“安全”选项卡，再依次点击“受信任的站点”、“站点”。
我们可以把http://127.0.0.1作为一个受信任的站点加入。注意，必须清除了“对该区域中的所有站点要求服务器验证
（https:）”选项之后，才能将http://127.0.0.1作为可信任站点加入。
本帖包含图片:
图4：添加一个信任站点
现在http://127.0.0.1已经是一个可信任的站点了，如果我们再次用http://127.0.0.1/CodeDownloadDemo/Loader.exe这个
URL来执行loader.exe，应用程序可以启动，不过.NET仍会提示还有一些安全问题有待解决（如图5）。
本帖包含图片:
图5：应用程序在部分受信任的安全上下文中运行
这一次我们看到loader应用程序正式运行了，但有一则提示信息告诉我们应用程序当前在一个部分受信任的安全上下文中运行
，因此应用程序的某些功能可能无法使用。例如，如果我们试图从Employees窗体装入数据，就会看到一个安全错误（如图6所示），这是因为该窗体试图从localhost上SQL Server的Northwind数据库读取数据，但我们还没有授权它可以执行这一操作。
本帖包含图片:
图6：试图访问指定站点之外的资源时.NET提示错误信息
另外请注意，应用程序的标题条上自动加上了表示来源的“127.0.0.1”。
