本页内容

	介绍
	.NET 框架概述
	创建一个部署项目规划
	在 Visual Studio .NET 中部署项目
	部署 .NET 框架
	>服务器端部署
	>客户端部署
	部署 Web 服务
	部署 .NET 应用程序使用的 SQL Server 数据库
	总结

介绍

这份 .NET 部署指南的主要阅读对象是 IT 经理、解决方案架构师，以及 IT 技术支持工程师，帮助他们部署为 .NET 框架开发的应用程序和组件。除了提供部署过程的技术细节，这份指南还提供了体系结构指南和示例，帮助解决方案架构师和系统架构师有效地支持新的平台。

这份指南并不提供关于 .NET 框架和 Visual Studio. NET 编程环境的全面信息。您可以从 .NET 框架 SDK 和 Microsoft Visual Studio .NET 的文档以及 MSDN Library Web 站点上 http://msdn.microsoft.com/nhp/default.asp?contentid=28000519 访问这些信息。

返回页首

.NET 框架概述

.NET 框架是一个新的开发平台，它为局域网 (LAN) 和 Internet 上的分布式企业应用提供了一致和有效的支持。该平台的关键特性包括：

.NET 框架有两大部分

CLR 的作用是作为运行和管理 .NET 代码的代理。该代理负责一些基础系统服务例如内存管理、线程管理、错误控制，以及类型安全。

开发者可以使用任何 .NET 兼容编程语言来编写程序，而相应的编译器会将它们都转换成中间语言 (IL) 。CLR 使用高效的即时编译 (JIT) 技术将语言无关的 IL 代码转换成特定设备的机器代码。

托管代码总是运行于编译模式，并为当前平台做了优化；但是，代码仍然受被托管以防止一般的执行错误。这种新的编程模型对于程序的运行提供了更加严格的控制，使得新的平台对于分布式应用程序来说更加健壮。

.NET 框架类库是一个全面的面向对象的类型集合，您可以使用它来开发任何应用程序、服务或组件。该类库取代了在 C++ 开发中普遍使用的 Microsoft 基础类库 (MFC) ，它被设计成易扩展的以便对其他服务提供面向对象的编程支持，这些服务例如 Microsoft Windows Server System 产品目前仅仅提供了专有的应用程序编程接口 (API) 。

.NET 框架开启了在 Internet 上共享组件的大门。该技术使用了 Web 服务，因此不仅可供基于 Windows 的应用程序访问，也可供运行于其它平台上的应用程序使用，只要该应用程序使用了 Internet 标准如 TCP/IP 、 HTTP 、 XML ，以及 SOAP 。

用 .NET 框架开发的应用程序仍然可以使用 COM 组件，以充分利用以前开发的投资。但是，这种能力也带来一些性能上的损失，因为需要在两种标准之间互相转换。因此，将 COM 组件移植成 .NET 的托管代码能够极大地提升性能。

体系结构图

