Tuesday, April 1, 2008

Optimizing ASP.NET 2.0 Build Performance


VS 2005 supports two project-model options: VS 2005 Web Site Projects and VS 2005 Web Application Projects.

This blog post summarizes how to best optimize the build performance with Visual Studio 2005 when using Web Site Projects/ Web Application Projects.

VS 2005 Web Site Projects [WSP]:

· Built-in with the initial VS 2005 release.

· Provide a project-less based model for doing web development that uses that same dynamic compilation system that ASP.NET 2.0 uses at runtime.

VS 2005 Web Application Projects [WAP]:

· Supported as a separate download.

· Provide a project model that uses a MSBuild based build system that compiles all code in a project into a single assembly.

· It is different than VS2003 in terms - Similar to VS 2003 - but without many of the limitations that VS 2003 web projects had with regard to FrontPage Server Extensions, IIS dependencies, and other issues.

From a feature perspective there is no "one best option" to use - it really depends on your personal preferences and team dynamics. For example: a lot of enterprise developers love the VS 2005 WAP option because it provides a lot more build control and team integration support, while a lot of web developers love the WSP because of its "just hit save" dynamic model and flexibility.

Two articles you might find useful to decide which works best for you is this MSDN whitepaper that includes some comparisons between the two models, and Rick Strahl's Web Application Projects and Web Deployment Projects are Here article that provides a good discussion of the pros/cons of the different options.

Which Project Option Builds Faster?

The answer is – WAP. Assumption – Full Build is considered.

By "full build" I mean cases where every class and page in a project is being compiled and re-built - either because you selected a "Rebuild" option within your "build" menu, or because you modified code within a dependent class library project or in the /app_code directory and then hit "build" or "ctrl-shift-b" to compile the solution.

Few reasons:

· The main reason is that the VS 2005 WAP option only compiles your page's code-behind code and other classes within your project.

· It does not analyze or compile .aspx pages i.e the content/controls/in-line code within your .aspx pages -- which means it does not need to parse those files.

· On the downside this means that during compilation it will not check for errors in those files. On the positive side it makes compilations much faster.

This downside can be fulfilled by adding a VS 2005 Web Deployment project to your solution for deep verification. Required is to configure this to run only when building "release" or "staging" builds of your solution (to avoid taking a build hit at development time), and use it to provide a deep verification of both your content and source code prior to shipping your app.

However there are techniques to improve the build process in WSP and WAP.

Tricks for Optimizing WSP Build Times

· Verify that you are not suffering from an issue I call "Dueling Assembly References".

· Keep the number of files in your /app_code directory small. It happens only when you have lots of directories or dozens of files. In such cases recommend is to add a separate class library project to your VS solution and move these classes within that instead since class library projects compile faster than compiling classes in the /app_code directory.

Note: Keeping less number of files in app_code also reduces the switch time from source to design-view within the VS HTML designer.The designer causes the /app_code directory to be compiled before the designer surface loads. Reason behind this compilation is - you can host controls defined within /app_code in the designer.

· Enable the On-Demand Compilation option for your web-site projects.

What does ‘Build Page’ mean - When you edit a page and then hit F5 (run with debugging) or Ctrl-F5 (run without debugging) the solution will compile as below.

o All of the class library projects like before,

o Then compile the /app_code directory and Global.asax file, and

o Then instead of re-verifying all pages within the web-site it will only verify only the current page you are working on, and any user controls that the page references.

o Then on-Demand - ASP.NET will automatically re-compile any other page or control you access at runtime -- so you will always have an up-to-date and current running application

With large (and even medium) projects with lots of pages, this can obviously lead to major performance wins

However, If you want a way to force a re-build to occur on pages not open, or across all pages within the web-site, you can use the "Build Web Site" menu options within the "Build" menu of Visual Studio.

What does deselecting ‘Build Web site as part of solution’ mean: When you make Ctrl + Shift + B, below happens.

o Compiling all class library projects.

o But will not re-build all pages within your web-site project.

Tricks for Optimizing WAP Build Times

· Watch out for Virus Checkers, Spy-Bots, and Search/Indexing Tools.

VS hits the file-system a lot, and obviously needs to reparse any file within a project that has changed the next time it compiles. Several times are cases where virus scanners, spy-bot detecters, and/or desktop search indexing tools end up monitoring a directory containing a project a little too closely, and continually change the timestamps of these files (they don't alter the contents of the file - but they do change a last touched timestamp that VS also uses). This then causes VS to have to re-build it again. Check for this if this has became a practice and you are seeing build performance issues, and preferably disable such directories from being scanned.

· Turn off AutoToolboxPopulate in the Windows Forms Designer Options - To disable this option, select the Tools->Options menu item, and then unselect the Windows Forms Designer/General/AutoToolboxPopulate checkbox option.

· Examine which 3rd party packages are running in Visual Studio.

There are a lot of great 3rd party VS packages that you can plug into Visual Studio. These deliver big productivity wins, and offer tons of features. Occasionally I've seen issues where performance or stability is being affected by them though.

Thanks & Regards,

Arun Manglick || Tech Lead

No comments:

Post a Comment