The History of ASP.NET – Part I

The first version of ASP.NET was released 17 years ago in early 2002 as part of the version 1.0 of the .NET Framework. It was initially designed to provide a better web platform than classic ASP and ActiveX, one that would feel familiar to existing Windows developers.

As we look back to its early design and years, it might be surprising to see how concepts like MVC, Web Services, JSON or JavaScript types were considered, discussed and/or introduced into ASP.NET earlier than you might remember.

This is the first part of a series of 3 articles that will cover the history of ASP.NET from its launch to the latest ASP.NET Core releases.

Update: Part II has been published. The History of ASP.NET – Part II (ASP.NET MVC).

Update: Part III has been published. The History of ASP.NET – Part III (ASP.NET Core).

I hope you will enjoy the look back in time as much as I enjoyed writing about it!

The ASP.NET Web Forms era (2002-2008)

Microsoft released ASP.NET to the world as part of the 1.0 release of the .NET framework during January 2002. XML was king, and the future was based around XML web services.

As Rob Howard, Program Manager for ASP.NET at that time wrote:

In the last several months, the industry has awakened to the promise of Web Services. Did I mention that XML Web Services represents the underpinning of Microsoft's .NET strategy, and is a core feature of ASP.NET?

In the era of XML, Microsoft wasn’t shy to push forward with IE in areas like XML data islands or the XMLHTTP ActiveX control. Few anticipated that other browsers would implement the latter as the standard XMLHttpRequest API and that it will form the basis for what would be known as Asynchronous JavaScript and XML, or AJAX. Of course, browser standards were only a dream and techniques like JavaScript forking for multi-browser support were commonly promoted.

These were also the years when DHTML was promoted as the next big thing (before becoming obsolete by standardized DOM, JavaScript and CSS). Enterprise developers who were used to create desktop applications were increasingly moving towards web applications, often deployed on corporate intranets.

It was then that Microsoft released the .NET framework 1.0 alongside Visual Studio.NET, with ASP.NET Web Forms being a core part of the package. This gave developers of the Microsoft platform a much better way of building web applications than the previous mixture of classic ASP, ActiveX controls and VB6 DLLs.

The design of Web Forms

The turn of the millennium saw Microsoft with a few significant fronts opened:

• It had failed in its embrace, extend and extinguish strategy against Java (which ended settling in a lawsuit), and it had now embarked on providing its own managed language alternative that could compete with Java
• It needed a better solution for building and hosting web applications in Windows, so it could keep competing in the context of the dot.com bubble.
• Its RAD (Rapid Application Development) platform, the aging Visual Basic 6, needed a replacement. A lot of buzz was being generated around visual tools and designers for developers as the new silver bullet for developer productivity!

To overcome these challenges, Microsoft finally came up with its own managed and interpreted platform, the .NET Framework, and the languages C# and VB.NET (simply known as Visual Basic today). The 1.0 release of the framework came with specific tools for desktop and web development, named Win Forms and ASP.NET Web Forms. As we will see, the similarity in the name of their desktop and web frameworks wasn’t a coincidence!

Win Forms was designed to be the successor to VB6 for developing Windows desktop applications, providing a RAD experience around a forms designer in Visual Studio that would be familiar to VB6 developers. ASP.NET Web Forms would then provide a very similar experience for developing web applications, with a similar forms designer in Visual Studio and a programming model that would truly resonate with their existing desktop developers. Its name also suggested this new framework was the successor to the classic ASP scripting framework.

Figure 1, The Web Forms designer in Visual Studio 2003

This was magical at the time and made the transition to the web smoother for developers used to Windows applications. Or at least on paper, because this was only possible through some clever abstractions around which the Web Forms framework was built, abstractions that would hide the reality of the web and would end up causing the shift to MVC!

Web Forms was designed following the Page Controller pattern, which is one of the classic web presentation patterns. Each page in the application is created as a Web Form and associated with an .aspx URL. The page is loaded through a GET request and sent to the browser. Controls within the page such as buttons would cause a POST to the same URL, which is handled by the same Web Forms page (or page controller).

Each Web Form had two distinct parts. The aspx template that ultimately defined the HTML of the page, and the class that implemented the Page Controller and provided the necessary logic. This would be the HelloWorld.aspx template:

<%@ Page language="c#" Codebehind="HelloWorld.aspx.cs" AutoEventWireup="false" Inherits="HelloWorldPage" %>
<HTML>
   <body>
      <form id="Form1" >
         Name:<asp:textbox id="name"  />
         <p />
         <asp:button id="MyButton" text="Click Here" OnClick="SubmitBtn_Click"  />
         <p />
         <span id="mySpan" ></span>
      </form>
   </body>
</HTML>

