When Microsoft released its .NET V1.0 framework along with ASP.NET in January 2002, a lot of developers and chief information officers were left trying to understand just what .NET truly was. In retrospect, the view is widely held by industry pundits that the initial marketing effort that accompanied .NET, a scheme to deliver software as a set of services over the Internet, was scattershot, poorly focused and in many respects a disaster.

Contrast the early marketing of .NET with Apple’s largely brilliant push for its OS X and the iPod. Of course, Steve Jobs has always been a marketer at heart, and understood the idea of taking what was complex and breaking down the benefits into easily digestible catch phrases.

.NET, on the other hand, seemed to be more of a “concept,” with which Microsoft started to brand just about everything. I remember remarking to a friend during those first server product launches that it was a good thing Microsoft didn’t own Procter-Silex, or I could have likely wandered into Target and spotted a “Dual-Slice Toaster.NET.”

The unfortunate part in all that mess is that at the same time, Microsoft completely revamped its entire Active Server Pages development environment. The changes were truly revolutionary, and deserving of the name change, since the new release changed the entire way ASP functioned.

What’s new?

Having just dipped my toe into the .NET world myself, using the MX releases of Macromedia/Adobe Dreamweaver as a visual development environment, and combining that with some custom code examples, it’s worth looking at what makes ASP.NET so different from the past versions of ASP.

*Language independence: Unlike ASP, which was restricted to VBScript and JScript, ASP.NET can use a wide variety of languages. The most popular choices seem to be VB.NET and C#. The actual language used is largely immaterial to ultimate performance, since all of them are automatically compiled to the Microsoft Intermediate Language (MSIL) anyway. This leads toÉ

*Auto compilation and caching: ASP code, in its past versions, was truly a scripting language. Every time a Web server works its way through a page containing raw ASP, each block of code is processed every time the page is viewed in a Web browser. With low to medium loads or simpler applications, often a fast server will perform adequately but may not scale as desired. ASP.NET changes all that. An ASP.NET page is fully compiled the first time a user accesses it, and that compiled page is cached in memory, so that anyone using the page after that gets lightning-quick performance. If the raw page is changed, however, then re-compilation and caching happens automatically. There is another benefit to this: code errors are usually caught in the compilation process and can be troubleshot earlier in the development cycle.

*Code separation: With previous ASP, code often had to be placed at specific points in a Web page where the desired functionality was needed. With ASP.NET, all server code can be placed anywhere in the page, or in a separate file altogether. This can make troubleshooting a heck of a lot easier, as discrete code grouping means the developer may not have to hunt and peck through code block after code block to find a particular chunk if it’s all in one place. Not often mentioned is the drawback to this: With ASP and visual design tools, you could often park your cursor at a spot in the page and then reference the code that makes something happen, which is a good teaching tool. With code separation in ASP.NET, that may not always be true. A lot of example and production code I’ve seen remains split up, suggesting that some developers may be sticking with tried-and-true methods, even with the new ASP.NET. That shouldn’t result in a performance hit, since the code is compiled anyway.

*Use of server controls: Default installations of the .NET framework include a pretty wide variety of user-inserted controls that perform functions that would have been relegated to “registered components” in previous versions of ASP. This includes functions like uploading files, displaying database data result sets in grids, and form designers. Many of these appear to have been the result of Microsoft engineers reviewing the “most used” external components in ASP, then including them by in the standard ASP.NET kit. A great side effect is that visual development environments like Dreamweaver and VB.NET are able to take full advantage of these controls in their user interfaces, making common programming needs quick and easy to drop into a page. Documentation on these controls is extensive and complete on the Microsoft .NET Web site, as well.

*Memory leak protection: Similar to the way that Microsoft’s IIS 6.0 can automatically recycle worker processes to prevent a leaky application from stealing memory over time, ASP.NET will also start up a new instance of the main worker process, direct all new requests to that new process, and then drop the old one once all of those requests are processed. Thus, the old leaked memory is released without interrupting the users on the older, leaking process. Combining .NET applications with IIS 6.0 thus provides two levels of protection against persistent memory leaks.

*Easier deployment: Application pages are simply uploaded to an ASP.NET-enabled server. Component registration is now a thing of the past, and configuration files are stored as XML in a file within the application. Significantly, the XML format allows human as well as machine reading of that configuration file, leading to easier modifications.

*New method of database connection: Before, developers were so familiar with ADO (ActiveX Data Objects) connections, they could probably write them in their sleep. Interestingly, even though Microsoft has continued the naming convention and now calls it ADO.NET, ADO.NET has absolutely nothing to do with ActiveX and likely used the moniker simply to assure some familiarity. The biggest benefit to developers will probably be noticed in the error reporting. ADO.NET errors are treated like any other .NET error and are not “private,” like they were with ADO, meaning they had to be debugged separately, adding another layer of complexity. Now, data access errors can be captured along with other page errors by using the ASP.NET subroutine ‘Page_Error()’.

A broader picture

Although .NET has been around for four years, the question still remains whether the strategy will remain only in the sphere of Microsoft products or whether it’ll be used more as an open interface to other applications. Even if it does remain somewhat closed, at least some elements in the strategy, such as ASP.NET, have been significantly improved and be can be used to great advantage regardless of whether or not Microsoft’s wider strategy works effectively.