This is a story of intrigue.
Ok, perhaps that is a bit overblown. This is really a story of
schizophrenia. It is the story of a method
PageParser.GetCompiledPageInstance that exhibits a different behavior
depending on whether or not you have the
attribute set to
The problem first came up when deploying the most recent builds of
this attribute set to
false. This was the natural response to Scott
Guthrie’s admonishment, Don’t Run Production ASP.NET Applications with
However, this affected Subtext in an unusual manner. Subtext employs an
URL rewriting mechanism I wrote about
It relies on the using an
IHttpHandler that is created by calling
I will spare you all the details and cut to the chase.
GetCompiledPageInstance takes in three parameters:
- virtualPath (string)
- inputFile (string)
- context (HttpContext).
In the initial request to the Subtext root, the values for those parameters on my local machine are:
- virtualPath = “http://localhost/Subtext.Web/Default.aspx”
- inputFile = “c:\projects\Subtext.Web\DTP.aspx”
- context = (the current context passed in by the ASP.NET runtime)
The interesting thing to note is that there is an actual
Default.aspx located at
http://localhost/Subtext.Web/Default.aspx. When the
compilation option was set to
true, this method would return a
compiled instance of DTP.aspx (hence the URL rewriting).
But when I set
debug="false", it would return a compiled instance of
Default.aspx. Holy moly!
I confirmed this by attaching a debugger and going through the process
multiple times. Using Reflector,
I started walking through the code for
my eyes started to burst. There is a lot of machinery at work under the
hood. I eventually found some code that appears to generate a URL path
differently based on debugging options. Not sure if this was the
culprit, but it is possible.
debug="false" causes the runtime to perform a batch
compilation. Thus a request for /Default.aspx is going to compile all
*.aspx files in that folder into a single DLL. Setting that debug value
to true causes ASP.NET to compile every page into its own assembly.
My fix is a bit of a hack, until I can get a deeper understanding of
what is really happening. As I see it, calling
virtualPath that points to a one file while passing in a
different physical file path to
inputFile is causing some confusion.
Perhaps due to the batch compilation.
To remedy this, I simply have a check before we call
GetCompiledPageInstance to check the end of the
/Default.aspx (case insensitive of course). If it finds that string,
it truncates the default.aspx portion of it. That seems to do the
trick for now since this is pretty much the one place in which URL
rewriting would attempt to rewrite a url that itself points to a real
For a nice look under the hood regarding the
compilation option, check
out this post by Milan
Please keep in mind that this is a separate issue from deploying your compiled assemblies in debug mode or with debug symbols. This has to do with the ASP.NET runtime compiling the ASPX files at runtime.