Hey ASP.NET: File it in the Circular References File

Quick quiz: What can make your ASP.NET 2.0 web application compile about 50% of the time? You know, now-it-compiles, now-it-doesn't? Circular References.

The designers of ASP.NET 2.0 were extremely worried about performance, especially for large websites. (Where large is a lot of controls, not a lot of visitors.) The ASPX 1.1 behavior of compiling an entire website's ASCX/ASPX markup was simply crippling to developers. So the ASPX 2.0 guys figured, hey, let's just compile pieces of the web application when they're needed. To this end they cordoned off the App_Code folder which effectively becomes its own assembly. Fine -- once you know the trick.

But their next choice was a little staggering. They decided to compile non-deterministic subsets of the application. If I hit /fred.aspx, the application might decide to also compile /ethel.ascx and /lucille.ascx... or it might decide that /ricardo.aspx "feels right" today. Again, if that floats the ASPX team's collective boats, why not. But unfortunately this non-deterministic model will occasionally choose subsets of the web site that do not correctly compile! The very semantics of program correctness are now random!

The issue is with controls which engage in what the ASPX folks (incorrectly, I believe) term circular references. Brendan Tompkins summarizes the issue and its solution quite well. If you have a true circular reference (fred.ascx requires ethel.ascx requires lucille.ascx requires fred.ascx) ASPX says you're hosed and break the dependency by introducing an abstract base class. Bummer, but okay. However because the compilation algorithm chosen by the ASPX pre-compiler is non-deterministic but usually folder-based it is possible for the compiler to believe that controls participate in a circular references when in fact only their folders do. You will drive yourself nuts trying to find the actual circular reference!

You can keep all your controls in a single folder, or at least only a few folders. That's a shame. But the real shame is that if you actually use Reflector to read the compiler in ASPX, you'll see it does a lot of homework to figure out who depends on what and how to chunk the compile up.

But surely, if the keen eager boys and girls from Redmond are already doing so much work as to determine the dependency graph of controls in the application, couldn't they apply any of a bazillion graph connectivity algorithms to compile subsets that are guaranteed to compile?! If you feel like hiding your extremely fancy compilation algorithms from me, please do so. Don't expose non-deterministic semantics into the framework!.