Getting started

Microsoft ASP.NET was released 15 years ago, in 2002, as part of the then shiny new .NET Framework. It inherited the name ASP (short for Active Server Pages) from its predecessor, with which it barely shared anything else, other than being a technology for developing dynamic server-side content for the internet, which ran on Windows platforms only.

ASP.NET gained tremendous popularity, it has to be said, and competed hand to hand with other popular web frameworks, such as Java Enterprise Edition (JEE) and PHP. In fact, it still does, with sites such as BuiltWith giving it a share of 21% (ASP.NET and ASP.NET MVC combined), way ahead of Java (https://trends.builtwith.com/framework). ASP.NET was not just for writing dynamic web pages. It could also be used for XML (SOAP) web services, which, in early 2000, were quite popular. It benefited from the .NET Framework and its big library of classes and reusable components, which made enterprise development almost seem easy!

Its first version, ASP.NET 1, introduced web forms, an attempt to bring to the web the event and component model of desktop-style applications, shielding users from some of the less friendly aspects of HTML, HTTP, and state maintenance. To a degree, it was highly successful; using Visual Studio,you could easily create a data-driven dynamic site in just a few minutes! A great deal of stuff could be accomplished merely through markup, with no code changes (read or compile) needed.

Version 2 came along a few years afterward, and among all the other goodies, it brought with it extensibility in the form of a provider model. A lot of its functionality could be adapted by the means of custom providers. Later on, it received the addition of the AJAX Extensions, which made AJAX-style effects astonishingly easy. It set the standard for years to come, leaving only room for more components.

To be honest, the following versions, 3.5, 4, and 4.5, only offered more of the same, with new specialized controls for displaying data and charts for retrieving and manipulating data and a few security improvements. A big change was that some of the framework libraries were released as open source.

Between versions 3.5 and 4, Microsoft released a totally new framework, based on the model-view-controller (MVC) pattern, and it was mostly open source. Although it sits on top of the infrastructure laid out by ASP.NET, it offered a whole new development paradigm, which this time fully embraced HTTP and HTML. It seemed to be the current trend for web development across technologies, and the likes of PHP, Ruby, and Java, and .NET developers were generally pleased with it. ASP.NET developers nowhad two choices—Web Forms and MVC, both sharing the ASP.NET pipeline and .NET libraries, but offering two radically different approaches to getting content to the browser.

In the meantime, the now venerable .NET Framework had grown up in an ever-changing world. In the modern enterprise, the needs have changed, and sentences such as runs on Windows only or we need to wait XX years for the next version became barely acceptable. Acknowledging this, Microsoft started working on something new, something different that would set the agenda for years to come. Enter .NET Core!

In late 2014, Microsoft announced .NET Core. It was meant to be a platform-independent, language-agnostic, free, and open source full rewrite of the .NET Framework. Its main characteristics were as follows:

• The base class libraries of .NET were to be rewritten from scratch while keeping the same (simplified) public APIs, which meant that not all of them would be initially available.
• It was also able to run on non-Windows operating systems, specifically several Linux and macOS flavors, and in mobile devices, so all Windows-specific code (and APIs) would be discarded.
• All of its components were to be delivered as NuGet packages, meaning that only a small bootstrap binary would need to be installed in the host machine.

• There was no longer a dependency (or, let's say, a very close relationship) with IIS, so it was able to be autohosted or run inside a hosting process, like, well, IIS.
• It would be open source and developers would be able to influence it, either by creating issues or by submitting pull requests.

This eventually took place in July 2016, when version 1.0 of .NET Core was released. The .NET developers could now write once and deploy (almost) everywhere and they finally had a say on the direction the framework was taking!

Rewriting the whole .NET Framework from scratch is a task of epic proportions, so Microsoft had to make decisions and define priorities. One of them was to ditch ASP.NET Web Forms and to only include MVC. So gone were the days when ASP.NET and Web Forms were synonyms, and the same happened with ASP.NET Core and MVC: it's now just ASP.NET Core! And it's not just that the ASP.NET Web API, which used to be a different project type, was now merged with ASP.NET Core as well (a wise decision from Microsoft, as basically the two technologies, MVC and Web API, had a lot of overlap and even had classes with the same name for pretty much the same purpose).

So, what does this mean for developers? Here are my personal thoughts about how the tech has fared:

• C#, Visual Basic, and F#; F# has gained a lot of momentum among the developer communities, and they have built templates for Visual Studio as well as lots of useful libraries.
• Open source is great! If you want to change anything, you can just grab the code from GitHub and make the changes yourself! If they're good enough, then chances are that others may be interested in them too, so why not submit a pull request to have them integrated?
• We don't need to decide upfront if we want to use MVC or the web API. It's just a matter of adding one or two NuGet packages anytime and adding a couple of lines to the Startup.cs file; the same controller can serve both API and web requests seamlessly.
• Attribute routing is built in, so there's no need for any explicit configuration.
• ASP.NET Core now uses Open Web Interface for .NET (OWIN) based middleware and configuration, so you will need to (significantly) change your modules and handlers so that they fit into this model; MVC/web API filters are basically the same.

• There is no dependency on IIS or Windows, meaning that we can easily write our apps in good old Windows/Visual Studio and then just deploy them to Azure/AWS/Docker/Linux/macOS. It's actually pretty cool to debug our app in Docker/Linux from Visual Studio! It can run self-hosted in a console application too.
• A consequence of the latter is that there are no more IIS Manager or web.config/machine.config files.
• Not all libraries are already available for .NET Core, meaning that you will either need to find replacements or implement the features yourself. The website https://icanhasdot.net/Stats has a good list of whatever is/is not available for .NET Core, and there is also a list in the project's roadmap at https://github.com/dotnet/core/blob/master/roadmap.md.
• Even the core (pun intended) .NET Core classes are still lacking some methods that used to be there; take, for example, some methods in the System.Environment class.
• You need to handpick the NuGet packages for the libraries you want to use, including for classes that you took for granted in the old days. For .NET; this includes, for example, System.Collections (https://www.nuget.org/packages/System.Collections), as they are not automatically referenced. Sometimes it's hard to find out which NuGet package contains the classes you want; when this happens, http://packagesearch.azurewebsites.net may come in handy.
• There is no more Web Forms (and the visual designer in Visual Studio); now it's MVC all the way, or Blazor, which offers some resemblance to Web Forms, and has some advantages too! Yay!

Let's see begin by looking at what .NET Core is all about.