ASPNET Core and NET Core and the Web Development Stack Timeline

Hello and happy Monday!

I’ve had an intense weekend with a sick 5-month-old, but I finally got around to buying a stroller for running and if feels great to run at a decent pace again! Loke is yet to crawl, and has been kind enough to let me sneak him in to work so I can get some writing done on my days of- for example, this post!

[caption id=“attachment_38023” align=“aligncenter” width=“695”] Loke at work with me Loke at work with me[/caption]

I’ve been meaning to post a blog post about the history of (.NET) web development, but struggled to find the time and energy as we have slept very little this weekend (still did my runs though!). I had written the timeline as a part of a book I’m publishing with Apress next month to clear up the confusion around ASP.NET Core, MVC, Web API, .NET Core, .NET Standard, the why and where we are now.

We decided the section got too long, and I wrote a shorter, more general timeline, for the intro chapter. But it would be a shame to waste it, and therefore I’ve decided to post it here instead. Understandably, I haven’t been able to cover all the details as I’ve tried to keep it short- but if something significant is missing let me know and I’ll make sure to add it!

Web Development Stack Timeline

Classic ASP (Active Server Pages) was the first server-side script engine created by Microsoft. It was a big deal when it came out as it was considered an important part of the next big step in modern computing- distributed computing. It had the ability to access data, build a model, do computing and business logic, and then dynamically generate HTML supported by any browser. ASP 1.0 came out in 1996 as a part of IIS 3.0, and two more versions came before the release of ASP.NET in 2001. Web Forms was one of the first programming models introduced in ASP.NET for creating web applications. Web Forms was a component-oriented framework and had a high concept compatibility with Windows Forms, the framework used for desktop application development at the time. It provided an event driven model that desktop developers were familiar with and made the transition to web from desktop development easier. Visual Studio provided a rich toolset, and support for third party toolsets, with familiar controls such as buttons, input fields and more. I used to work for a component vendor, Telerik, and although we sold GUI (Graphical User Interface) components for a wide range of technologies, everything from Web Forms to MVC, to Windows Phone, Web Forms was always the most popular component kit. The event driven approach made it easy to put together a web application fast and offered familiarity, but at the expense of fine-grained control, testability and extensibility. Thus, in 2007 Microsoft announced that they were working on another programming model, ASP.NET MVC, and in 2009 the first release was made.

But before we talk more about ASP.NET MVC, let’s take a step back all the way to early 2000 again. As systems were growing in size and complexity the need for web services grew. Distributed systems needed ways to communicate with each other, with different clients, across operating systems and languages. Business to business transactions became more common, as well as feature components, and at the same time decoupling and independent scaling became a core need for distributed systems. Over a short period of time we had gone from specialized and isolated components to cross-domain systems with a complexity we couldn’t even dream of a decade earlier.

In 1987 Microsoft introduced one of their first inter-process communication methods, DDE – Dynamic Data Exchange, that had a publish-subscribe model. A program subscribed to changes and was notified when a change happened. On top of DDE, and somewhat superseding DDE, was OLE – Object Linking and Embedding. OLE was object based, and when OLE 2.0 was released in 1993 COM was the underlying object model. Component Object Model was a way to bundle business logic in reusable components- but this was limited to local work. This is where DCOM, Distributed Common Object Model came in. DCOM allowed communication between components on remote computers. DCOM used Remote Procedure Calls, RPC,- a request-response protocol designed to facilitate communication in a client-server manner irrespective of whether the communication was local or remote. DCOM was not the only standardized RPC system out there, a big competitor was CORBA, another distributed component middleware that had steadily gained popularity since its release in 1990- 6 years prior to DCOM. With the release of .NET in late 2000 .NET Remoting came to replace DCOM. It supported different transportation protocols and serialization formats, and worked with objects. But there were still limitations with the available distributed component middleware. Scaling was difficult, they were complex and often tied to specific platforms. An example would be NET Remoting, which was Microsoft only and worked with binary or XML serialized objects. At the same time web applications were changing and were doing more than just serving up pages. The nature and scope of distributed applications was changing. That inspired the creation of ASP Web Services. The aim was human readable messages based on open standards that would work across platforms- and just as important: simplicity. ASP Web Services supported several standards such a as WSDL, HTTP and SOAP. This meant that as a consumer of a Web Service you wouldn’t need to know how the service was implemented, be that object model or language, as long as you as the consumer could read and use the same standards. You now had many options for communicating between processes, locally or remote. Across the internet with a service on a different platform you would use Web Services, but for fast binary communication you would probably use .NET Remoting and so on. A large system would often end up tying together components using different methods increasing the complexity of the system. Windows Communication Foundation, unveiled in 2003 and released in 2006, was introduced to solve all this. WCF was intended to be a unified programming model for building service-oriented applications that had explicit support for service-oriented development.

