目前我们部署编译ASP.Net应用程序通过在本地发布网站，并通过电子邮件发送zip文件到系统管理员（通常）冗长的一套部署的说明。这是因为我们第一次将ASP.Net应用程序部署到客户端时，开发人员和测试IIS实例是相同的，我们无法将该站点两次部署到同一台计算机。这为后续所有项目的部署奠定了基调。你用什么方法将ASP.Net应用程序部署到野外？
我现在评价我们的部署方法和我在内置的部署工具专门找;特别是我正在查看自定义安装任务并尽可能多地使用标准安装程序功能（主要是用户界面）。
其次，我期待在合并部署和自动更新。
你怎么去在组织中部署sofware？你使用哪些工具，以及你经常遇到什么问题？
部署Web应用程序使用复制Web工具 从微软培训工具包基于通讯簿Web开发
Web安装项目
文本是有用的，如果你是众多用户提供了一个Web应用程序（例如，允许人们下载来自Web的应用程序并安装它）。如果您负责为组织更新特定的网站，那么登录到Web服务器并在每次更新时安装Windows Installer程序包都是不切实际的。对于内部应用程序，您可以直接在Web服务器上编辑Web应用程序。但是，您所做的更改会立即在生产Web应用程序中实施，并且包含可能存在的任何错误。要使自己能够测试Web应用程序，可以在计算机上编辑Web应用程序的本地副本，并使用“复制Web”工具将更改发布到生产Web服务器。您还可以使用“复制Web”工具将更改从登台服务器发布到生产Web服务器，或任何两台Web服务器之间。复制Web工具可以将单个文件或整个网站复制到源网站或远程网站，或从源网站和远程网站复制。您还可以选择同步文件，其中包括仅复制已更改的文件，并检测可能的版本冲突，其中源和远程站点上的相同文件已分别编辑。复制Web工具无法合并单个文件中的更改;只有完整的文件可以被复制。
，我已经做了两件事情是：
1）使用Web部署项目，以编译和清理建设以及移交web.config部分，如果更换环境之间的配置变化。 2）使用楠来完成所有的建筑物，归档和复制的以重复的方式。
Web部署项目最终创建一个MSBuild文件，可用于替代NAnt;然而，我来自Java背景，并且一直使用Ant，所以NAnt是我在.Net中的首选。如果添加了NAnt Contrib任务，则不仅可以部署这些文件，还可以处理诸如源代码管理（包含它不属于默认任务）和Sql Script Execution等项目以进行更改。
目前我使用这两个选项在一起。我有我的NAnt构建文件通过MSBuild调用Web部署项目。通过为每个环境配置管理器设置，它允许我自动管理web.config部分替换，并且仍然对我的复制和存档发布有相当好的控制。
希望这会有所帮助。
目前我们使用JetBrains的TeamCity，并让其他人设置构建脚本！它非常简单，我们在CI服务器上使用MSBuild。我还使用Web部署项目来正确构建网站，但有时候可能会有点费力地让它正确设置。 – Hooloovoo 2009-06-10 11:56:20
我们使用web部署项目和VS 2008项目来从webdeployment &其他项目的输出创建.msi。一个名为'setup'的普通Windows应用程序用于执行大量数据库创建和初步工作，而不是尝试使用自定义步骤自定义安装项目。自己做这件事比试图自定义MS代码要容易得多。这个Windows应用程序然后调用用户需要的正确的.msi文件。
团队基础构建每天晚上运行以重建解决方案并将所有内容复制到任何人都可以访问的“发行CD”目录，并在最新的“发行版”上进行测试。 说实话，TFS的构建对于像我们这样的小团队来说有点过分了，我只用它，因为我习惯了。
在以前的公司，我们使用这个http://www.finalbuilder.com/，我可以推荐它以方便使用和支持的软件数量。
1）MSBUILD建设项目
2）FTP文件到生产环境
3）复制/手动粘贴到每个Web服务器
对于内部网站，我们与SVN结合使用CruiseControl让网站自动重建。
理论上，如果您可以将驱动器远程映射到客户端的Intranet，则可以通过VPN扩展此模型。或者一个更加快速和肮脏的解决方案可能是使用像SyncBack这样的工具来同步包含为该站点编译的DLL的远程文件夹。
我们有专用的DEV，TEST，STAGE和PRODUCTION服务器。
我们也有一个专门的生成机器运行巡航控制。
巡航控制配置为持续集成构建，该构建在签入代码后运行。它还配置为单独的开发，质量保证，阶段和生产任务。
要部署到开发中，首先从SVN中检索代码并构建，然后将“预编译的Web”文件夹复制到开发网站，并将Web服务项目复制到开发应用程序服务器。巡航控制还被配置为在构建开始之前对源代码进行“标记”，以便我们稍后可以重新构建构建，或者如果我们需要做一个热修复，则可以从标记分支。
要部署到QA，文件将从开发机器复制到QA机器。
同样，要部署到舞台，将文件从QA机器复制到舞台机器。
最后，要部署到生产环境，这些文件将再次从舞台机器复制到生产机器。
要配置每个环境，我们有一个自定义工具，它是修改连接字符串的每个环境的巡航控制任务的一部分，“debug = true | false”，“customErrors = Off | RemoteOnly”以及其他特定于环境的设置。
因此，每个环境都可以通过巡航控制仪表板上的按钮进行部署。
一个需要注意的是，我们目前在巡航控制配置文件中配置了生产数据库密码......将它移动到其他地方会很好！
最后，让我补充一点，即使我们的生产机器在专用主机设备中，服务器也可以从我们的Cruise Control机器访问，这使得生产部署非常容易。唯一的手动步骤是加密web.config文件并删除Cruise Control提供的“AppOffline.html”文件。
让我知道如果这能帮助，或者如果您有任何疑问。
谢谢！
由于我发布了这个原始问题，我发现了WiX。它是开源的，免费的。这也是Microsoft用于开发Office 2007部署包的原因。一旦您了解了基本知识，使用它似乎很容易，并且该界面允许您在安装时选择和选择组件。 – Hooloovoo 2009-12-03 14:29:47
只是一个更新;应用发布自动化工具是专门为此设计有一群引人注目的工具在那里寻找到我最常跨越5个专用网络拆分工作比较https://en.wikipedia.org/wiki/Application_release_automation – 2016-06-27 20:56:19