As outlined in Tip/Trick: Optimizing ASP.NET 2.0 Web Project Build Performance with VS 2005, the "Build Page" command available within Visual Studio web site projects does the following:
the solution will compile all of the class library projects like before, then compile the /app_code directory and Global.asax file, and then instead of re-verifying all pages within the web-site it will only verify the current page you are working on, and any user controls that the page references.
Is there a way to access this functionality from msbuild and / or the command line?
I am setting up an automated build of a large Visual Studio web site project (based on Kentico CMS), which consists of:
Pre-compiling the entire site using aspnet_compiler takes up to 10 minutes, which is too slow for a commit build. Ideally, I'd like to introduce a step that pre-compiles just our custom code. Note that we don't actually deploy the pre-compiled output (not recommended for Kentico sites), this step is intended only to validate the code in the .ascx files.
The best way I've found to reduce the pre-compile time for small changes to large web sites is to use the ASP.Net Compilation Tool (aspnet_compiler.exe) with in-place compilation.
Our build script runs the tool using the following command:
aspnet_compiler.exe -v / -p C:\path\to\MyWebSite
This command specifies the physical path to the web site but does not set the targetDir option, which results in the application being compiled in-place.
The benefit of in-place compilation is that aspnet_compiler will by default only compile files that have changed since the web site was last compiled (you can force it to recompile everything with the -c option). For example, when I run the above command against the web site for the first time, it takes about 10 mins to run. If I then change a single file and run it again, it only takes 30 seconds or so.
You may be curious as to how the compilation tool "knows" which files have changed. Compiling in-place doesn't modify the application being compiled, i.e., you won't end up with files like App_Web_xdqqvn5q.dll and default.aspx.cdcab7d2.compiled in the bin folder of your web application. The output is actually generated within the "Temporary ASP.NET Files" folder. When you specify a physical path (rather than an IIS metabase), a folder within your profile is used, e.g. C:\Users\your.name\AppData\Local\Temp\Temporary ASP.NET Files. Your web application source code is cross-referenced with data stored in Temporary ASP.NET Files to work out what has changed.