导读：
摘要
Microsoft .NET 框架提出了一种新的软件开发规范，信息技术 (IT) 的从业者将会面临一些风险，即在他们现有基础结构上来管理和部署这些新的应用程序和组件。这份 .NET 部署指南为部署基于 Microsoft .NET 框架的应用程序和组件提供了信息和指南。该指南提供了成功部署 .NET 应用程序的详细描述，同时为读者提供了附加信息的链接
介绍
这份 .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 上的分布式企业应用提供了一致和有效的支持。该平台的关键特性包括：
统一的、语言无关的、面向对象开发环境，充分利用开发者已有的编程知识
无冲突软件部署，避免组件的版本冲突
丰富的可执行模式，与存储位置无关，组件可以在本地存储执行，或者远程存储本地执行，或者在 Internet 上远程存储执行
安全代码执行，具有高级安全设置以满足现代组织的安全需求
Windows 和 Web 应用程序具有统一的编程环境
通过在各自环境中高效的代码编译提升 Windows 和 Web 应用程序的执行性能
兼容的通信标准，确保 .NET 应用程序可以与其它应用程序和其它平台的应用程序共存和集成
.NET 框架有两大部分
公共语言运行时 (CLR)
.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) 的一部分。
该图显示了三种不同的应用程序开发方案：
在 CLR 下运行托管代码的程序
运行非托管机器代码的程序
在 ASP.NET 下运行托管代码的 Web 应用程序和 Web 服务
.NET 框架托管应用程序能够与非托管应用程序共存于同一台机器上。根据所选的编程语言，可以按需求编写托管和非托管代码。
图 1：.NET 体系结构图
开发者可以用 .NET 框架设计很多不同类型的应用程序，例如：
Windows 应用程序
类库
Windows 控件库
ASP.NET Web 应用程序
ASP.NET Web 服务
Web 控件库
控制台应用程序
Windows 服务
安装项目
Web 安装项目
Visual Studio .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 特性使得该简单部署过程成为可能。
每个程序集都是自描述的，因为程序集包含定义其内容的元数据。这个特性杜绝了用无止境的注册表登记项来定义各个组件的公共接口的做法。
.NET 程序集中的每个组件都使用标准的位置，因此不需要在注册表中进行定义。
可以用配置文件来修改组件的位置，不过程序集在标准位置查询这些配置文件，从而避免了注册过程。
但是，还有部署过程更加复杂的情形，例如：
.NET 应用程序与 COM 组件的交互仍然需要注册。
在远程计算机上将程序集预编译为本地代码需要比仅仅将文件拷贝到目标目录更多的过程。
将程序集安装到远程计算机的全局程序集缓冲中时需要更多的步骤以使该程序集成为全局共享程序集。
当安装与 .NET 框架一起部署的 Windows 服务时，这些服务需要在目标系统注册。
某些 .NET 应用程序安装过程需要在其它服务中设置对象，如活动目录、 Internet 信息服务，以及集成于 Windows Server 系统的服务器软件，需要运行其他的应用程序或脚本来创建和配置这些对象。
当定制一个用户环境，例如开始菜单项、桌面快捷方式、控制面板小程序、自定义文件夹以及 Office 外接程序时，需要安装程序创建所有这些自定义的项目。
用 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 安装程序安装包，,需要执行下列任务：
在目标计算机上验证 Windows 安装程序运行时的可用性
使用 Windows 安装程序的管理安装来设置一个源包的路径。
创建一个包。
配置弹性资源（可选）。
使用 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 。
生成一个项目规划时需要考虑的步骤是：
创建一个项目规划大纲：
定义项目范围和目的
确定适当的部署进度表
按照常规 MOF 指南的定义规划部署
确定资源/人员需求
建立项目团队
收集当前环境信息
建立标准和指导方案
风险管理
培训
测试和试验概述
确定技术参考和依赖
完成项目规划
部署 .NET 解决方案的过程通常是一个重复的任务，因为一个新的 .NET 解决方案的部署与上一个解决方案并没有很大的区别。但是，虽然大多数解决方案都会遵循一个十分相似的过程，遵循一个适当的部署规划可以确保用最小的风险来成功地进行部署。
部署管理结构应该与目前的管理结构紧密结合，但是管理结构应该适合管理下列阶段：
规划 .NET 解决方案的部署
设计和管理一个 .NET 实验室来测试 .NET 解决方案的部署
完成最终在产品环境中的部署
开发项目规划过程
.NET 解决方案的部署遵循一个生命周期，从目的和目标的定义到最后在产品环境中的部署。规划一个部署项目的过程中应该提供一个供遵循的合理指导方案，该指导方案详细描述了怎样进行设计、实现、测试、修改，以及执行每个动作。
确定目的和目标
在规划过程的这个阶段，需要确定将要部署的 .NET 解决方案的主要逻辑配置并特别强调安全性和功能可用性。网络基础结构在该阶段扮演至关重要的角色，因为网络基础结构被设计为业务的安全性和功能性提供服务。
该阶段的目的是定义部署项目的框架，以确保在部署过程中获取必需的执行批准。这第一阶段应该回答与特定部署项目相关的问题，例如：
为什么您的组织要部署这个特定的 .NET 解决方案？
该解决方案何时能够启用？
该项目的具体范围？
该项目会影响到谁？
怎样才算是成功的部署？
系统中是否已经实现了其它 .NET 解决方案？如果是，它们与该项目中将要部属的解决方案之间是否会发生潜在的交互？
有没有其它应用程、系统或软件会受到该解决方案部署的影响？ 如果是，是否需要将它们集成到新的解决方案中？怎样进行集成？
有什么样的风险？
整个过程将包括哪些人？
在这个阶段可能创建的文档包括：
目的和目标文档
当前环境概述
风险评估
该阶段对于确定部署的里程碑非常重要。您需要向所有参加的团队提供一个清晰的概念如为什么要部署该解决方案、它会怎样影响目前环境、以及将怎样进行部署。
逻辑项目大纲：策略问题
一个典型的 .NET 解决方案包含一些不同的实体
后端服务器
应用程序服务器
Web 服务器
终端用户应用程序
用户
图 3 显示了一个 .NET 解决方案典型的网络拓扑结构。
图 3 ： 一个典型的 .NET 解决方案
用户可以是内部或外部用户，对于两者来说，确定他们可以访问该解决方案的哪些功能是非常重要的。内部用户应该按照他们与该解决方案相关联的访问级别来分组。而对外部用户来说，情况就稍稍复杂一些，因为必须区分客户、供应商以及合作伙伴，甚至从外部网络连接进来的员工。定义对于每个组哪些可用哪些不可用需要细心的规划。
在很多情况下，终端用户应用程序会是 Web 服务器上基于 ASP.NET 的应用程序。因此，需要确定哪些内部 Web 服务器的功能能够在内部防火墙以内访问，而哪些功能能够被内部防火墙以外的外部用户访问。
这些 ASP.NET 和 Windows 应用程序能够使用 .NET Web 服务提供的功能。在这种情况下，确定哪些服务只能本地访问（只为 intranet 用户提供 ）而哪些 Web 服务可以在 intranet 以外访问。
但是，确定过程并不止这些。使一个 Web 服务可用并不意味着该服务对任何类型的使用方式都开放。必须按照上下文确定什么是“私有“和“公有”。然后，可以将 Web 服务分为几个主要的组：
私有 Web 服务只对预定义的运行在所选的 Web 服务器上的 ASP.NET 应用程序可用。
私有 Web 服务只对预定义的 .NET 应用程序可用。这与上一种情况一致，因为 ASP.NET 应用程序和 Windows 应用程序可以被看作相同 Web 服务纯粹的消费者。
私有 Web 服务对任何被设计在 intranet 上运行的应用程序可用。
公有 Web 服务只对运行在所选公有 Web 服务器上的预定义 ASP.NET 应用程序可用，但对于其它应用程序不可用。
公有 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 测试实验室应该是产品环境的一个复制品，包括最终所包含的所有的网络层次和系统。越接近产品环境，试验项目的效率就越高。
试验项目稳定以后，部署团队就能够获得最终的可行性。该阶段的重要事件是：
功能规格的完成和稳定
概念验证的完成
产前测试完成
试验完成
风险管理规划更新
您可能想开发额外的文档来辅助将要进行部署的操作团队。这些文档可能包括：
培训计划
支持或问询规划
操作转换规划
灾难恢复规划
在该阶段，部署规划将是一个随着测试程序进行中发生的连续变化而变化的动态规划。应该特别注意灾难恢复规划，它应该被全面测试并尝试预测和解决所有已知的潜在问题。
获取反馈
为了帮助确定是否超出了试验项目，需要从试验所包含的所有小组获取反馈。可以使用不同的技术来获取这些反馈，例如：
Web 站点反馈表单
与业务经理的会议
问题报告
调查
对 IT 项目和网络操作的观测
试着从各个角度获取尽可能多的部署该 .NET 解决方案信息，例如：
培训
首发过程
支持
通讯
发生的问题
改进的建议
产品首发
部署项目的最后阶段是产品首发。在这个阶段，作为试验程序的一部分已经测试了所有任务，并且定义了所有风险和意外事故规划。由于测试实验室与真实地产品环境之间的区别，需要继续测试并且已经在调整测试项目中初始化的过程。
产品首发过程应该在产品首发首发规划中全面文档记录，包括不同组件是如何部署的详细信息。应特别关注组件之间的依赖性，如果存在依赖性，要清楚地详细说明部署的顺序。已经在测试实验室测试过的灾难恢复规划在该阶段可做精细调整已符合产品环境的实际情况。
在部署完毕并为执行主管准备好项目完结报告之后，应进行一次项目复查。项目复查可以客观地反映整个项目的优势和弱点，并分析如何运用获得的知识和经验提高将来基础结构的部署水平。
在 Visual Studio .NET 中部署项目
要使用 Windows 安装程序部署 .NET 应用程序，可以使用 Visual Studio .NET 中的安装和部署项目之一，如图 4 所示：
图 4 ：用 Visual Studio .NET 添加一个安装项目
安装项目为一个基于 Windows 的应用程序创建了一个 Windows 安装程序项目。
Web 安装项目创建了一个 Windows 安装程序 Web 项目，在开发过程中可以手动向该项目添加文件
合并模块项目将可能被多个应用程序共享的组件打包。
安装向导帮助开发者一步一步创建安装项目。
Cab 项目为旧式的 Web 浏览器准备 Cab 文件。
为 Web 部署创建一个项目后（在 VS.NET 集成开发环境中叫做 Web 安装项目），不能将它转换为一个 Windows 安装程序项目（在 VS.NET 集成开发环境中叫做安装项目），反之亦然。要获取这样的功能，必须创建两个不同的安装项目。使用安装向导来创建一个直接安装程序；但是，所有其它项目类型提供了极大地灵活性。
安装程序提供了几个编辑器。通过从安装项目上下文菜单中选择相应的项目来查看这些编辑器，如图 5 所示
图 5 ：从安装项目的查看菜单选册编辑器
以下是可为特定应用程序选择的编辑器：
文件系统编辑器。使用该编辑器，可以定制用户桌面和开始菜单以及向应用程序文件夹添加文件和快捷方式。
图 6 ：查看文件系统编辑器可选项
注册表编辑器。使用该编辑器向注册表添加键值，用来存储默认设置。
图 7 ：查看注册表可选项
文件类型。使用该编辑器添加文件类型和对这些文件类型的动作，这由其扩展名决定。例如，在下面的图中，文件类型 FGG （扩展名为 .fgg ）定义了打开动作。
图 8 ： 定义文件类型和动作
用户界面。使用该编辑器定制安装程序的外观。这些设置可以从一组模板式样隐藏或添加安装向导中的某些画面或。在下图中，可以看到能够定义显示哪些文字和向导的特定部分（注意图中的文字太长，无法在图中完整显示，但是实际上可以编辑）。
本文转自
http://www.szstc.org.cn/info_detail.asp?id=878
摘要
Microsoft .NET 框架提出了一种新的软件开发规范，信息技术 (IT) 的从业者将会面临一些风险，即在他们现有基础结构上来管理和部署这些新的应用程序和组件。这份 .NET 部署指南为部署基于 Microsoft .NET 框架的应用程序和组件提供了信息和指南。该指南提供了成功部署 .NET 应用程序的详细描述，同时为读者提供了附加信息的链接
介绍
这份 .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 上的分布式企业应用提供了一致和有效的支持。该平台的关键特性包括：
统一的、语言无关的、面向对象开发环境，充分利用开发者已有的编程知识
无冲突软件部署，避免组件的版本冲突
丰富的可执行模式，与存储位置无关，组件可以在本地存储执行，或者远程存储本地执行，或者在 Internet 上远程存储执行
安全代码执行，具有高级安全设置以满足现代组织的安全需求
Windows 和 Web 应用程序具有统一的编程环境
通过在各自环境中高效的代码编译提升 Windows 和 Web 应用程序的执行性能
兼容的通信标准，确保 .NET 应用程序可以与其它应用程序和其它平台的应用程序共存和集成
.NET 框架有两大部分
公共语言运行时 (CLR)
.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) 的一部分。
该图显示了三种不同的应用程序开发方案：
在 CLR 下运行托管代码的程序
运行非托管机器代码的程序
在 ASP.NET 下运行托管代码的 Web 应用程序和 Web 服务
.NET 框架托管应用程序能够与非托管应用程序共存于同一台机器上。根据所选的编程语言，可以按需求编写托管和非托管代码。
图 1：.NET 体系结构图
开发者可以用 .NET 框架设计很多不同类型的应用程序，例如：
Windows 应用程序
类库
Windows 控件库
ASP.NET Web 应用程序
ASP.NET Web 服务
Web 控件库
控制台应用程序
Windows 服务
安装项目
Web 安装项目
Visual Studio .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 特性使得该简单部署过程成为可能。
每个程序集都是自描述的，因为程序集包含定义其内容的元数据。这个特性杜绝了用无止境的注册表登记项来定义各个组件的公共接口的做法。
.NET 程序集中的每个组件都使用标准的位置，因此不需要在注册表中进行定义。
可以用配置文件来修改组件的位置，不过程序集在标准位置查询这些配置文件，从而避免了注册过程。
但是，还有部署过程更加复杂的情形，例如：
.NET 应用程序与 COM 组件的交互仍然需要注册。
在远程计算机上将程序集预编译为本地代码需要比仅仅将文件拷贝到目标目录更多的过程。
将程序集安装到远程计算机的全局程序集缓冲中时需要更多的步骤以使该程序集成为全局共享程序集。
当安装与 .NET 框架一起部署的 Windows 服务时，这些服务需要在目标系统注册。
某些 .NET 应用程序安装过程需要在其它服务中设置对象，如活动目录、 Internet 信息服务，以及集成于 Windows Server 系统的服务器软件，需要运行其他的应用程序或脚本来创建和配置这些对象。
当定制一个用户环境，例如开始菜单项、桌面快捷方式、控制面板小程序、自定义文件夹以及 Office 外接程序时，需要安装程序创建所有这些自定义的项目。
用 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 安装程序安装包，,需要执行下列任务：
在目标计算机上验证 Windows 安装程序运行时的可用性
使用 Windows 安装程序的管理安装来设置一个源包的路径。
创建一个包。
配置弹性资源（可选）。
使用 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 。
生成一个项目规划时需要考虑的步骤是：
创建一个项目规划大纲：
定义项目范围和目的
确定适当的部署进度表
按照常规 MOF 指南的定义规划部署
确定资源/人员需求
建立项目团队
收集当前环境信息
建立标准和指导方案
风险管理
培训
测试和试验概述
确定技术参考和依赖
完成项目规划
部署 .NET 解决方案的过程通常是一个重复的任务，因为一个新的 .NET 解决方案的部署与上一个解决方案并没有很大的区别。但是，虽然大多数解决方案都会遵循一个十分相似的过程，遵循一个适当的部署规划可以确保用最小的风险来成功地进行部署。
部署管理结构应该与目前的管理结构紧密结合，但是管理结构应该适合管理下列阶段：
规划 .NET 解决方案的部署
设计和管理一个 .NET 实验室来测试 .NET 解决方案的部署
完成最终在产品环境中的部署
开发项目规划过程
.NET 解决方案的部署遵循一个生命周期，从目的和目标的定义到最后在产品环境中的部署。规划一个部署项目的过程中应该提供一个供遵循的合理指导方案，该指导方案详细描述了怎样进行设计、实现、测试、修改，以及执行每个动作。
确定目的和目标
在规划过程的这个阶段，需要确定将要部署的 .NET 解决方案的主要逻辑配置并特别强调安全性和功能可用性。网络基础结构在该阶段扮演至关重要的角色，因为网络基础结构被设计为业务的安全性和功能性提供服务。
该阶段的目的是定义部署项目的框架，以确保在部署过程中获取必需的执行批准。这第一阶段应该回答与特定部署项目相关的问题，例如：
为什么您的组织要部署这个特定的 .NET 解决方案？
该解决方案何时能够启用？
该项目的具体范围？
该项目会影响到谁？
怎样才算是成功的部署？
系统中是否已经实现了其它 .NET 解决方案？如果是，它们与该项目中将要部属的解决方案之间是否会发生潜在的交互？
有没有其它应用程、系统或软件会受到该解决方案部署的影响？ 如果是，是否需要将它们集成到新的解决方案中？怎样进行集成？
有什么样的风险？
整个过程将包括哪些人？
在这个阶段可能创建的文档包括：
目的和目标文档
当前环境概述
风险评估
该阶段对于确定部署的里程碑非常重要。您需要向所有参加的团队提供一个清晰的概念如为什么要部署该解决方案、它会怎样影响目前环境、以及将怎样进行部署。
逻辑项目大纲：策略问题
一个典型的 .NET 解决方案包含一些不同的实体
后端服务器
应用程序服务器
Web 服务器
终端用户应用程序
用户
图 3 显示了一个 .NET 解决方案典型的网络拓扑结构。
图 3 ： 一个典型的 .NET 解决方案
用户可以是内部或外部用户，对于两者来说，确定他们可以访问该解决方案的哪些功能是非常重要的。内部用户应该按照他们与该解决方案相关联的访问级别来分组。而对外部用户来说，情况就稍稍复杂一些，因为必须区分客户、供应商以及合作伙伴，甚至从外部网络连接进来的员工。定义对于每个组哪些可用哪些不可用需要细心的规划。
在很多情况下，终端用户应用程序会是 Web 服务器上基于 ASP.NET 的应用程序。因此，需要确定哪些内部 Web 服务器的功能能够在内部防火墙以内访问，而哪些功能能够被内部防火墙以外的外部用户访问。
这些 ASP.NET 和 Windows 应用程序能够使用 .NET Web 服务提供的功能。在这种情况下，确定哪些服务只能本地访问（只为 intranet 用户提供 ）而哪些 Web 服务可以在 intranet 以外访问。
但是，确定过程并不止这些。使一个 Web 服务可用并不意味着该服务对任何类型的使用方式都开放。必须按照上下文确定什么是“私有“和“公有”。然后，可以将 Web 服务分为几个主要的组：
私有 Web 服务只对预定义的运行在所选的 Web 服务器上的 ASP.NET 应用程序可用。
私有 Web 服务只对预定义的 .NET 应用程序可用。这与上一种情况一致，因为 ASP.NET 应用程序和 Windows 应用程序可以被看作相同 Web 服务纯粹的消费者。
私有 Web 服务对任何被设计在 intranet 上运行的应用程序可用。
公有 Web 服务只对运行在所选公有 Web 服务器上的预定义 ASP.NET 应用程序可用，但对于其它应用程序不可用。
公有 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 测试实验室应该是产品环境的一个复制品，包括最终所包含的所有的网络层次和系统。越接近产品环境，试验项目的效率就越高。
试验项目稳定以后，部署团队就能够获得最终的可行性。该阶段的重要事件是：
功能规格的完成和稳定
概念验证的完成
产前测试完成
试验完成
风险管理规划更新
您可能想开发额外的文档来辅助将要进行部署的操作团队。这些文档可能包括：
培训计划
支持或问询规划
操作转换规划
灾难恢复规划
在该阶段，部署规划将是一个随着测试程序进行中发生的连续变化而变化的动态规划。应该特别注意灾难恢复规划，它应该被全面测试并尝试预测和解决所有已知的潜在问题。
获取反馈
为了帮助确定是否超出了试验项目，需要从试验所包含的所有小组获取反馈。可以使用不同的技术来获取这些反馈，例如：
Web 站点反馈表单
与业务经理的会议
问题报告
调查
对 IT 项目和网络操作的观测
试着从各个角度获取尽可能多的部署该 .NET 解决方案信息，例如：
培训
首发过程
支持
通讯
发生的问题
改进的建议
产品首发
部署项目的最后阶段是产品首发。在这个阶段，作为试验程序的一部分已经测试了所有任务，并且定义了所有风险和意外事故规划。由于测试实验室与真实地产品环境之间的区别，需要继续测试并且已经在调整测试项目中初始化的过程。
产品首发过程应该在产品首发首发规划中全面文档记录，包括不同组件是如何部署的详细信息。应特别关注组件之间的依赖性，如果存在依赖性，要清楚地详细说明部署的顺序。已经在测试实验室测试过的灾难恢复规划在该阶段可做精细调整已符合产品环境的实际情况。
在部署完毕并为执行主管准备好项目完结报告之后，应进行一次项目复查。项目复查可以客观地反映整个项目的优势和弱点，并分析如何运用获得的知识和经验提高将来基础结构的部署水平。
在 Visual Studio .NET 中部署项目
要使用 Windows 安装程序部署 .NET 应用程序，可以使用 Visual Studio .NET 中的安装和部署项目之一，如图 4 所示：
图 4 ：用 Visual Studio .NET 添加一个安装项目
安装项目为一个基于 Windows 的应用程序创建了一个 Windows 安装程序项目。
Web 安装项目创建了一个 Windows 安装程序 Web 项目，在开发过程中可以手动向该项目添加文件
合并模块项目将可能被多个应用程序共享的组件打包。
安装向导帮助开发者一步一步创建安装项目。
Cab 项目为旧式的 Web 浏览器准备 Cab 文件。
为 Web 部署创建一个项目后（在 VS.NET 集成开发环境中叫做 Web 安装项目），不能将它转换为一个 Windows 安装程序项目（在 VS.NET 集成开发环境中叫做安装项目），反之亦然。要获取这样的功能，必须创建两个不同的安装项目。使用安装向导来创建一个直接安装程序；但是，所有其它项目类型提供了极大地灵活性。
安装程序提供了几个编辑器。通过从安装项目上下文菜单中选择相应的项目来查看这些编辑器，如图 5 所示
图 5 ：从安装项目的查看菜单选册编辑器
以下是可为特定应用程序选择的编辑器：
文件系统编辑器。使用该编辑器，可以定制用户桌面和开始菜单以及向应用程序文件夹添加文件和快捷方式。
图 6 ：查看文件系统编辑器可选项
注册表编辑器。使用该编辑器向注册表添加键值，用来存储默认设置。
图 7 ：查看注册表可选项
文件类型。使用该编辑器添加文件类型和对这些文件类型的动作，这由其扩展名决定。例如，在下面的图中，文件类型 FGG （扩展名为 .fgg ）定义了打开动作。
图 8 ： 定义文件类型和动作
用户界面。使用该编辑器定制安装程序的外观。这些设置可以从一组模板式样隐藏或添加安装向导中的某些画面或。在下图中，可以看到能够定义显示哪些文字和向导的特定部分（注意图中的文字太长，无法在图中完整显示，但是实际上可以编辑）。
本文转自
http://www.szstc.org.cn/info_detail.asp?id=878
5099
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
