Blog Moved To http://weblogs.asp.net/meligy

Cross posting from the new blog @ http://weblogs.asp.net/meligy

  Home  |   Contact  |   Syndication    |   Login
  308 Posts | 3 Stories | 146 Comments | 110 Trackbacks

News

My main blog url now is: weblogs.asp.net/meligy

SponsoredTweets referral badge

Twitter












Tag Cloud


Article Categories

Archives

Post Categories

BlogRoll

About Me:

Heah, this decreased the compilation time for website I work on these days from FIVE+ MINUTES of FROZEN VS 2005 to just TEN- SECONDS of normal build progress messages!!!
Now I can use CTRL+SHIFT+B again :-D.

Note: This is related to VS 2005 normal websites, sites built using VS2005 Application Projects (which is the same build model as VS 2003: single assembly, controls references having to exist in both page markup and code, etc) do NOT face this problem. (I helped a colleague to use the VS 2005 Application Projects on a web project converted from VS 2003, not a bad experience, though you miss some few goodies).

If you're getting VERY LONG build times when compiling your website in VS 2005, while IIS seems to compile changed pages in much shorter time when you first request them (I suppose you already know ASP.NET pages compilation models, although not extremely essential in ths context, that's something you really should know). This may be due to a certain VS 2005 behavior causing some of your DLL references to be loaded repetitively on every single VS 2005 build rather than once when compiling using VS 2005 (typically when two or more DLLs depend on one more DLL, but each depends on a different version of this DLL).

The short solution to this is to remove any "*.Refresh" file (auto generated by VS 2005 for normal websites, this is to make sure the DLL reference is updated same as the original file, as these websites don't have “csproj” / “vbproj“ files to store this) for all the DLLs you don't expect a need to change so often. Samples are ATLAS and ATLAS Control Toolkit, as well as any third party library you may be using like FreeTextBox or so (especially those you know for sure they depend on other DLLs). Beware that you'll need to manually copy these DLL refrences to your site “Bin“ folder if they change.

Note: This problem doesn't take place when you reference the DLL as Project included in the same solution; the ".Refresh" file is generated only for the DLLs you reference by browsing to their location on the file system. (Therefore, you shouldn't encounter this problem with projects generated by ".NET Tiers" O/R mapping CodeSmith template projects for example).

By the way, “.Refresh“ files are not really evil by nature. For more information on / better explaination for the specific problem (yes, this is important information), please check the original post by Microsoft first ASP.NET lead/hero, Scott Guthrie.

Thank you very much Scott, not the first great hit from you, and likely not the last one! :-) ;-)

posted on Monday, July 31, 2006 12:04 AM

Feedback

# re: If you suffer LONG build times with VS 2005 websites... 7/31/2006 5:55 AM Matt Tester
I had a similar problem with the Enterprise Library assemblies I had referenced. Removing the '.refresh' files worked great ... but it just doesn't seem right to have to do that :-)

Post A Comment
Title:
Name:
Email:
Website:
Comment:
Verification: