In 2002, Microsoft announced its .NET 2.0 platform. Since then, it is changing the programming world. Today, Microsoft .NET has become one of the most used mainstream platforms of software development. From this day to nowadays, most of it changed a lot, following the needs of the market, the availability of the customers, and now, with the help of the community too.

A quick look to the past

If you look at the image below, you can have a simplified view of how many Microsoft .NET Framework has evolved.

Evolution of .NET Framework

I am not from 1.x era, altough I had made some contact with classic ASP. Since then, I have been looking closely the evolution of the engine. With the release of the 2.0 version, my eyes widened with the features. Everything started with the CLR creation and the framework class library: building software for any architecture (altough still limited to Windows OS) and having a big amount of ready classes and tools to simplify everyday dev tasks was the big thing that made me choose this framework back then.

I was a Desktop developer in that time. Some years of experience with Delphi and freelance projects, the development market was starting to turn towards Web, and I was not happy with my developer toolkit for it. Microsoft had made me try the framework, inspired by the Web Forms feature: who would not be happy to develop web sites in the (almost) same way of Windows Forms? For my surprise, this was just a strategy made by Microsoft.

ASP.NET was made with the intention of attracting two types of developers:

  • Developers of the classic ASP, who were accustomed to develop data oriented, dynamic web applications, everything being made of HTML markup and server-side scripts. ASP gave them a good amount of abstractions in its runtime, like HTTP protocol, session state, WebServer utilities, cache, and so on. But even with that, traditional ASP applications began to show incredible difficulty to maintain from the moment they grew up considerably in codebase. That happened mostly because this code structure support was poor, with many duplicated code that happened most of the time thanks to markups being interlaced with server scripts. Those problems were addressed, and Microsoft tried to solve them by maintaining the good side of ASP and giving a solid Objected Oriented programming model.

  • Developers of Desktop applications, who, differently from the group above, where accustomed to a design-time experience, where what you see is a canvas where we drag and drop ready components from a rich set of interface controls. What more, there was also a code behind it, where the developer could define the behavior of the application as the user interacts with the interface drawn by them. The name "WebForms" did not came by coincidence: the same behavior was reproduced with the new feature, and that made me jump straight to it. I was one of those developers, trying to keep up with the tendencies.

The challenges with a historical model

The result was a rich and mature programming model. But this maturity and richness of resources began to bring new challenges as the developer community grew. One of the bigger ones was just the architecture of the Framework itself. System.Web.dll started to be known as a monolitic assembly, with many features toughly coupled with other objects form the namespace. It made things hard to do Unit Testing - wich was a growing culture among developers (TDD). Keep in pace with the rapid changes in the web development proved to be a hard challenge for the Framework team, because they had annual releases of it.

The first steps: ASP.NET MVC AND Web API

Outside of the Framework, apps were being developed by the use of reusable, small components, instead of swiss army knife frameworks like .NET one. The number of components, along with the frequency of the releases began to grow in a incredible pace. It was clear for Microsoft that, if they want to keep up with the market, they would have to to the same thing: the Framework started to be remodeled, in tiny steps, to become a series of pluggable components.

Also, another big change in the Web development was the solidification of Web patterns. Developers did not only want to have control of the server, but also of the markup being generated on the client-side. ASP.NET MVC was made then, trying to adapt to this tendency, and it did well. The Model-View-Controller pattern was already popular in the Ruby on Rails community, starting to be very popular in other platforms. This model not only helped with making Unit Tests of Web Applications more easy to develop, but also kept a good separation between key layeres of an application (data, business and interface).

Another big thing that changed was the growing pattern of rich javascript pages making calls to Web Services (API's) without refreshing page contents, giving a richer experience to the user. Keeping eyes open to that, Microsoft also made a great new product to help developers with it: Web API. And because Web API was a new product, Microsoft could make without classical System.Web.dll dependencies, and then, independently from IIS Web Server too.

The future: an open-source, agile based Framework

Uncoupling Framework components and distributing them as NuGet packages, Microsoft could begin a new era on the evolution process of the .NET, along with the opening of the source code of it: now they can release new versions in shorter intervals and be in touch with the community tendencies.

Every day, more and more companies and developers are joining the .NET Core community. We see C# being used to build AR/VR applications using Unity. Samsung releases Tizen for .NET that allows .NET developers to build apps for Samsung devices. Google joined .NET foundation and is being a part of .NET open source group.

New features are being made or joined into the ecossystem all the time. Cross platform came with the help of utilities like Mono. Xamarin is now a Microsoft product, being an incredible Framework to fast development of mobile applications. We see F# became a mature functional-first type language, starting to be a solid choice for building every kind of application.

All of it become a solid bet, not only because this is a proven success recipe by many open sourced companies, but thanks to Azure: it is now the Microsoft primary fountain of earnings, and for its sake, it's best for .NET to be an open-sourced tool. Taking advantage of the ideas and expertise of developers who embrace open source projects, Microsoft can have most of the help from them.