I mentioned RPC earlier, but I didn’t talk about REST (Representational State Transfer). REST is considered a lightweight alternative to RPC, and it quickly became a buzzword after being introduced by Roy Fielding in his dissertation in 2000. Soon the majority of APIs where REST APIs, and developers kept pushing forward REST over RPC. Ironically few seem to agree what REST is, and even fewer have read his dissertation. Developers wanted REST, and WCF provided some support for REST-style services. But it still had some limitations. The WCF Web API project was intended to fill the gaps, and eventually evolved and became what we today know as Web API.

To quote Microsoft:

“Although WCF provides some support for writing REST-style services, the support for REST in ASP.NET Web API is more complete and all future REST feature improvements will be made in ASP.NET Web API”

What is important to understand is that Web API was (is) a framework for developing RESTful HTTP services. It is not intended to replace WCF, it isn’t the only way to create and expose an API, and it will continue to evolve and be influenced by current trends. Web API was quickly embraced, partly because it tied in nicely with the ASP.NET MVC style of programming

Both ASP.NET MVC and ASP.NET Web API followed the Model, View, Controller pattern with actions defined in the controllers. The actions followed a REST inspired model. This is in contrast to for example Web Forms which is largely event driven like we talked about earlier. The biggest difference was that ASP.NET MVC uses a web engine to dynamically render web pages as it predominately is designed to create standard web applications, while Web API is designed to create RESTful/HTTP applications. Web API has a logical layer for content negotiation. Content negotiation lets the client and server negotiate so the best available data format can be used. Content negotiation can be implemented in ASP.NET MVC, but what would be harder to implement is the lack of dependency on IIS.

But where does ASP.NET Core fit in in all of this? Let’s talk about .NET Core and ASP.NET Core

.NET Core and ASP.NET Core

As I see it, there were two major driving forces that led to what we today know as .NET Core. Firstly, there was an increasing need for cross platform compatibility to stay relevant, and secondly, we had gotten to a place where we had too many subsets of the .NET framework, which was causing all sorts of problems as the subsets were created and maintained by different teams.

Since the first release in 2000 the .NET Framework has constantly evolved, but I think we can all agree that things started changing significantly after 2011. The trend towards cross-platform systems and applications couldn’t be ignored and as a result JavaScript had a significant increase in popularity. Node.js came out for Linux and MacOS X, and we could write web applications, back and front, in JavaScript. Microsoft took notice, and in 2011 several things happened. Firstly, together with Joyent, Microsoft implemented a native Windows version of Node.js. The same year WinJS, Windows Library for JavaScript, was released (at the time only for Windows Store Applications) with Windows 8 in 2011/2012. It was later changed to be used in browsers as well, and open sourced. Not long after WinJS, in 2012, TypeScript, a language that is a syntactical superset of JavaScript, was announced- and open sourced from the start. It was clear that Microsoft was making a shift towards open source with a new and refreshing developer focus, as well as embracing other platforms.

But, meanwhile we also had the issue of the many subsets of .NET framework. Such as .NET Compact Framework, Silverlight, Windows Phone, Windows Store and so on. They were maintained independently, and what they had in common was somewhat by coincidence, or by sharing similar starting points. Creating libraries that spawned the different subsets was a pain. I remember battling with linked files and preprocessor compilation symbols and builds, while still having to resort to separate libraries for some functionality. When portable libraries came out I got my hopes up, and quickly became a fan and advocate. So much that I did a Pluralsight training course on the topic. But they weren’t as portable as the name indicated. What portable class libraries did was look at the targeted platforms and find the common ground, and that became the boundaries for what you could use. If I targeted Windows Phone, and Xbox, then only libraries that supported both were available to me. And that wasn’t much. Many of the problems contributed to the motivation to build .NET Core, and later the .NET Standard.

