In ASP.NET 1.x, though, only a few resources were really compiled-the most important and most frequently requested. The list of compiled resources includes Web pages (.aspx resources), ASP.NET Web services (.asmx resources), custom HTTP handlers (.ashx resources), the global application file (global.asax). What else is really worth a compilation?
Web pages, ASP.NET Web services, global.asax and custom HTTP handlers are written as a combination of source code and markup. That content is then parsed and dynamically transformed into a class; the class is then compiled to an assembly and loaded in the application domain.
A number of other auxiliary resources are involved with an ASP.NET application: helper classes, typed DataSets, Web service proxies, resources. In ASP.NET 1.x, all these resources require a compiled class to be fully integrated with the application. However, the developer is responsible for creating such a class with some help from system tools, so developers had to create satellite assemblies for resources, go through wsdl.exe for Web service proxies, and rely on xsd.exe for integrating typed DataSets. In the latter two cases, Visual Studio 2003 helped a lot with wizards, but in the end the compilation of such resources was manual and left to the developer.
The extensible compilation model in ASP.NET 2.0 automates all of these tasks and, in addition, gives developers a chance to integrate any type of data in any format into ASP.NET applications.
In ASP.NET 2.0 applications, any resource can be part of the application regardless of the extension. For example, you can have .xyz files in your Web project whose contents is a chunk of XML data. Normally, unknown file types are just copied to the production machine and consumed by pages in a way that is set in their code. In ASP.NET 2.0, you can create a component named the build provider to take files of a given type and generate a class to wrap the contents. In other words, you can create a component that parses the contents of the .xyz file and come up with a class that is automatically part of the application runtime.
The source code of this class never shows up in the Visual Studio 2005 project; instead it is created in the ASP.NET temporary folder where the source code for .aspx resources is saved. Yet, the class the .xyz resource represents is available to Visual Studio 2005, and it even shows up correctly through Intellisense. Let's go through this with an example.
In ASP.NET 1.x, you import a Web service by clicking on a Visual Studio 2003 menu item and then downloading the WSDL of the selected Web service. Visual Studio 2003 parses the WSDL on the fly and creates a proxy class. This class is named reference.cs or reference.vb and is part of the project. You could also run wsdl.exe offline, get a proxy class and incorporate that with the project. The bottom line is that the proxy class is part of the project; not the WSDL.
In ASP.NET 2.0, all that you have to do is incorporate the WSDL in the project. The same menu item in Visual Studio 2005 just lets you download the WSDL source file and copies it in a reserved folder of the Web application. The ASP.NET 2.0 runtime system, though, knows that .wsdl extension files are to be processed by a tailor-made build provider which will create--dynamically--the proxy class. This model is implemented throughout the whole ASP.NET 2.0 platform and involves a number of file extensions. But this makes good fodder for my next article.
