Not because Nick says so!

published: Mon, 19-Jul-2004   |   updated: Sun, 23-Jul-2006

In my last blog I said that I'd comment on articles in Delphi Informant, especially with regard to technical veracity (I have enough problems writing my own prose to comment on others'; an editor I am not). Well, the new issue of DI is out (at least, I can access the new content online), and I have a couple of comments on Nick Hodges' first article.

Nick is starting a column on ASP.NET, especially with regard to Delphi 8. This is, in and of itself, something very interesting to me, especially since I've only "done" ASP.NET with C#.

Now when I first started out with ASP.NET, for some reason I had the utmost difficulty in understanding what was going on; the "View from 10,000 Feet" to quote the headline from Nick's article. It was especially tricky since I'd never done any "old-style" ASP programming, and had only the vaguest idea about it all. Then I met with someone at Microsoft when I was there and he explained it to me as to a 10 year old and the penny finally dropped.

Now, this first article of Nick's is an introduction to ASP.NET, albeit with a Delphi flavor. It's laying the groundwork for what's to come; it's the high-level overview for those who've not seen or used ASP.NET before. As such, it has to gloss over an awful lot, I agree, but the article should at least mention the big strength of ASP.NET: it's not a scripting engine, the code that produces the pages you see is compiled not interpreted. Bear this in mind, because the article ignores this benefit completely. (And, note, I am not just talking about the code-behind files here.)

Although most of the article is well-written and is spot-on technically, especially given (or maybe in spite of) its high level treatment, there is one paragraph with which I have the most difficulty to accept, and I quote:

Aspnet_isapi.dll is really just a scripting engine that hosts the .NET Framework, and knows how to take aspx pages and use the page's associated DLL to render HTML pages for IIS. Cool, eh? I bet most people didn't know that their ASP.NET application was really just another Win32 scripting language as far as IIS is concerned.

I don't know where to begin with this paragraph. Let's take a stab and comment.

Aspnet_isapi.dll is really just a scripting engine. Er. no, I'm afraid it isn't. This is how ASP.NET works, in layman's terms. The first request for an aspx page comes in. IIS (if that's what you're using, of course) passes the request on to aspnet_isapi.dll, because that's how IIS is set up by the .NET Framework. This dll then parses the aspx file requested, generates C# (or Delphi, or VB, or whatever) code and a string resource from it, and calls the C# (or ...) compiler to create an assembly for that page. The code it generates is basically a bunch of calls to build up the HTML that the web browser will render. Once the page has been parsed and compiled into an assembly, the aspx page is no longer used.

This is why the first call to an aspx page takes the longest: the page has to be parsed, the code that creates it has to be generated, the compiler has to compile the code, and finally the assembly has to be run. Subsequent calls to the same page just cause the compiled assembly to be run and are much faster, and indeed quicker than any interpreted scripting language.

If you have any embedded "run at server" code in your aspx page, it will get inserted at the proper place in the generated C# (or ...) code and get compiled along with all the generated code. (This is different than the older ASP technology: here the page requested is parsed and any embedded "run at server" script is interpreted by the server every time.)

[...] that hosts the .NET Framework. Nope, sorry. In Windows XP, aspnet_isapi.dll starts a worker process called aspnet_wp.exe that hosts the .NET Framework and loads the pre-compiled application dll and the just-compiled page dll into a new application domain. In Windows 2003, using IIS 6.0, it's slightly different.

[...] knows how to take aspx pages and use the page's associated DLL to render HTML pages for IIS. Nope, again; the HTML you get back is always generated by normal, compiled .NET code.

[...] their ASP.NET application was really just another Win32 scripting language [...]. No, it isn't. I don't even know what a "Win32 scripting language" means. The biggest client-side scripting language, JScript, is operating system agnostic (which is why web pages using it work on IE as well as Mozilla and Safari, etc). PHP, the best known server-side scripting language, is also operating system agnostic.

Now, admittedly, there is a whole lot more to the entire process than this, of course, (and I dare say that I will, in turn, be berated for getting something wrong) but for me, the biggest insight that helped me understand what was going on in ASP.NET was that aspx pages got compiled into a normal class (a descendant, via your code-behind file, of the System.Web.UI.Page class). Writing and designing aspx pages was just another way of writing a .NET class, one that gets compiled and called just like any other managed code dll.