Notice that although the view engine used in aspx files allowed for code to be mixed inside <% %> blocks, this was frowned upon. The ASP.NET community had just moved away from classic ASP and its spaghetti code issues!

..and its corresponding code-behind HelloWorld.aspx.cs file:

using System;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.HtmlControls;

public class HelloWorldPage: System.Web.UI.Page
{
   protected System.Web.UI.WebControls.TextBox name;
   protected System.Web.UI.WebControls.Button MyButton;
   protected System.Web.UI.HtmlControls.HtmlGenericControl mySpan;

   public void SubmitBtn_Click(Object sender, EventArgs e) 
   {
      mySpan.InnerHtml = "Hello, " + name.Text + "."; 
   }
}

The ASP.NET framework provided a set of controls that could be used on each page.

The asp:textbox and asp:button tags are examples of Server Controls, which are not standard HTML tags. The final HTML and JavaScript sent to the client is generated by the framework when rendering the page and depends on both its properties and potentially, the client. Each of them gets a variable added to the code-behind class.

There are also HTML Server Controls, which are directly related with HTML elements and whose intention is for the code-behind class to have access to them. There is one in the earlier example, the span mySpan, with its corresponding variable of the code-behind class.

The asp:button in the example shows another interesting characteristic. Server Controls can render the necessary HTML and JavaScript to process an event on the server through PostBack requests, which is nothing else than a POST request to the same page, alongside its current state and the name of the control and event that was triggered. A method in the code-behind class can be associated with each of these events, so it can be executed on the server during the handling of the PostBack request. The click event of MyButton associated with the SubmitBtn_Click method is an example of this.

As you can see, each page contained a single HTML form, which would cause the browser to submit it as a POST request to the same URL. The server would then instantiate the same page controller class, which can then react to the post back.

This model would be immediately familiar to developers used to working with desktop applications where the view and page controller run as part of the same process. However, it hid from them the fact that client and server were separated over a network, one stateless by nature.

The trick was possible by combining:

• Its state management, which combined different alternatives for keeping data. Apart from the usual Application and Session State, ASP.NET introduced the View State. Before the page HTML is sent to the browser, the server encoded the state of the page controls into a Base64 encoded string which was included as a hidden form field. This hidden field would then be automatically included by browsers in POST requests.
• A page lifecycle with events that would be automatically invoked by the framework at different points during the processing of the request. These would allow the page state to be initialized from scratch (as in fetching from the database) or rehydrated from the posted View State (as in properties of form controls)

The following diagram shows this flow in action:

Figure 2, Flow of a typical page in ASP.NET 1.0

As you can see in Figure 2, the framework is designed assuming most of the work would be done by the server, with the client mostly rendering the HTML documents and issuing new GET/POST requests. This was a sign of the times, since clients were not as powerful, nor browsers as advanced as they are today.

Overall, ASP.NET succeeded in its objectives of providing a model closer to desktop development and a RAD platform for web development. However, its stateful model over a stateless network combined with an abstraction that hid the web from developers, ended up hurting the framework in the long term.

Of course, the years elapsed since the ASP.NET launch gave us an insight people didn’t have back then and it is easy to criticize or mock something done 17 years ago.

However, you would be surprised by what was possible to achieve in ASP.NET!

I found it particularly interesting reading through the patterns provided by Microsoft’s Patterns and Practices team back in in June 2003, all of them implemented in ASP.NET:

• They provided an implementation of the MVC pattern, years before the first release of ASP.NET MVC
• The implementation for the Front Controller pattern is nothing but an early attempt at what would become the routing component of ASP.NET MVC
• The intercepting filter pattern provides similar functionality to the Filters in ASP.NET MVC or even the Middleware in ASP.NET Core.

It is true that most developers never followed these patterns. And yes, guidance mainly focused on the RAD aspects and the ease of building applications by dragging and dropping controls on the designer and writing event handlers in the code-behind.

But it is also true that developers could build clean applications with a little more effort, as we have seen with those patterns!

Before we move on, let’s consider what else was going on around that time in the web development world.

• The main external competitor to ASP.NET were Java frameworks like Struts and later, Spring. It seems Microsoft recognized them as such and their early documentation has content aimed for people familiar with Struts and J2EE web technologies in general, as per the JSP (JavaServer pages) migration articles.
• As mentioned earlier, XML in general and XML-based Web Services were a huge deal back then. ASP.NET had a web services offering over HTTP and the .NET framework came with a more general purpose .NET Remoting, the predecessor to WCF. Web Services interaction between different platforms like .NET and Java was a big deal.
• Microsoft still had a large base of VB6, ActiveX and classic ASP programmers around that had to move into their new .NET platform. As you can imagine, abundant materials were produced to help with the transition, like this series of articles collected in their official docs.

It is fair to say that the introduction of ASP.NET was a huge success for Microsoft. It became one of the dominant web development platforms and saw huge adoption in the enterprise world.

