Today I came across Jon Galloway’s blog entry on pre-compiling ASP.NET web applications in v1.1. I have been looking for this for a while now. I tried it on with the web application I am currently developing on my development machine (Win XP Professional).
And here are the observations.
1. The handler compiles all the aspx files in the folder irrespective whether the file is part of your project. This was very troublesome for me as on my development machine there existed old aspx files which were removed from source control but they existed on my disk.
2. If an error occurs during compilation of a page the compilations stops and no other pages are compiled. Aspx pages are not classes which refer each other I think if a error occurs on a page that page should be skipped and the next page should be compiled and the list of pages which caused errors should be generated. For each time an old aspx file (no longer used in the project) was found I had to go and delete it and wait for the next error page.
3. If an error occurs during compilation and is then corrected. Restarting the pre-compilation doesn’t work. One needs to re-start the ASP.NET worker process for the compilation to work. That’s a major issue. We cannot keep on restarting the worker process each time we encounter an error during pre-compilation.
4. The handler only compiles the aspx files (and all the ascx user controls refrenced in the aspx ) in the specified folder not in all aspx pages the in the web application. In case one is developing a large website and the aspx pages are grouped in different folders one has to go to each folder for the pages to compile.
5. In my case I had forms authentication enabled so the ways I could make pre-compilation work is to either disable forms authentication for the time I am pre-compiling or through web.config grant access to the handler in each folder. Neither can be used for production environments as changing the web.config after compilation will cause the aspx to be recompiled by the runtime. The other smart thing would be login the website and the call the pre-compile page. But none of these solutions are good enough. The handler should behave something like the debug works. I can configure whether debug information is available on remote machines or only on local machines. Similarly I should be able to configure that I can make a pre-compilation request from a remote location or from a local machine. And an authorization mechanism where I can grant access to pre-compilation easily rather then listing out each folders in which pre-compilation is allowed
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.
Perhaps the System.Web.Handlers.BatchHandler is used when the web.config
ReplyDelete\configuation
\system.web
\compilation
\debug, batchTimeout, maxBatchSize, maxBatchGeneratedFileSize are set?
These settings control whether the ASP.NET engine compiles ASPX pages individually, or in 'batches'! IF debug="false":
when an ASP.NET file is requested for the first time the framework conducts a batch compilation on that directory. It compiles files in that directory only into a DLL. It does not traverse subfolders. You need to hit a page in every folder to have each folder batch compiled. This is an important point.
-- Sounds like what the BatchHandler is doing...
For a custom approach to pre-compilation, see Joni Zhang's Precompile.axd HttpHandler and/or my 'improvements'
HTH