发布一个ASP.NET MVC2站点Web部署 [英] Publishing an ASP.NET MVC2 site with Web Deploy

问题描述

我目前使用的Web部署，<一个href=\"http://learn.iis.net/page.aspx/346/web-deploy/\">http://learn.iis.net/page.aspx/346/web-deploy/发布我的MVC2应用程序。它曾经工作得很好，但现在却到了地步，我不能继续使用它：

I currently use Web Deploy, http://learn.iis.net/page.aspx/346/web-deploy/ to publish my MVC2 app. It used to work well, but now it is got to the point where I can't continue using it:

在该MVC应用程序很小，只有很少的用户很容易发布。只要右击Visual Studio中的项目，然后选择发布。而由于当时只有很少的用户很容易发现，当没有人使用该网站做一个快速更新的时代。

When the MVC app was small and had only a few users it was easy to publish. Just right click the project in Visual Studio and choose "Publish". And because there were only a few users it was easy to find a time when no one was using the site to do a quick update.

然后，应用程序越来越大，并有一些更多的用户。 发布行动开始服用的时间越来越长，有时超时。甚至当我回收应用程序池部署之前它仍然花了很长的时间。

Then the app got bigger and had a few more users. The "Publish" action started taking longer and longer and occasionally timing out. Even when I recycled the app pool before deploy it still took a long time.

此外，它越来越难找到时，没有人使用的网站，以便更新可以在不影响任何人做了一次。

Also it became harder to find a time when no one was using the site so the update could be done without affecting anyone.

然后发布行动开始超时每一次，我不得不切换到手动部署按照这个早期没有答案的问题：<一href=\"http://stackoverflow.com/questions/4133485/visual-studio-2010-web-deploy-times-out-what-to-do\">Visual Studio 2010中 - 网络部署超时 - 怎么办？

Then the "Publish" action started timing out every single time, and I had to switch to manual deployment as per this earlier unanswered question: Visual Studio 2010 - web deploy times out - what to do?

现在手动部署正在越来越长，从5到20分钟。和用户的数目已显著增加，所以在部署始终影响着某人（缓慢的响应时间，超时，站点不可用，等）

Now the manual deploy is taking longer and longer, from 5 to 20 minutes. And the number of users has grown significantly, so the deployment always affects someone (slow response times, timeouts, site unavailable, etc)

所以，我该怎么办？有没有使用Web部署一个更好的选择？

So what can I do? Is there a better alternative to using web deploy?

编辑：

今天的部署花了18分钟，刚刚发布49更改的文件。这种情况仅仅是荒谬的，是我们网站的最大弱点之一，现在。于是我开始在解决这个的希望一个体面的大小赏金。

Today's deployment took 18 minutes to publish just 49 changed files. The situation is just ridiculous and is one of the biggest weaknesses of our site right now. So I'm starting a decent sized bounty in the hopes of solving this.

一些可能会导致解决方案的更多问题：

Some more questions that may lead to a solution:

• 为什么它会这么长的时间，当只有几个文件已被修改？


• 为什么Web部署拉链总是包括整个codeBase的并不仅仅是更改的文件？


• 为什么不让我手动复制已更改的文件我和跳过整个网络部署？但是，很难手动制定出哪些文件已经改变。我使用SVN - 它有办法只输出文件已经两个分支
之间的变化？

• 我应该问什么其他问题，但有没有想过没有？

• Why would it take so long when only a few files have been changed?
• Why does the web deploy zip always include the entire codebase and not just changed files?
• Why don't I just manually copy the changed files myself and skip the whole web deploy? But it is hard to manually work out what files have changed. I use SVN - does it have a way to output only files that have changed between two branches?
• What other questions should I be asking but haven't thought of yet?

在回答的答案：

回复：<一href=\"http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_24.html\">http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_24.html这正是我是怎么做的部署，并且将是一个理想的方法。 Web部署能够正确地识别哪些文件已经改变了，但它超时并没有发布发生。大约有2500个文件在解决方案中，也许它花费的时间太长，以确定哪些改变？或者，它可能是发布了一个简短的超时值和刚刚上传15MB的zip文件，使用所有的时间了。

Re: http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_24.html This is exactly how I was doing the deploy, and would be an ideal method. Web deploy does correctly identify which files have changed, however it times out and no publish occurs. There are around 2500 files in the solution, perhaps it is taking too long to identify which ones are changed? Or it could be that publish has a short timeout value and that just uploading the 15mb zip file uses all that time up.

我确实有对服务器的完全控制，而且它支持的网络部署。实际上有2台服务器：主活的服务器，和一个冗余服务器，我们的情况下，保持准备第一翻倒。因此，任何解决方案必须易于部署到多台服务器（网络部署是理想的，直到它停止工作）。

I do have full control over the server, and it does support web deploy. There are actually 2 servers: the primary live server, and a redundant server that we keep ready in case the first falls over. So any solution has to be easy to deploy to more than one server (web deploy was ideal until it stopped working).

