我们的主网站是10个独立的ASP.NET项目和应用程序的集合。目前，要在新服务器上进行完整部署，需要运行十个单独的msdeploy作业;每个应用程序都是构建，配置（使用配置转换）和打包，但我们没有任何解决方案将所有软件包部署为单个操作。
我可以看到可能在这种情况下工作的几种可能性，但是很想听到任何成功或失败的人在设置类似内容时：
一个包含packages和deploy.cmd脚本的文件夹，其中包含一个“主脚本”，可以依次调用每个应用程序脚本并将该应用程序部署到目标服务器。
使用登台服务器，我们使用生产配置从TeamCity部署每个软件包的最新版本，然后使用msdeploy将该服务器捕获到一个巨大的msdeploy ZIP软件包中，然后将其部署到每个生产服务器上作为单个msdeploy步骤。
创建一个巨大的Visual Studio解决方案，它引用我们代码库中的每个项目（可能通过svn：externals？），编译并交叉引用它们ALL，因此支持使用单个msbuild作业创建一个巨大的单片包，包含我们的整个代码库，从源代码管理的最新版本构建，并为目标环境配置。
我已经研究了Troy Hunt's excellent "You're Deploying it Wrong" series和Scott Hanselman's "Web Deployment Made Awesome"文章，但我认为我正在寻找超越这些方法的一个步骤，这些方法包含多个项目和应用程序，而不必从源代码构建它们一步 - 任何想法？
答案 0 :(得分：2)
我们公司的情况非常相似，我们使用WIX创建了一个安装包。我们的配置转换发生在安装时，所以现在我们创建一个构建，然后通过MSI安装包将它部署到每个服务器。 WIX非常灵活，但也有陡峭的学习曲线。我们使用自己的自定义操作修改我们的配置，但也可以通过其他方式完成。
我们使用Team Foundation Server和MSBuild来完成构建。这非常简单，但确实需要做一些工作才能正确设置与我们一样多的项目和解决方案。
我们研究过的其他选项，甚至尝试过：
我认为Visual Studio中内置的部署工具是针对单个应用程序而设计的，只需几个部署。听起来您需要外部工具和开发工作来更快地部署，并且无需手动执行操作。这就是我们投资上述解决方案的原因，并且它确实得到了回报。
答案 1 :(得分：-1)
我会选择Installshield。