我目前使用Web Deploy http://learn.iis.net/page.aspx/346/web-deploy/发布我的MVC2应用程序。它曾经可以很好地工作，但是现在到了我无法继续使用它的地步：
当MVC应用程序很小且只有几个用户时，它很容易发布。只需右键单击Visual Studio中的项目，然后选择“发布”。而且由于只有少数用户，因此很容易找到没有人使用该站点进行快速更新的时间。
然后，该应用程序变得更大，并拥有更多的用户。 “发布”操作开始花费的时间越来越长，有时会超时。即使我在部署之前回收了应用程序池，仍然花费了很长时间。
而且，很难找到没有人使用该网站的时间，因此可以在不影响任何人的情况下进行更新。
然后，“发布”操作开始每次都超时，因此我不得不根据之前未解决的问题切换到手动部署：Visual Studio 2010 - web deploy times out - what to do?
现在，手动部署花费的时间越来越长，从5到20分钟。而且用户数量已大大增加，因此部署总是会影响某人（响应时间慢，超时，站点不可用等）
那我该怎么办？除了使用Web部署，还有更好的选择吗？
编辑：
今天的部署花了18分钟才能发布49个更改的文件。这种情况简直荒唐可笑，是我们网站目前最大的弱点之一。因此，为了解决这个问题，我正在开始一个相当大的赏金计划。
其他一些可能会导致解决方案的问题：
当只更改了几个文件时，为什么要花这么长时间？
为什么Web部署zip总是包含整个代码库，而不仅仅是更改的文件？
为什么我不自己手动复制更改的文件并跳过整个Web部署？但是，很难手动找出已更改的文件。我使用SVN-是否可以仅输出两个分支之间已更改的文件？
我还想问什么但还没有想到的其他问题？
回答答案：
回复：http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_24.html这正是我进行部署的方式，并且是一种理想的方法。 Web部署可以正确识别哪些文件已更改，但是它超时并且没有发布。该解决方案中大约有2500个文件，也许要花很长时间才能确定哪些文件被更改了？也可能是publish具有较短的超时值，而仅上传15mb zip文件占用了所有时间。
我确实可以完全控制服务器，并且它确实支持Web部署。实际上有两台服务器：主活动服务器和一台冗余服务器，如果第一台服务器倒塌，我们将保留这些服务器。因此，任何解决方案都必须易于部署到多个服务器上（Web部署在停止工作之前是理想的）。
建议为每个发行版创建一个新文件夹，然后仅将IIS更改为指向该新文件夹，这听起来像在发布期间会减少停机时间/减速时间。但这是一个非常手动的过程，我更喜欢自动化的过程。
编辑＃2
我设法缩小了范围，并确切地找到了它的慢速位置-但不是为什么。这来自部署日志：
[9/02/2011 12:11:56 a.m.] Performing synchronization pass #1.
[9/02/2011 12:11:56 a.m.] Parameter entry 'IIS Web Application Name/1' is applicable to 'iisApp/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp' because of its scope.
[9/02/2011 12:11:56 a.m.] Parameter entry 'IIS Web Application Name/2' is applicable to 'setAcl/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp' because of its scope.
[9/02/2011 12:11:56 a.m.] Parameter entry 'IIS Web Application Name/2' is applicable to 'setAcl/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp' because of its scope.
[9/02/2011 12:11:56 a.m.] Parameter entry 'Add write permission to App_Data Folder/1' is applicable to 'setAcl/C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data' because of its scope.
[9/02/2011 12:11:56 a.m.] Source createApp (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest['False','True']). Update pending.
[9/02/2011 12:11:56 a.m.] Update operation on createApp (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) skipped because of rule CreateApplicationRule.
[9/02/2011 12:11:56 a.m.] Source filePath (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data\Create.sql) does not match destination (Default Web Site/virtual-dir/App_Data\Create.sql) differing in attributes (size['259691','259697'],lastWriteTime['02/08/2011 10:45:20','02/06/2011 03:48:16']). Update pending.
[400 lines of file updates skipped, time expired 2 seconds ....]
[9/02/2011 12:11:58 a.m.] Delete operation on filePath (Default Web Site/v2/zzz_app_offline.htm) skipped because of rule DoNotDeleteRule.
[9/02/2011 12:11:58 a.m.] Source setAcl (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest['False','True'],setAclUser,setAclAccess). Update pending.
[9/02/2011 12:11:58 a.m.] Updating setAcl (Default Web Site/virtual-dir/).
[9/02/2011 12:13:47 a.m.] Source setAcl (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp) does not match destination (Default Web Site/virtual-dir/) differing in attributes (isDest['False','True'],setAclUser,setAclAccess). Update pending.
[9/02/2011 12:13:47 a.m.] Updating setAcl (Default Web Site/virtual-dir/).
[9/02/2011 12:17:11 a.m.] Source setAcl (C:\src\Site.2010\Site.UI\obj\Release\Package\PackageTmp\App_Data) does not match destination (Default Web Site/virtual-dir//App_Data) differing in attributes (isDest['False','True'],setAclUser,setAclAccess). Update pending.
[9/02/2011 12:17:11 a.m.] Updating setAcl (Default Web Site/virtual-dir//App_Data).
[9/02/2011 12:17:11 a.m.] The dependency check 'DependencyCheckInUse' found no issues.
[9/02/2011 12:17:11 a.m.] The synchronization completed in 1 pass(es).
缓慢的原因是
"Updating setAcl"组件。我正在检查开发箱和服务器箱的ACL，以了解有什么不同。但是，将ACL从开发箱复制到服务器箱似乎是一个非常糟糕的主意！我已经在服务器上设置了ACL。 最佳答案
我将从尝试隔离发生超时的地方开始。您提到了一个15MB的zip文件，其中包含2500个文件，这对我来说并不算太大。您是否尝试过在Visual Studio中创建部署程序包，然后直接在服务器上运行它？这将使网络延迟消失，这对于超时而言是一个非常基本的变量。
至于为什么需要上载包含整个应用程序的zip的原因，您需要记住对已更改内容的实际标识，以及随后在IIS中进行的所有部署。它不是本地计算机上的Visual Studio或msdeploy来对此进行说明。
至于为什么您不只是手动复制更改的文件的原因，在您引用的我的博客文章中已进行了总结，总之，这很麻烦且容易出错。这意味着您需要有意识地完成“ 2,500个文件中的哪个刚刚更改”的思想过程，而不是简单地说“使我的目标站点与我的开发版本相匹配”。您没有提到是否要发布web.config，但是显然config转换是简单的CTRL-C然后CTRL-V方法麻烦的另一个重要原因。
尝试直接从SVN进行更改也有风险。您的第一个问题是，要发布适当的更改，您需要对要更新的修订的完整性和准确性有完全的信心。然后，您将不得不尝试将它们同步到目标，而您又回到了上一段中提到的相同问题。另一个大问题是版本控制目标代码总是令人讨厌。您将与项目中的其他任何人处于永久冲突状态，而VCS根本不打算以此方式运行。
我的建议是专注于解决问题的根本原因-Web Deploy正在超时-而不仅仅是尝试解决这些症状。从长远来看，仅手动发布更改或弄乱IIS绑定只会给您带来更多麻烦，并在短期内会带来更多工作。了解如何共享创建包，将其复制到服务器然后在本地执行该包的结果，我们将从那里获取它。按设计工作后，您应该会看到部署不超过几分钟，并且站点中断以秒为单位。
顺便说一句-您可能还想添加一下PC与服务器之间的延迟时间，以及通过HTTP传输15MB文件通常需要多长时间。
关于asp.net-mvc - 使用Web Deploy发布ASP.NET MVC2网站，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4885133/