Do your users find errors like this before you do?

The ASP.NET code-behind model (basically) results in:

• 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.

TODO:

• provide authentication example
• a NAnt task to confirm compilation of a website during build

P.S. 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...

Other .AXDs
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.