每个版本创建一个新的文件夹，然后只是改变IIS指向该新文件夹的建议听起来像它会导致更低的停机/ slowtime期间，当发布。但它是一个非常手动过程，我想preFER东西更加自动化。

The suggestion of creating a new folder for each release and then just changing IIS to point to that new folder sounds like it will result in lower downtime/slowtime when during the publish. But it is a very manual process and I would prefer something more automated.

编辑＃2

我设法缩小它，发现它的确切位置是缓慢的 - 然而不知其所以然。这是从deploy日志：

I have managed to narrow it down, and found exactly where it is slow - but not why. This is from the deploy log:

[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).

缓慢的原因是更新SETACL组件。我研究的发展框和服务器框的访问控制列表，看看有什么不同。然而，它似乎是一个非常糟糕的想法到ACL从开发框复制到服务器框！我已经有ACL设置就好在服务器上。

The cause of the slowness is the "Updating setAcl" component. I am examining the ACLs of the development box and server box to see what is different. However it seems like an extremely bad idea to copy the ACL from a dev box to a server box! I already had the ACL set up just fine on the server.

推荐答案

我试图孤立，其中超时发生开始。你提到了一个15MB的zip 2500文件，这并不在我看来他们特别大。您是否尝试过创建在Visual Studio部署包然后直接在服务器上运行呢？这将需要网络延迟出这是一个pretty根本变量，当涉及到超时的图片。

I'd start by trying to isolate where the timeout is happening. You've mentioned a 15MB zip with 2,500 files which doesn't strike me as particularly large. Have you tried creating a deployment package in Visual Studio then running it directly on the server? This will take network latency out of the picture which is a pretty fundamental variable when it comes to timeouts.

至于为什么需要上传与整个应用程序的ZIP，你需要记住的是什么改变了实际的识别和随后部署到IIS一切都发生在服务器上。这是你的本地计算机上调用这个镜头上没有Visual Studio或msdeploy。

As for why a zip with the entire application needs to be uploaded, you need to remember the actual identification of what has changed and subsequent deployment into IIS all happens on the server. It's not Visual Studio or msdeploy on your local machine calling the shots on this.

至于为什么你不只是手动更改的文件拷贝过来，它总结了你引用我的博客文章，但简而言之，它是费力又容易出错。这意味着你需要有意识地通过，这是我2500的文件只是改变了，而不是简单地说：让我的目标网站符合我的开发版本的思维过程工作。您还没有提到，如果你发布的web.config或没有，但很明显的配置转换的另一个重要原因简单CTRL-C然后CTRL-V的做法是麻烦的。

As for why you don't just manually copy the changed files over, it's summarised in my blog post you've referenced but in short, it's laborious and error prone. It means you need to consciously work through the thought process of "which of my 2,500 files just changed" rather than simply saying "make my target site match my development version". You haven't mentioned if you're publishing the web.config or not but obviously config transforms is another important reason why the simple CTRL-C then CTRL-V approach is cumbersome.

试图只是直接从SVN采取的改变也是有风险的。你的第一个问题是你需要在修订的完整性和准确性完全信任你从更新的 的，如果你拿到公​​布相应的更改。你然后想把这些同步到目标左，你回到在previous款提出了同样的问题。另一个大问题是版本控制对象code总是讨厌的;你会在冲突的永久状态，对项目他人，VCS根本就没有打算发挥这种方式。

Trying to just take a change directly from SVN is also risky. Your first problem is you need to have complete confidence in the integrity and accuracy of the revision you're updating from if you're to get the appropriate changes published. You're then left with trying to sync these to the target and you're back at the same issues raised in the previous paragraph. The other big problem is versioning object code is always nasty; you'll be in a perpetual state of conflict with anyone else on the project and VCS is simply not intended to function this way.

我的建议是把重点放在解决问题的根源 - 网络部署已超时 - 而不是简单地试图解决的症状。仅手动发布变更或瞎搞与IIS绑定只会在长期内创造更多的麻烦你并在近期内大量的工作。看你怎么去共享创建一个包，将它复制到服务器，然后在本地执行它的结果，我们就会把它从那里。一旦你拥有了它按设计工作，你应该看到的部署不超过以秒为单位几分钟，网站停运了。

My advice would be to focus on solving the root cause of the problem - Web Deploy is timing out - rather than simply trying to work around the symptoms. Manually publishing changes only or messing around with IIS bindings is only going to create more trouble for you in the long run and a lot more work in the immediate term. See how you go sharing the results of creating a package, copying it to the server then executing it locally and we'll take it from there. Once you have it working as designed, you should be seeing deployments no more than a few minutes and site outage measured in seconds.

顺便说一句 - 你可能也想补充您的PC和服务器多久通常需要通过HTTP传输一个15MB的文件之间什么样的延迟

BTW - You might also like to add what sort of latency you have between your PC and the server and how long it would normally take to transfer a 15MB file over HTTP.

这篇关于发布一个ASP.NET MVC2站点Web部署的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！