A Bit of History Regarding the .NET Framework

Travel back with me to the year 1998. Were you building software with Microsoft technologies? First, you could build apps or components with C/C++ and use big Windows-centric pieces like Microsoft Foundation Class Library (MFC) and the Component Object Model (COM). Another option was Visual Basic. Here, you sacrificed low-level control in exchange for a very simple way to build data-driven apps with a nice graphical user interface. Or, you might have started your web development career building Active Server Pages (ASP) with gobs of server-side scripting.

The .NET Framework changed the game. Microsoft introduced the Common Language Runtime (CLR). This application virtual machine executed code compiled down to an Intermediate Language (IL) and offered capabilities like thread management, garbage collection, memory management, and more. Any app written for .NET ran in the CLR.

Software written in multiple languages—including the brand new C#—had shared access to the Framework Class Library (FCL). The FCL (with the Base Class Libraries at its core) offered a unified way for different apps written in different languages to perform data access, web application development, input/output (I/O), network communication, and more. These shared libraries also defined higher-order constructs like ADO.NET, and ASP.NET Windows Forms, and, later on, things like the Windows Communication Foundation (WCF) and the Windows Presentation Foundation (WPF).

Web development took off shortly after the release of the .NET Framework 1.0 in 2002. ASP.NET offered an easy-to-use programming model, and many countries saw the explosion of broadband availability that made rich web applications usable. However, that simple programming model came at a cost. Developers were explicitly shielded from actual web programming. Most of the work was server side, with little JavaScript or HTML interaction. If you needed smart UX components, you bought them from software vendors and baked those controls into your ASP.NET app. ASP.NET Web Services let us expose a SOAP endpoint by adding a basic annotation to a function. As a result, I paid little attention to the HTTP processing pipeline. All of these .NET web applications were also closely intertwined with the Internet Information Services (IIS) web server.

Over the years, the .NET Framework fragmented to support the needs of specific platforms. Each of these platforms—including Silverlight, Windows Phone, and ASP.NET 4—diverged slightly on application model, framework surface, and runtime. Even though the .NET framework was optimized for a given platform, this fragmentation made it tough to build cross-platform systems.

Although all of these design decisions improved developer productivity, they began to become a hindrance as demand increased for more lightweight, cross-platform applications. The built-in overhead and abstractions were getting in the way.

The Introduction of .NET Core

Announced in 2014 and released in 2016, .NET Core represents a modern take on application development. It’s entirely open source. It’s modular, lightweight, and compatible with Windows, Linux, and macOS.

Let’s dig into the major differences between the .NET Framework and .NET Core:

• First, .NET Core is more modular. Instead of inheriting the entire .NET Framework and massive assemblies like system.web, .NET Core brings in dependencies as NuGet packages. You add only what’s needed for a given app. This makes your applications smaller, less memory-hungry, and more amenable to container-based deployment.

• What’s also new is the front-and-center use of a command-line interface (CLI) for .NET developers. Although there were CLI tools before, many .NET developers treated the Visual Studio development environment as their gateway to .NET development. No longer. From the .NET Core CLI, you can create projects, add packages, restore dependencies, build projects, run the app, and much more. And with the introduction of Visual Studio Code, Visual Studio for Mac, and JetBrains Rider, .NET developers have a wealth of options for building apps.

• For the web developer, ASP.NET Core ushers in a variety of changes to the programming model, as well. Gone are the global.asax and web.config files. Now, you have a new approach to middleware, application startup, and patterns like dependency injection. An ASP.NET Core web app is actually a console app that instantiates a web server. The lightweight Kestrel web server is the default option, and you have more control than ever before over the request handling pipeline. These asynchronous pipelines have access to middleware that handles static files, authentication, routing, and more. What happened to the web.config file from ASP.NET? An ASP.NET Core app uses an extensible configuration provider that lets you pull in configuration data from a variety of sources—JSON, XML, environment variables, and in-memory .NET objects, for instance.

• Not everything from the .NET Framework made its way into .NET Core. Today, it supports ASP.NET Core (web apps), console applications, class libraries, and Universal Windows Platform (Windows Store) apps. Microsoft announced that .NET Core 3.0 would also support desktop application frameworks like Windows Forms and WPF. But don’t hold you breath for classic .NET Framework services like WCF or Windows Workflow Foundation (WF) to make it over. Neither is under active development by Microsoft, and porting to .NET Core seems unlikely.

Deciding Which to Use When Modernizing .NET Apps

Pretty clear cut, eh? Drop everything and get your apps over to .NET Core? It’s not that easy.

It appears that .NET Core is the future. To be sure, Microsoft continues to iterate on .NET Framework and dutifully issues updates. It’s not a “legacy” platform or scheduled for retirement. It’s a robust, mature framework. But Microsoft’s focus is clearly on .NET Core and encouraging developers to adopt it as their base framework for all future development.

Microsoft issues some of its own guidance about when you should use each. For example, Microsoft suggests that you should stick with the .NET Framework if your app already uses it, you depend on third-party libraries or technologies that aren’t available for .NET Core, or you’re using a .NET technology (like WCF or WF) that isn’t coming to .NET Core. Conversely, Microsoft recommends .NET Core if you have cross-platform development or deployment needs, you’re deploying apps into containers, you want high performance with minimal infrastructure, and you run apps with different versions of .NET on the same machine.

Summary

Don’t replatform .NET Framework apps to .NET Core just because .NET Core is new. Do it only because you’re getting legitimate value for the effort. Would replatforming to .NET Core enable you to deliver features faster? Would it allow you to use less expensive hardware and operating systems? Does it support the testing and release automation tools that your company depends on for apps written in other programming languages?

Even though your new .NET development might happen in .NET Core, your existing portfolio of apps might only incrementally migrate over. In Chapter 7, we look at the specific recipes for how to modernize those applications that benefit from an upgrade.