t's crucial to understand the changes to the compilation process from ASP.NET 1.x to ASP.NET 2.0 so you can debug your Web applications effectively. This article shows you how compilation works now and what has changed from ASP.NET 1.x.
ASP.NET 2.0's release offers many welcome changes and additions to the ASP.NET model of Web development. Compilation and deployment has changed drastically in ASP.NET 2.0 and these changes are somewhat controversial. In this article, I'll look at the stock project model and explain how the different compilation models work. I'll look at the project system, the page parsing mechanism and page compilation, and how applications deploy. Because developers have raised a number of concerns about stock projects, Microsoft recently released a couple of add-ins for Visual Studio that address some of the shortcomings and complaints. The tools are Web Deployment Projects and Web Application Projects and I'll look at these two tools and explain how they complement or replace stock projects.
The New Project Model in ASP.NET 2.0
Microsoft has tightly linked the new project model in ASP.NET 2.0 with the new compilation and deployment features. They completely overhauled the way that page compilation works in the new version without breaking the way that original compilation worked in ASP.NET 1.1.
|Changes to the project model make it quicker and easier to get a new project up and running in ASP.NET 2.0, or to open an existing project.|
The motivation behind these changes in the model was to make it easier to use ASP.NET and Visual Studio for Web development. In Visual Studio 2003, creating a new projector even worse trying to open an existing project moved from another machinewas a fairly involved process that required creating a virtual directory, ensuring that FrontPage extensions were installed, and making sure that the project file was configured correctly to point at the virtual directory before you could even start to look at the project. It's much easier to perform these tasks in Visual Studio 2005.
The changes in the new project model make it quicker and easier to get a new project up and running, or to open an existing project. You can now open a project simply by pointing at a directory and ASP.NET and Visual Studio can figure out from the directory structure how to display, compile, and run that project without any manual configuration or an explicit compilation step. As shown in Figure 1, to open an existing Web Project you can simply point at a directory in the file system and open it as a Web site.
|Figure 1: Opening and creating projects is much easier in Visual Studio 2005 simply by selecting a directory in the file system. Once opened, the directory acts as the project, providing the file content for the project—there's no explicit project file in Web projects.|
The new project system allows you to open projects from a directory, a local IIS server, an FTP site, and a remote site. Local IIS uses the IIS metabase to find the directory on the local machine. Other than that there is not a big difference from a file-based project. An FTP site opens a remote site through an FTP connection and it uses FTP to figure out the project structure in much the same way as a file-based project does, so everything is pulled into the project.
You can also open a Remote Site, which like Visual Studio 2003, requires installing the FrontPage extensions on the remote or local server (accessed through HTTP). The Remote Site configuration is more rigid in that you have to explicitly add files to the projectit doesn't auto-detect content. This project opening format is useful if you want to remotely connect to another machine, but it's also useful for local projects that contain lots of static content that you don't want to automatically include in your project. For example, if you have a root Web site that has subdirectories that are in turn virtual directories, a Remote Site prevents Visual Studio from importing all the child virtual directories, which is not the case with file projects.
The file system project is the easiest and most common way to open a project. Add to that the new built-in Web server that ships with Visual Studio and you can have a new or existing Web application up and running instantly without having to configure anything. Open the directory as a File Web Project in Visual Studio, click View in Browser and your page runs. It's very easy, and this is surely what the ASP.NET designers were shooting for: Making ASP.NET less daunting when creating a new application or running an existing one.
Easy on the SurfaceComplex Underneath
|While project behavior gets easier in ASP.NET 2.0, the underlying model used to provide this simplicity is actually very complex and requires a lot of help from ASP.NET internals to make it happen.|
While project behavior gets easier in ASP.NET 2.0, the underlying model used to provide this simplicity is actually very complex and requires a lot of help from ASP.NET internals to make it happen. Compared with the ASP.NET 1.1 CodeBehind model, which was based purely on simple inheritance, this new model uses run-time control and event generation, partial classes, inferred referencing of assemblies, delayed run-time compilation, and single-page assembly compilation along with considerable help from the ASP.NET runtime and Visual Studio to make it all work.
A lot of magic happens inside the ASP.NET runtime to allow features such as individual page compilation, ensuring proper linking of "reference" assemblies, and making sure that the development environment can display accurate IntelliSense information on all this inferred type information that logistically wouldn't be available until run time. What this means is that you don't plainly see all there is to see at design time in terms of code, and you're relying on Visual Studio to provide you with a rich design-time experience with IntelliSense.
Most of the time you don't need to worry about these internals because they're encapsulated within ASP.NET itself. However, if you go beyond simple scenarios and run into situations where the simple method just doesn't work, you have to fully understand all the intricacies of this complex model to make it work for you. This need for understanding affects some developers more than others, depending on the application type. I think developers building and working with reusable and extensible Web frameworks containing lots of generic code will quickly reach the limitations of the new project model.
Compilation in ASP.NET 2.0 works by running the new ASPNET_COMPILER.EXE utility against a Web application. The compiler offers many project compile options, including in-place compilation, which requires source code distribution; pre-compiled compilation into all binary code; and partial compilation, which compiles your user code, but lets you distribute and modify the ASPX markup pages. There are at least 16 different compilation and pre-compilation combinationsand none of them are likely to be exactly what you want; most combinations produce non-repeatable installs and none of the stock combinations create a single deployable assembly that most developers would expect from a pre-compiled application.
The only simple deployment method is in-place deploymentyou simply copy your entire development environment, including source code, to the server. All the other options require that you delete files on the server and then recopy newly compiled files, which disrupts application uptime on the server and requires a fairly strict deployment regimen to work reliably.
To address some of the shortcomings with compilation, Microsoft released the Web Deployment Projects (WDP) add-in, which provides a mechanism to post-process the output from the ASPNET_COMPILER.EXE and create a single assembly.