ASP.NET is popular among developers for a variety of reasons, including its compilation model, and rightly so. The first time an ASP.NET page is requested, the runtime parses the page’s markup code, produces a C# or Visual Basic .NET class, and finally compiles it on the fly. The newly created assembly is automatically loaded in the page’s AppDomain, and the contained class that represents the requested resource is instantiated. At the same time the dynamic assembly is created, an XML companion file is created in a temporary folder to preserve link information between the assembly name and the originally requested ASPX resource. In this way, whenever the ASPX file is updated, the linked assembly is invalidated. Upon the next request, the assembly would be recreated. Clean and effective.
However, many (should I say, all?) developers use Visual Studio .NET to create their applications. And Visual Studio .NET promotes the code-behind model for source code. What's that, you ask? Basically, a C# or Visual Basic .NET class file is associated with each ASPX markup file and contains any glue code needed to the page. At the very minimum, a code-behind class contains a handler for page events such as Init, Load, and PreRender. The key thing that is going on here is that each ASP.NET resource is split in two: a markup file (whose extension is .aspx) and a code-behind file (whose extension depends on the language of choice).
If the ASPX markup file gets modified, the next request triggers the compilation mechanism and generates a newer assembly. If the code-behind class is modified, instead, nothing of the kind happens. What's up?
In a Visual Studio .NET project, all class files are compiled into a single assembly, which is then deployed with the ASPX endpoint files. Unlike ASPX endpoints, no C# or Visual Basic .NET class file is ever deployed in the production environment. Hence, there's no way for the runtime to detect changes on class files and update the related assemblies. However, even if you decide to deploy class files on the server, nothing would happen anyway because the ASP.NET runtime is not configured to monitor C# or Visual Basic .NET classes for changes, unless these classes are explicitly bound to ASPX endpoints. As you may have guessed already, this just doesn't occur with code-behind classes.
Visual Studio .NET uses the CodeBehind attribute in the @Page directive to track page-class associations. Unfortunately, the ASP.NET runtime doesn't recognize this attribute. The ASP.NET runtime, instead, recognizes the Src attribute, which plays a similar role outside the realm of Visual Studio .NET. For any ASPX page that references a class file through the Src attribute, the ASP.NET runtime requires the class be available on the server and compiles it on the fly. In this case, any changes to the class file are promptly detected and lead to a new assembly.
Is there a way to combine the two models together? Sure.
You create an ASPX page in Visual Studio .NET and let Visual Studio .NET create a code-behind class for you. Next, you select the code-behind class in the Solution box and set the Compile property to None in the Properties box. At the same time, you add an Src attribute to the ASPX endpoint that links the code-behind class. You don't lose any of the Intellisense facilities that only Visual Studio .NET delivers, and you're still able to introduce changes to classes that are automatically detected without an intermediate compilation step.
As a final note, be aware that with ASP.NET 2.0, you'll enjoy a brand new compilation model that resolves these issues at the root.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant
based in Rome, Italy. Dino is a contributing editor to Windows Developer
Network and MSDN Magazine, and the author of several books for Microsoft
Press including Building Web Solutions with ASP.NET and ADO.NET
and Applied XML Programming for .NET. Contact Dino at [email protected].
