Migrating large asp sites to asp.net - website project

In web forms world of asp.net , visual studio offers two options. WebSite projects and WebApplication projects.   If you are starting a green field project and choose to take web forms route,  website projects are definitely not a good option, especially if the site size is large.   But if the site is being migrated from legacy asp site, it is better to stick with website project.  You are not going to benefit a lot from web  application project, if the individual asp.net pages (not in code behind) are going to contain most of the code.

Following are some of my observations from such an effort.

• Patching gets simpler.   The quickest way to patch an asp page is just copying modified page on to server.   As legacy site is mostly likely contains code a markup combined, this option helps to maintain the new site until these concerns are separated.
  

• Site can be precompiled to check for the asp.net page errors.  In web application option, if the code is in asp.net page,  vs.net is not going to compile asp.net pages.   So there is no way to know if there is a problem with a page until runtime.
  

• Visual Studio crashes every time if you try to convert a large site in to a web application project.  Your web deployment projects won't finish without crashing.  This instability suggests that you should better stick to website project.
  

• Every time you touch the bin folder or web.config or user controls, app domain gets recycled.  This kicks users out.  You should be able to mitigate this a little by choosing some kind of persistent session option.
  

• If you choose to deploy precompiled site, with every patch you will be deploying more dlls than necessary.  This is because every refereced dll is going to produce a new version of the dll that is different from the already deployed version.
  

• Visual studio suffers from huge performance issues, especially when the site is large.  Combined with Resharper, it feels like being in a hell to use the IDE to make small changes.  If you have automated integration tests, then better not to use Visual Studio for simple changes.
  

• You want to turn the 'Build Website' option off, else you will waiting for the compiler to come back for the most part of the work, when ever you modify a sub project item that compiles in to your site's bin.  It is better to defer the build site option to the build server.
  

• Your builds are going to be slow.   Every time if some one checks in the code you need to Clean, Build, PreCompile the while site.  Precompile task runs really slow as it has to compile each page in to its own dll and copy every thing in to new directory.  You can speed this a little with in-place precompilation.
  

• Deploying involves two steps.

Step 1:    Clean, Build, PreCompile -> to make sure that build is still ok

Step 2:     Clean, Build, Copy web files, copy bin files, copy environment specific config files,  -> if you are not deploying the precompiled site

Copy the precompile outputs, copy environment specific files -> if you are deploying precompiled site

• You might not be able to use the built-in web server for testing the application, again due the size of the site.