a ZIP file containing:
You can also view the formatted code
About the code
Based on Joni Zhang's Precompile.axd
implementation, with some improvements for output formatting (and hopefully better
Do your users find errors like this before you do?
The ASP.NET code-behind model (basically) results in:
Learn more about the web.config <compilation> section
and in particular the debug=false setting
explains how the compilation of ASP pages works.
- a DLL in your yoursite/bin directory that contains COMPILED code-behind classes
- ASPX pages which are COMPILED on first use into the /Temporary ASP.NET Files/ directory
The important point is that pages aren't compiled until first access, so a COMPILATION ERROR will not become
obvious until someone accesses the page! That means there's a chance a user will see the
dreaded red&yellow Server Error in '/' Application message!
Wouldn't it be great if there was an easy way to check ALL your ASPX pages to confirm they compile?
Basically, a process that would "pre-compile" all your pages and report the ones that fail?
Jon Galloway discusses the little-known (or not-known-at-all)
System.Web.Handlers.BatchHandler which perfoms a 'batch precompile' of ASPX pages on this blog post:
Precompile.axd in ASP.NET 1.1 with System.Web.Handlers.BatchHandler
(thanks to Scott Hanselman for the link).
DotNetGeek then goes on to
discuss the problems with this
'hidden but built in' approach to ASPX pre-compilation using BatchHandler in ASP.NET 1.1
BUT I think that Handler is there purely for the web.config\compilation settings and not really
for user-implementation. So if we want to pre-compile our ASP.NET 1.1 applications, we should do it ourselves.
There are other good reasons for building something, including being able to report individual page errors (pointed out by
DotNetGeek) and being able to
extend the approach to interact with whatever authentication mechanism might be protecting pages on your site (NOTE:
I have NOT implemented any authentication in the code yet - but it should be easy to see where you might add the code).
To create a 'real' precompilation function,
Joni Zhang has written his own Precompile.axd HttpHandler which accesses each
ASPX page in a site's application directory (and subdirectories). By accessing them, the ASP.NET engine will cause them to
be compiled, either into individual assemblies (if debug=true) or by-folder into batched-up assemblies (if debug=false).
I've updated Joni's code to provide more visual feedback, like this (click to enlarge):
The C# code determines what web location and physical directory it is being run from,
loops through the physical directory tree (recursively) and builds a list of all the *.ASPX files. It then requests each page
via the HttpWebRequest class, which causes the ASP.NET engine to compile the page (if it has not already been compiled).
If a page fails, clicking on the 'Browse' link will open the page so the compilation error can be reviewed.
- provide authentication example
- a NAnt task to confirm compilation of a website during build
DotNetGeek said "Overall the handler
has still some issues and is very primitive to be used in an actual production environment.
I think that’s the reason the handler has not been advertised. I fell its better that I wait for the
ASP.NET v2.0 and see if it is good enough to be used in a production environment."
Sorry to tell you, but I'd say the BatchHandler is being used on EVERY ASP.NET production environment
based on this explanation...
HttpHandlers and HttpModules in ASP.NET 2.0
An Overview of the New Services, Controls, and Features in ASP.NET 2.0
2.0 includes the 'pre-compile' option among a host of other new bits and pieces
Debug Code in Production
Discusses the debug=true|false line in web.config/compilation and how it affects
the compilation of ASPX pages... (I love this site)
ASPX DLL discussion
ASP.NET 1.x does try to compile all pages in a directory into a single
assembly when the first page from a directory is requested.