ASP.NET Web Forms gets perfected

Even though it was a success, the .NET framework was still in its infancy and in much need of maturing and refining. Microsoft adopted a schedule that released major new framework versions every two years, with all the pieces including ASP.NET upgraded at the same time.

In 2003, the .NET Framework 1.1 was released and ASP.NET received the Mobile Controls amongst other minor updates. It was with the release in 2005 of the .NET Framework 2.0 that the framework took a big step forward and came of age.

At that moment, .NET received some of its most useful and widely adopted features. It is amazing looking back and imagining yourself writing .NET code without generics or nullable value types. Let’s briefly revisit some of these features:

• The introduction of generic types made it possible to adopt patterns that increased reusability and type safety, like the generic collections. Before generics, it was relatively common for runtime casts to cause exceptions and to incur a performance penalty due to boxing/unboxing of value types. Microsoft themselves would add generic methods and types across many areas of the framework.
• Nullable types were also introduced, so it was now possible to assign null to value types when using the Nullable<T> structure (another example of a generic type)
• C# received support for static classes. That’s right, C# didn’t have static classes in its first release!
• Partial classes were now possible in both C# and VB.NET. This would greatly help Win Forms and Web Forms to separate the designer code generated by Visual Studio from the actual code-behind written by the user.
• A new model for managing transactions that was able to transparently enlist transactions in existing ambient transactions and promote between the local transaction manager and the Microsoft Distributed Transaction Coordinator (MSDTC). This greatly benefitted many using ADO.NET for data access and/or integrating with existing COM+ components.

The importance of the 2.0 release is even more obvious when looking specifically at ASP.NET 2.0. Apart from benefitting from new .NET features such as generics, ASP.NET really received a major overhaul and became a more powerful and easy-to-work-with framework.

A long list of new server controls was included in this release. In fact, controls became one of the preferred ways to expand ASP.NET in the community, and started an industry of 3^rd party control vendors.

But including more controls wasn’t everything.

There were many other additions and improvements to the framework that changed the development experience:

• The View State was improved and reduced in size, one of the criticisms towards ASP.NET. The concept of “Control State” was introduced to separate the absolute minimum data required for a control to function (which cannot be disabled) from the rest of the View State.
• Achieving a consistent look and feel was easier after the introduction of Master Pages, a concept close to the layouts seen in ASP.NET MVC and ASP.NET Core. The styling of the entire website could be centralized through themes and skins, where a theme is made by a number of CSS and skin files, and a skin is an XML take on CSS that could set properties for ASP.NET Server Controls as well.
• It was now possible to create a Site Map, an xml file describing the location and names of pages in your website. This file could then be directly used with new Server Controls added for navigation purposes, able to render breadcrumbs, menus or tree menus from the Site Map.
• The page lifecycle was updated with new events.
• Cross-page postbacks were now allowed. That is, a page could now send a POST to a different page and not just to itself.
• The caching features were significantly improved. New dependencies based on SQL server were introduced, developers could now write their own cache dependency implementations and dynamic parts were allowed in cached pages.
• Web Parts allowed users to personalize websites, an idea like the iGoogle or My Yahoo! portals of the time. Server Controls could be used as Web Parts (and custom ones could be created), which users could add, remove and customize from their portal-like page.
• Finally, the factory design pattern was combined with generics in order to create the so-called Providers. This is nothing but a contract that decoupled ASP.NET features like Membership or Profiles from the actual source of the underlying data. The framework already contained providers for typical sources like SQL Server or XML, while developers could create their own. These could then be wired to their features as part of the providers configuration section.

I am sure that even with a brief summary like the one above, you would agree with me that ASP.NET 2.0 overall was a significant step forward.

However, you might have noticed that there was almost nothing new for the client side. Most of the new features were still geared towards the server, with the browser mostly dedicated to render the pages generated on the server.

This was about to change, and it would happen fast!

The importance of JavaScript and AJAX

Web 2.0 introduced the need for more dynamic websites that increasingly needed to take advantage of client-side scripting. This trend continued through the first half of the decade and entered an exponential growth when these features became a common and expected feature of modern websites, particularly after its adoption in Google products. The term AJAX (Asynchronous JavaScript and XML) coined in early 2005 quickly became a buzzword mentioned everywhere and the next big thing in web development.

Prior to ASP.NET 2.0, the term AJAX hadn’t been coined nor adopted, but the XMLHttpRequest API it relies upon had been available in browsers for some years. In fact, nothing really stopped an ASP.NET developer from creating server side endpoints that could then be called from JavaScript, as described in articles such as this one which introduced the pattern to ASP.NET developers.

