ASP 101 - Active Server Pages 101 - Web01
The Place ASP Developers Go!

Windows Technology Windows Technology
15 Seconds
ASP 101
ASP Wire
VB Forums
VB Wire
internet.commerce internet.commerce
Partners & Affiliates
ASP 101 is an site
ASP 101 is an site
Internet News
Small Business
Personal Technology

Corporate Info
Tech Jobs
E-mail Offers

ASP 101 News Flash ASP 101 News Flash

 Top ASP 101 Stories Top ASP 101 Stories
VBScript Classes: Part 1 of N
Migrating to ASP.NET
Getting Scripts to Run on a Schedule

Don't use ODBC for your database connections
Show All Tips >>
ASP 101 RSS Feed ASP 101 Updates

ASP+ versus ASP

ASP+ versus ASP

by Chris Payne


We've all heard about ASP+ now, Microsoft's next generation of Active Server Pages. ASP+ is a complete rework of ASP from the ground up. This isn't just an incremental release. (For a more complete description, check out this ASP 101 article.) ASP+ is part of Microsoft's evolving new architecture, .NET, which promises some very interesting new technologies that will make life easier for everyone. With all this hype around the new technology though, there hasn't been much talk about what we might be losing.


First, let's talk briefly about some of the benefits that we gain from ASP+, before we lambaste them.

  • Compatibility

    Microsoft has designed ASP+ to run along side regular ASP, so there's no need to worry that your existing applications will break with the next release of Internet Information Services (IIS). ASP+ files comes with a new extension (aspx), so you can easily separate the old from the new.

  • Compiled Code

    ASP+ has the benefit of access to compiled languages, such as Visual Basic, C++, and even MS's new C#. You can now program Active Server Pages in any language you wish, as all code is now compiled when requested. Even VBScript and Javascript are now compiled.

  • COM Objects

    We are all aware of the problems with COM when using typical ASP. Registering components, restarting servers, blech, what a pain. Well, now with the Next Generation Windows Services (NGWS), you don't have to worry about this anymore. You can simply copy the source files for your component, paste them wherever you want, and it will work. No DLL registering, no headaches.

  • XML Configuration

    With the NGWS framework, all metabase and configuration information is stored in XML files. This means you no longer have to fool around with IIS to change the settings. In fact, you could change the XML file from anywhere, and ftp the changes to the server. No need for any type of remote PC control.

  • Web Forms and Web Controls

    ASP+ introduces the ability for forms to be linked to the server, so you can process requests more easily. Web controls offer similar functionality, and provide a web developer with additional functionality versus the regular HTML controls.

  • Caching

    ASP+ allows objects and output to be cached, which should increase speed, since subsequent users won't have to make more requests to the server. The ASP+ caching system is very advanced, allowing you to specify what needs to be cached and what doesn't, and when to recall the cached information versus performing a new request.

  • Scalability

    ASP+ has some great scalability features built into it, including maintaining session state across servers, and multi-processor balancing. The ASP+ runtime also monitors processes, so when one goes haywire, ASP+ will shut it down and restart it for you, and send old requests to the new process.

ASP+ provides a slew of new features, and improves on some existing ones. While some of these initiatives sound great, they are not without problems. Without further ado, let's get into the drawbacks.

Managed Files