2014 was the year many exciting announcements were made by Microsoft. ASP.NET vNext was announced in April, and .NET Core in November the same year. ASP.NET Core was a complete rewrite of ASP.NET- and was later known as ASP.NET 5 (and by some as project K), until Microsoft realized the name was confusing and renamed it to ASP.NET Core. .NET Core was first announced as .NET Core 5, but since developers wondered where on earth 1,2,3 and 4th release was (there weren’t any) they renamed it to .NET Core 1.0. Which made sense. .NET Core is a completely new concept, even if it does build on old ideas. Unfortunately, with ASP.NET Core, it was still confusing. They had changed the name so developers wouldn’t assume that it was the next version in line, and therefore better. But it could be compiled for both .NET as well as .NET Core. As a consequence, when you did a File-New Project-Web you would have three very similar looking projects, ASP.NET .NET Framework, ASP.NET .NET Core (.NET Framework) and ASP.NET .Core (.Net Core).

Here is the deal:

ASP.NET Core is a complete rewrite. It is faster, modular, everything is a NuGet package, it is host agnostic, has a light-weight HTTP pipeline, is cross platform and you can deploy the application as a standalone package- with everything it needs, and only what it needs.

That’s the framework, the ASP.NET Core framework. And that framework can run on top of both the good ol’ .NET Framework runtime (CLR)- tried and tested over many years and almost two decades, as well as on the .NET Core runtime (CoreCLR). In other words, you can get the benefits from the rewrite (except cross-platform ability for obvious reasons) and combine that with the .NET Framework runtime.

Or, you could wait it out, and keep writing great applications in the original ASP.NET. If you had the pleasure of following, maybe even experiencing first-hand, the first year or two with ASP.NET Core you might have wished you had waited. The process was lower and more complicated than Microsoft could foresee, and there were many breaking changes and issues along the way. Most famously was the introduction of the project.json file, that replaced the XML project file. Some were excited, some less so, but nonetheless they had to go back on that decision and today we are using csproj files again.

.NET Standard

I talked about the many subsets and forks of the .NET framework and you might have noticed that .NET Core doesn’t really solve the code sharing problem (at least not then or at the time of writing). In 2016 the .NET Standard was introduced to us, as a way to bring everything together. And as something that will replace the Portable Class Libraries.

So, what is .NET Standard?

.NET Standard is a specification, it defines a set of available .NET APIs. You can think of it as interfaces, and the frameworks that support the (or version of) .NET Standard as implementations. This is important to understand, it’s a standard and not an actual implementation. Portable Class Libraries used a union model, what the target libraries had in common would be what would be available in the PCL- which could be very little. And since you couldn’t use conditional compilation in a PCL, you would have to master a set of linked files combined with Adapter Pattern and Dependency Injection. With .NET Standard you can create truly portable class libraries, and hopefully only need to use conditional compilation for code that that is specific for the operating system. You can explore the API here: https://docs.microsoft.com/en-us/dotnet/api/

The future

Is .NET Core, .NET Standard and ASP.NET Core the future? Yes. It doesn’t mean that that everything else is thrown out the window. But things are changing- and I highly recommend that you stay up to date. .NET Core 3.0 adds support for WinForms and WPF (not cross platform- obciously!). ASP.NET Core 3.0 drops support for compiling for .NET. EF Core has matured and there are tools for migrating, Signalr Core is out of preview with a complete rewrite, and the library and tooling support for .NET Core has exploded. Likewise, .NET Standard has become a recognized and respected standard and you’ll find most popular third party libs support some version of it. But, most importantly:

After .NET Core 3.0 we will not port any more features from .NET Framework…
…With the .NET Core 3.0 release in September 2019 we think that all *new* .NET applications should be based on .NET Core…
… .NET Framework 4.8 will be the last major version of .NET Framework…

This was written by Scott Hunter, Director Program Management, .NET, in May this year. Only a week or so ago at the time of writing this post.
While older versions will be maintained and supported, the future is clearly .NET Core. If that makes you anxious, follow my blog as I’m planning a series of posts that cover the ins and outs in a comprehendible way. In the end I hope everybody is as excited about this as I am, the community certainly seems to be- and with everything being open source we have the unique opportunity to not understand the inner workings, but also contribute, to one of the biggest changes in the history of .NET.

ASPNET Core and NET Core and the Web Development Stack Timeline

Web Development Stack Timeline

.NET Core and ASP.NET Core

.NET Standard

The future

Comments