图 1 中的图可以在 .NET 框架程序员指南中找到，该图也是 MSDN (http://msdn.microsoft.com/library/en-us/cpguide/html/cpovrintroductiontonetframeworksdk.asp) 的一部分。

该图显示了三种不同的应用程序开发方案：

.NET 框架托管应用程序能够与非托管应用程序共存于同一台机器上。根据所选的编程语言，可以按需求编写托管和非托管代码。

图 1：.NET 体系结构图
查看完整的图像。

开发者可以用 .NET 框架设计很多不同类型的应用程序，例如：

这些应用程序需要不同的部署过程，本文重点介绍主要的可选方案。

.NET 程序集

为了简化应用程序和组件的部署，.NET 框架引入了程序集的概念。在 Windows Server 系统中，程序集是重用、版本控制、安全性、部署的单位。换句话说，程序集是一组任何类型的文件，它们必须一起部署。在某些情况下，程序集只是一个单独的文件，例如一个 DLL 组件包或一个可执行程序。但是，程序集也可以包含其他文件，例如 HTML 页面、 XML 文件，多媒体文件，或其它类型的文件。

开发者可以使用程序集将程序包需要部署的逻辑单元和需要部署的物理单元分离开来。这些程序集可以是一个应用程序的一部分并和它一起部署，也可以是由多个应用程序使用的共享程序集。

程序集信息存储在清单中，每个程序集都自动包含清单。Visual Studio .NET 集成开发环境生成方案自动将清单插入 .EXE 或 .DLL 文件中，可以使用 ildasm.exe 工具（.NET 框架 SDK 的一部分）来观测程序集清单，如下例所示（一个简单的 HelloWorld VB.NET 应用程序）。

图 2：用 ildasm.exe 反汇编程序集的清单

.NET 的 XCOPY 部署

.NET 程序集的部署与以前版本相比显得简单的多，可以被称为 XCOPY 部署。XCOPY 部署意味着在很多情况下，都只用简单地将 .NET 应用程序目录拷贝到目标位置。

以下的 .NET 特性使得该简单部署过程成为可能。

但是，还有部署过程更加复杂的情形，例如：

用 Windows 安装程序部署 .NET

Windows 安装程序为所有类型的应用程序和组件的部署提供了统一的解决方案。部署通过 Windows 安装程序文件完成， Windows 安装程序文件具有 .msi 扩展名，它包含了对应用程序安装的描述，包括：

部署 .NET 应用程序需要 Windows 安装程序 2.0 或更高版本， Windows 2000、Windows XP、以及 Windows Server 2003 的所有版本都提供该安装程序。获取其它平台上 Windows 安装程序的更新版本的详细步骤将在本文后面叙述。

要创建 .msi 文件，需要使用第三方工具。独立软件供应商，如 Installshield Software Corporation (www.installshield.com) 和 Wise Solutions, Inc. (www.wise.com) ，提供了不同的产品来制作 .msi 包。也可以用 Microsoft Visual Studio .NET 来替换这些工具，这些将在本文后面叙述。

MSI 数据库实用工具

Windows 安装程序 SDK （包含在 Windows 平台 SDK 中）允许用 ORCA.EXE 工具查看和编辑已有的 .msi 包。该 SDK 可以从 http://www.microsoft.com/msdownload/platformsdk/sdkupdate/处下载。

该 SDK 包括 msidb.exe 工具，可以用它来导入和导出数据库表和流，合并 .msi 数据库，进行 Windows 安装程序数据库的转换。要了解更多关于 ORCA 和 MSIDB 工具的信息，请参考 Windows 安装程序 SDK 文档。

用 Microsoft Application Center 部属 .NET

Application Center 2000 提供了在负载平衡 Web farm 或故障转移群集服务器上部署 .NET 应用程序的工具。群集中的所有服务器在 Application Center 2000 中作为一个单独的服务器来管理。群集之间的同步保证了应用程序映像在所有成员服务器上被自动复制。

不用关闭任何服务就可以更新服务器应用程序，这样提高了可用性。Application Center 2000 简化了从开发工作站部署新的应用程序或新的版本以及部署失败时进行的回滚。也可以通过 Application Center 2000 使用脚本语言来使部署过程自动化，这依赖于它功能全面的 API 。

关于 Application Center 2000 详细功能的信息超出了本文的范围。要获取该产品的额外信息，请访问 http://www.microsoft.com/applicationcenter/ .

用 Microsoft System Management Server 部署 .NET

Microsoft System Management Server (SMS) 可以为 Windows 安装程序包提供附加的功能，特别针对的情况是向客户端计算机分发 Windows Server 2003 以及向多个 .NET Web 服务器分发 ASP.NET 和 Web服务。

使用 SMS ，可以获得额外的特性和配置优势，例如：

要使用 SMS 2.0 部署 Windows 安装程序安装包，,需要执行下列任务：

要获取更多关于使用 SMS 部署 Windows 安装程序安装包的信息，请参阅“使用 System Management Server 2.0 部属 Windows 安装程序安装包”，见 (http://www.microsoft.com/smserver/techinfo/deployment/20/deployosapps/deploymsi.asp) 。

但是，建议使用 Microsoft Application Center 在群集或 Web farm 中部署 Web 服务和 ASP.NET 应用程序。

返回页首

创建一个部署项目规划

项目规划是部署 .NET 应用程序的逻辑过程中一个重要的步骤。设计项目规划是为了满足商业基础结构和需求。Microsoft 操作框架 (MOF) 提供了部署过程指南。要获取关于 MOF 的额外信息，请访问 MOF Web 站点 www.microsoft.com/mof 。

生成一个项目规划时需要考虑的步骤是：

部署 .NET 解决方案的过程通常是一个重复的任务，因为一个新的 .NET 解决方案的部署与上一个解决方案并没有很大的区别。但是，虽然大多数解决方案都会遵循一个十分相似的过程，遵循一个适当的部署规划可以确保用最小的风险来成功地进行部署。

部署管理结构应该与目前的管理结构紧密结合，但是管理结构应该适合管理下列阶段：

开发项目规划过程

.NET 解决方案的部署遵循一个生命周期，从目的和目标的定义到最后在产品环境中的部署。规划一个部署项目的过程中应该提供一个供遵循的合理指导方案，该指导方案详细描述了怎样进行设计、实现、测试、修改，以及执行每个动作。

确定目的和目标

在规划过程的这个阶段，需要确定将要部署的 .NET 解决方案的主要逻辑配置并特别强调安全性和功能可用性。网络基础结构在该阶段扮演至关重要的角色，因为网络基础结构被设计为业务的安全性和功能性提供服务。

该阶段的目的是定义部署项目的框架，以确保在部署过程中获取必需的执行批准。这第一阶段应该回答与特定部署项目相关的问题，例如：

在这个阶段可能创建的文档包括：

该阶段对于确定部署的里程碑非常重要。您需要向所有参加的团队提供一个清晰的概念如为什么要部署该解决方案、它会怎样影响目前环境、以及将怎样进行部署。

逻辑项目大纲：策略问题

一个典型的 .NET 解决方案包含一些不同的实体

图 3 显示了一个 .NET 解决方案典型的网络拓扑结构。

图 3 ： 一个典型的 .NET 解决方案
查看完整的图像。

用户可以是内部或外部用户，对于两者来说，确定他们可以访问该解决方案的哪些功能是非常重要的。内部用户应该按照他们与该解决方案相关联的访问级别来分组。而对外部用户来说，情况就稍稍复杂一些，因为必须区分客户、供应商以及合作伙伴，甚至从外部网络连接进来的员工。定义对于每个组哪些可用哪些不可用需要细心的规划。

在很多情况下，终端用户应用程序会是 Web 服务器上基于 ASP.NET 的应用程序。因此，需要确定哪些内部 Web 服务器的功能能够在内部防火墙以内访问，而哪些功能能够被内部防火墙以外的外部用户访问。

这些 ASP.NET 和 Windows 应用程序能够使用 .NET Web 服务提供的功能。在这种情况下，确定哪些服务只能本地访问（只为 intranet 用户提供 ）而哪些 Web 服务可以在 intranet 以外访问。

但是，确定过程并不止这些。使一个 Web 服务可用并不意味着该服务对任何类型的使用方式都开放。必须按照上下文确定什么是“私有“和“公有”。然后，可以将 Web 服务分为几个主要的组：

为基础结构和平台组件服务的 Web 服务应该放置在本地 intranet 中。它们能够被完全发现，因为在 intranet 内部访问它们已经受到了保护。但是，放置在私有局域网以外的公有 Web 服务应该只暴露有限的被发现能力。相似的考虑也适用于私有和公有 .NET Web 应用程序，因为必须考虑哪些只能供企业用户使用，哪些可以供外部用户使用。

在某些情况下，您也许想在 intranet 应用程序中用 .NET Remoting 来代替 Web 服务。要了解 Remoting 和 Web 服务的对比，请参阅 Microsoft Web 站点 ( http://msdn.microsoft.com/library/en-us/dnadvnet/html/vbnet10232001.asp) 。 Web 服务是运行于不同平台的应用程序间通信的理想选择，而 Remoting 在基于 .NET 的应用程序之间的通信会更有效和可靠。

在任何情况下，确定每个组件将使用什么验证方法以及怎样验证使用该方法验证那些资源也是非常重要的。可以用程序来确定，这样在部署阶段这些设置将不能改变。但是在部署阶段，可以通过修改配置文件来定制这些设置，本文将后面将进行论述。

设计和管理一个 .NET 测试实验室

要测试一个部署规划的可行性，方便的办法是运行一个试验部署项目。该试验项目的目的是在不需要面对产品环境的情况下跟踪和解决任何潜在的问题并精细调整部署过程。该阶段对于达到部署目标、保持进度、不超出预算边界来说都是至关重要的。

.NET 测试实验室应该是产品环境的一个复制品，包括最终所包含的所有的网络层次和系统。越接近产品环境，试验项目的效率就越高。

试验项目稳定以后，部署团队就能够获得最终的可行性。该阶段的重要事件是：

您可能想开发额外的文档来辅助将要进行部署的操作团队。这些文档可能包括：

在该阶段，部署规划将是一个随着测试程序进行中发生的连续变化而变化的动态规划。应该特别注意灾难恢复规划，它应该被全面测试并尝试预测和解决所有已知的潜在问题。

获取反馈

为了帮助确定是否超出了试验项目，需要从试验所包含的所有小组获取反馈。可以使用不同的技术来获取这些反馈，例如：

试着从各个角度获取尽可能多的部署该 .NET 解决方案信息，例如：

产品首发

部署项目的最后阶段是产品首发。在这个阶段，作为试验程序的一部分已经测试了所有任务，并且定义了所有风险和意外事故规划。由于测试实验室与真实地产品环境之间的区别，需要继续测试并且已经在调整测试项目中初始化的过程。

产品首发过程应该在产品首发首发规划中全面文档记录，包括不同组件是如何部署的详细信息。应特别关注组件之间的依赖性，如果存在依赖性，要清楚地详细说明部署的顺序。已经在测试实验室测试过的灾难恢复规划在该阶段可做精细调整已符合产品环境的实际情况。

在部署完毕并为执行主管准备好项目完结报告之后，应进行一次项目复查。项目复查可以客观地反映整个项目的优势和弱点，并分析如何运用获得的知识和经验提高将来基础结构的部署水平。

返回页首

在 Visual Studio .NET 中部署项目

要使用 Windows 安装程序部署 .NET 应用程序，可以使用 Visual Studio .NET 中的安装和部署项目之一，如图 4 所示：

图 4 ：用 Visual Studio .NET 添加一个安装项目
查看完整的图像。

为 Web 部署创建一个项目后（在 VS.NET 集成开发环境中叫做 Web 安装项目），不能将它转换为一个 Windows 安装程序项目（在 VS.NET 集成开发环境中叫做安装项目），反之亦然。要获取这样的功能，必须创建两个不同的安装项目。使用安装向导来创建一个直接安装程序；但是，所有其它项目类型提供了极大地灵活性。

安装程序提供了几个编辑器。通过从安装项目上下文菜单中选择相应的项目来查看这些编辑器，如图 5 所示

图 5 ：从安装项目的查看菜单选册编辑器
查看完整的图像。

以下是可为特定应用程序选择的编辑器：

文件系统编辑器。使用该编辑器，可以定制用户桌面和开始菜单以及向应用程序文件夹添加文件和快捷方式。

图 6 ：查看文件系统编辑器可选项

注册表编辑器。使用该编辑器向注册表添加键值，用来存储默认设置。

图 7 ：查看注册表可选项
查看完整的图像。

文件类型。使用该编辑器添加文件类型和对这些文件类型的动作，这由其扩展名决定。例如，在下面的图中，文件类型 FGG （扩展名为 .fgg ）定义了打开动作。

图 8 ： 定义文件类型和动作

用户界面。 使用该编辑器定制安装程序的外观。这些设置可以从一组模板式样隐藏或添加安装向导中的某些画面或。在下图中，可以看到能够定义显示哪些文字和向导的特定部分（注意图中的文字太长，无法在图中完整显示，但是实际上可以编辑）。

图 9： 定义用户界面对话框
查看完整的图像。

自定义动作。使用该编辑器来指定在特定的动作被选择后应该执行哪个程序。这个功能对于安装将来的组件或创建特定的数据库对象来说非常有用。这些动作在特定的事件发生时运行，例如：

图 10 ：定义自定义动作

启动条件。使用该编辑器指定检查目标机器上的那些条件。

图 11 ：定义启动条件

安装项目配置

安装项目属性页用来访问配置设置。要访问该页，在项目上下文菜单中选择属性，如图 12 所示：

图 12 ：安装项目属性页
查看完整的图像。

使用该配置页，可以确定生成配置和创建结果文件的文件夹。这些文件可以以不同的方式创建，如图 13 所示：

图 13 ：定义如何打包安装文件

使用图 14 所示的引导选项，可以选择将提供哪种类型的 Windows 安装程序（在目标机器需要时）。

图 14 ：选择引导

如同任何 .NET 项目一样，该安装项目可以在大小和速度上进行优化，如图 15 所示：

图 15 ：选择压缩优化类型

安装文件

生成安装项目的过程中在 Debug 或 Release 文件夹（视所选的生成类型而定）下创建了以下文件，如表 1 所示：

表 1 安装中创建的文件

返回页首

部署 .NET 框架

要在特定的计算机中执行为 .NET 框架设计的应用程序或服务，该计算机需要安装 .NET 框架。由于目前所有的 Microsoft 平台都不包含 .NET 框架，因此第一步就是确定目标计算机上 .NET 框架是否可用。

运行任何版本 Microsoft Windows Server 2003 的计算机都已经安装了 .NET 框架，因为它是标准操作系统安装过程中的一部分。运行 Microsoft Windows XP 的计算机可以通过 Microsoft Windows Update Web 站点安装 .NET 框架。推荐使用 Microsoft Windows Update Web 站点来更新 .NET 框架的最新服务包或新发行版本。

对于运行其它平台的计算机来说，通过 Dotnetfx.exe 应用程序来实现 .NET 的重新发布。目前它可以从下列位置和产品获得：

不要在您的 intranet 或 Web 站点上重新发布 .NET 框架。将用户引导到 Microsoft Windows 更新 Web 站点，为他们提供最新版本的组件。

该重新发布将安装所有服务器和客户端所需要的组件。 .NET 框架重新发布包支持如下平台：

>要运行 .NET 框架组件，还需要

返回页首

>服务器端部署

ASP.NET 应用程序和 Web 服务被设计作为服务器组件运行，通常运行于本地或远程网络中的中心计算机上。要运行这些应用程序和服务，必须确保满足所有先决条件。运行 Windows Server 2003 操作系统的服务器包含了所有运行 .NET 应用程序的先决条件。

如果要部署的应用程序不使用客户端组件，就只需要部署服务器端。在这种情况下，这些应用程序提供的功能将由 Internet 浏览器或 Windows 应用程序使用，与 .NET 应用程序相关的任何过程都不包含“宿主”应用程序。

确定需求

要确保 .NET 服务器应用程序运行时的性能，您应该观测表 2 所列出的需求：

表 2 部属 .NET 应用程序的服务器需求

返回页首

>客户端部署

>ASP.NET 应用程序和 Web 服务被设计作为服务器组件运行。客户端设备使用宿主应用程序，例如 Internet Explorer ，来运行这些 .NET 应用程序，或者它会运行一个 .NET 应用程序来远程使用这些服务。运行 Windows Server 2003 操作系统的服务器包含了将 .NET 应用程序作为客户端设备运行的所有先决条件

在某些情况下， .NET 应用程序需要部署客户端组件，在这种情况下的部署所要考虑的问题与部署 .NET 服务器应用程序非常相似。

确定需求

为了确保运行于客户端的 .NET 应用程序的功能和性能，您因该观测表 3 列出的需求。

表 3 运行 .NET 的客户端需求

安全性考虑

Web 服务上的验证和授权遵循与 ASP.NET 应用程序授权和验证相同的规则。表 4 总结了不同的验证方法。

表 4 验证方法

安全配置文件。 .NET 应用程序的安全配置文件安装在表 5 所列出的位置。

表 5 配置文件的位置

为了避免安全文件损坏，您应该使用以下工具：

配置 .NET 应用程序

.NET 应用程序配置位于几个文件中，我们将在以下部分详细叙述。该部分的目的是提供关于这些文件的位置信息，解释他们的目的和主要组成部分。

配置文件是标准的 XML 文件。配置设置使用 XML 标签被安排为一套预定义元素。如果要直接编辑配置文件需要熟悉 XML ，请记住 XML 标签和属性是大小写敏感的。

每个配置文件都使用了一个 <configuration> 格式如下：

<configuration>
<!-- configuration settings -->
</configuration>

该元素可能包含一些子元素，如表 6 所示。该表显示了这些配置文件中不同的部分以及这些部分由那些元素所定义。

可以在以下位置找到这些 XML 配置文件的一些例子：

表 6 .NET 配置文件的内容

<startup>

<runtime>

<system.runtime.remoting>

<system.net>

<mscorlib>

<configSections>
<appSettings>
<MyCustomSettings>

<system.diagnostics>

<system.web>

机器配置文件。 machine.config 文件在 %runtime install path%\Config 目录下，包含影响整个安装 .NET 的机器的设置。由于这个原因，将应用程序设置存储在不同的位置会更加方便，稍候将进行讨论。

使用 Windows 安装程序部署 .NET 应用程序能够自动对 machine.config 文件应用更新，但是使用 XCOPY 部属则不行。

应用程序配置文件。 CLR 首先在应用程序配置文件中搜索应用程序设置，然后再搜索机器配置文件。应用程序配置文件的名称和位置依赖于应用程序宿主，它可以是以下之一：

<?xml version ="1.0"?>
<configuration>
<startup>
<requiredRuntime  safemode="true"  imageVersion="v1.0.3705" version="v1.0.3705"  />
</startup>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<publisherPolicy apply="no"/>
</assemblyBinding>
</runtime>
</configuration>

返回页首

部署 Web 服务

前面所有叙述应用于任何类型的 .NET 应用程序和服务。但是，对于 Web 服务还有一些特别要注意的地方。

部署一个 XML Web 服务包括将 .asmx 文件和该 XML Web 服务所用到的任何程序集拷贝到 Web 服务器上，但是不包括 Microsoft .NET 框架的那部分。例如，如果要部署一个名为 StockServices 的 XML Web 服务，要在 Web 服务器上创建一个虚拟目录并将该服务的 .asmx 文件放置于此。虚拟目录也是一个 IIS Web 应用程序，虽然不是必需的。这样一个应用程序的树形结构是：

\Inetpub
\Wwwroot
\StockServices
StockServices.asmx
\Bin

Under \Bin ，可以对所有非 Microsoft .NET 框架部分而由 XML Web 服务使用的程序集添加引用。

与 Web 服务一起部署的项目

发布一个 XML Web 服务时，表 7 中的项目也被部署到 Web 服务器上。Service, the following items in Table 7 are deploye

tting role="bold">表 7

返回页首

部署 .NET 应用程序使用的 SQL Server 数据库

某些 .NET 应用程序和 Web 服务使用 SQL Server 数据库来存储应用程序数据。应该定义部署过程来自动安装所有需要存储的项目，可以使用下列任何策略：

连接 SQL Server 数据库

如果 .NET 应用程序的部署包括 SQL Server 数据库，如此部署的最简单方法是使用 SQL Server 的连接数据库功能。下面是部署一个将要连接到现存或新安装的 SQL Server 的 SQL Server 数据库的步骤：

返回页首

总结

Microsoft .NET 框架为开发者提供了一个强大的可扩展的平台来生成安全的、可伸缩的解决方案。.NET 框架 还扩展了 Windows 2000、IIS、以及 SQL Server 已有的某些功能，但是这些新的解决方案的部署与过去有着很大的区别。本文提供了关于如何使用 Windows 安装程序和 XCOPY 的方式部署 .NET 应用程序的详尽说明。但是本文最重要的目标是强调在部署过程中进行谨慎地设计和测试以在最终产品环境中成功地进行部署。

返回页首