ASP.NET 2.0 recognized the growing importance of JavaScript interaction with XMLHttpRequest(still not commonly identified as AJAX) and introduced a feature called script callbacks. This allowed a server-side method to be called from JavaScript through an XMLHttpRequest. This release also introduced the ClientScriptManager, an early attempt at managing and bundling the JavaScript code needed on each page!

Around the time ASP.NET 2.0 was about to be released, the AJAX craze had already started. Microsoft had already taken notice and announced that they were working on a project codenamed Atlas which will bring first class AJAX support to ASP.NET.

Atlas was finally released as Microsoft AJAX 1.0 during January 2007. Apart from bringing AJAX to the forefront of ASP.NET, this release marked two interesting firsts for ASP.NET:

• It was released separately from the .NET Framework, as a standalone installer that added Microsoft AJAX to ASP.NET 2.0. Before it, developers had to wait for the 2-year release cycle of the .NET Framework in order to get new features.
• The source code of the new controls part of the AJAX Control Toolkit was open sourced and available in CodePlex. The client-side JavaScript code was released under the MS-PL (Microsoft Public License) which was similar to the MIT license. The server-side code used the more restrictive MS-RsL (Microsoft Reference Source License) instead, with the aim to facilitate development and debugging.

Microsoft AJAX focus wasn’t limited to AJAX requests, instead it focused on all the client-side aspects needed for the modern dynamic websites of the time:

• The controls included in the Controls Toolkit, such as date pickers, accordions or dropdowns, contained rich client-side functionality. The inclusion of control extenders of regular ASP.NET controls made it easy to add some of the new functionality into existing Server Controls.
• Server-side controls like the UpdatePanel simplified the task of partially updating parts of the page without the need for any JavaScript code to be written.
• An entire type system for JavaScript was introduced, which allowed developers to write JavaScript code using types. As we all know, this idea would be later implemented again and perfected with the release of TypeScript. Seeing the early attempt, it is interesting nonetheless, and I wonder what lessons were learned that were later used during the TypeScript development (if any).
• Both ASMX and WCF web services could be exposed to client-side scripting using the new ServiceReference object, which automatically generated a JavaScript proxy to call the service.

While the work on Microsoft AJAX neared its initial release,.NET Framework 3.0 released in November of 2006. The sole purpose of this release was to introduce the trio of XML-based frameworks WCF (Windows Communication Foundation), WPF (Windows Presentation Foundation) and WF (Windows Workflow Foundation).

It wasn’t until a year later when .NET Framework 3.5 was released in November of 2007, that ASP.NET received new features. The most significant one was the fact that Microsoft AJAX was now part of the framework. Another major feature was the inclusion of the ListView control, which allowed to easily build CRUD-like functionality for any data source through the customization of different templates.

We also shouldn’t forget that .NET 3.5 introduced LINQ (Language Integrated Query) to the delight of many, including ASP.NET developers, who even got a specific LinqDataSource control.

Conclusion

It was the end of the year 2007 and we had a mature .NET framework after 3 major revisions, which included a very capable ASP.NET framework. However, the cracks were starting to show. The abstraction provided by ASP.NET did a reasonable job at providing client-side functionality without the need for deep understanding of HTML, HTTP and JavaScript, but the same abstraction leaked and got in the way when things didn’t work, or custom functionality was needed.

The focus on server-side controls and declarative programming through bindings, hid even more the realities of the web from developers. When developers tried to keep up with the increasing expectations for web applications they could find themselves working around the framework rather than in the way the framework intended.

At the same time, things were beginning to change for both developers and web users. Ruby on Rails had been released in 2004 and had a huge impact on the web development world. Its approach was considerably different from ASP.NET, providing a lightweight MVC framework that accepted the strengths and limitations of the web and explicitly tried not to get in the developer’s way. In comparison, it made ASP.NET look old and heavy, criticized by those seeking a better way of developing web applications and often cited as the counter-example.

However, the biggest change would be caused by the first iPhone. Introduced during the summer of 2007, the web won’t be the same once the number of users with mobile devices exploded!

Stay tuned for part II of the article series to read how ASP.NET reacted about these and other challenges.

Update: Part II has been published. The History of ASP.NET – Part II (ASP.NET MVC).

Update: Part III has been published. The History of ASP.NET – Part III (ASP.NET Core).

This article was technically reviewed by Damir Arh.

This article has been editorially reviewed by Suprotim Agarwal.

C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.

We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).

Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.

Click here to Explore the Table of Contents or Download Sample Chapters!

Author

Daniel Jimenez Garciais a passionate software developer with 10+ years of experience who likes to share his knowledge and has been publishing articles since 2016. He started his career as a Microsoft developer focused mainly on .NET, C# and SQL Server. In the latter half of his career he worked on a broader set of technologies and platforms with a special interest for .NET Core, Node.js, Vue, Python, Docker and Kubernetes. You can check out his repos.