The entire .NET architecture is based around the NGWS runtime, which does away with the COM that we are used to, and replaces it with a common language runtime - essentially the same as the Java Virtual Machine (now we know why Microsoft has dropped support of This runtime basically intercepts any type of code, and translates it to a common machine language for the system to use. It's this runtime that also handles ASP+ page compilation.

Note: If you are not familiar with Java, essentially what happens is that a program resides on your computer that 'interprets' Java code into machine language. Then, when moving to a different platform, you only have to redo the program, instead of the entire programming language. This is how Java ensures cross-platform compatibility. You can see how this is similar to .NET, except instead of cross-platform, it's cross-language.

This system also keeps tabs on the source files for your application. If it detects they have been modified, the runtime will recompile it for you, thus serving up the latest version to your users.

We can definitely see how that would be of a benefit to ASP applications. After all, compiled languages, with their machine code and strongly typed variables are much faster than scripting languages, which must be interpreted before executed.

We can't help but wonder, however, how much overhead the new runtime introduces. Microsoft has assured us that the performance gain from the compiled ASP pages would outweigh the loss from the overhead of the runtime system, but this doesn't sound like a solution, but rather a change of the problem. The Java Virtual Machine, for example, slows Java applications down tremendously. Let's hope we don't see any major problems in this area.

Also, as a minor note, compiling an application also takes time, so the first user on your system will notice a definite delay. And if you change your application often (as most ASP writers do), your users will see much more of a performance decrease.

Web Controls

Web controls promise to make life easier when building forms and other HTML controls. For example, with a typical select box in ASP, you would have to build a loop to populate the control. With ASP+, you can have the control "data-bound" which means it will be tied to a data source, and will populate itself automatically.

This sounds like a huge bonus, but let's examine it more closely. With traditional ASP and ADO, you could choose where to place database cursors (server side or client side), among other things, depending on the type of performance and function you are trying to build. With ASP+, you no longer have a choice. Because of the link between the web controls and the server, you are forced to keep everything on the client side. This can be a performance drain for both the client, because it must now store all the data in local memory, and the web server, because of resync-ing of data. Also, with linked controls, there is likely to be a small performance hit as more data has to travel over the network connection.

Web controls also introduce new syntax, in the style of strict XML nomenclature. Thus, you can no longer have sloppy coding, you must close all tags, use namespaces, etc. While this may be a benefit to some (stricter coding usually means less errors), to most it will be a pain to adapt to.

Another small drawback about web forms - you must use the POST method of your forms to take advantage of web form's most valuable feature: state management. When you use the GET method, all best are off, and you lose the functionality. Quite an ugly restriction there.

<asp:TextBox id="textBox1" runat="server" Text="[Entry Keywords]"></asp:TextBox>


<input type="Text" value="[Entry Keywords]" id="textBox1">

Out of Control Code

We can definitely appreciate the fact that COM objects no longer have to be registered on the server. With this simplification, however, we can potentially open up a can of worms. One reason (as much as we hate it) for the nightmares behind DLL hell is that it enforces version security. You can't run more than one version of a DLL on your server, and the code is fairly secure - it is difficult to change without the proper development tools and source code.

The safety mechanism, however, is now dealt away with. You can have as many versions of a DLL running on your server as you want, which can lead to all sorts of new headaches and security nightmares.

Another large benefit that most developers love about COM objects is that you can encase your business logic so that no one but the developer will see it - the object is compiled, so your clients can't take a look at the magic behind the scenes. With the new framework, you should distribute the source files with the application, because NGWS must keep track of them. The end users can then view or modify the code at will. Of course, you could compile the object and not give the out source files, but then, you're losing the benefits provided by NGWS.

You'll also have to keep tighter wraps on who accesses your files, probably by using some outside form of source control (i.e. Visual Source Safe). Any user can walk in and modify your objects fairly easily, and I'll let your imagination run wild about hackers.

The same problems apply to the XML based configuration system. All the easier to hack you with my dear.


You can be sure, as with any new technology, it will take a while for ASP+ to penetrate the market. Microsoft is just starting to get ASP and the IIS platform recognized in the industry as a viable alternative to other web servers out there. With such a drastic change in their fundamental structure, however, it will be difficult to find clients or developers who are willing to abandon the old ways and move on. Time will, of course, heal this wound, but ASP+ faces a hurdle to gain acceptance, and with that slow adoption, comes also difficulty in finding quality solutions and support.

Not to mention the fact that ASP+ is still an alpha technology as of this writing, so good luck in finding support.


As you have read throughout this article, ASP+ has a few issues with doing things that ASP would handle normally. There are a lot of caveats to using ASP+, and you must do things a certain way if you wish to receive any benefits, which restricts your application greatly. On one hand, Microsoft has tried to let the developer do less manual coding, but has sacrificed flexibility for it.

Consequently, ASP+ is more difficult to manage and write, rather than easier, as its framers would have it. There are many "little things" that must be taken into account, and it is easy to see how beginners, and even ASP pros, will spend hours scratching their heads wondering why something so simple doesn't work.

In the end, it may become apparent that ASP and ASP+ must be used side by side for next generation web applications. ASP+ offers some great new features, though with hefty costs, and ASP will (hopefully) still be around to balance those costs and offer functionality that ASP+ cannot.

Existing Code

And of course, we couldn't close without mentioning that by switching to ASP+, and to receive all the above benefits, you will have to rewrite all of your existing code. Your old code will still work within IIS, but you'll be stuck using the traditional ASP framework (not necessarily a bad thing). It may be a pain though, to move a large web application over to ASP+, especially if you've developed a lot of custom solutions or COM objects.


It is often difficult when a new technology comes into the world. Usually, however, you hear both the good and bad about a new technology. ASP+ is not the end-of-all web application frameworks (though many will tell you otherwise), but it is a welcome step forward in the right direction. The benefits will most likely outweigh all the problems, but it is helpful to look at ASP+, and any new technology, with a grain of salt.

For more great info on ASP+, check out the following links:

Home |  News |  Samples |  Articles |  Lessons |  Resources |  Forum |  Links |  Search |  Feedback
The Network for Technology Professionals



Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers