ASP.NET Core and the Enterprise: Part 1 Frameworks

Tuesday, October 11, 2016

When larger companies with larger development teams ask me about ASP.NET Core, I generally frame the conversation in terms of risk and reward. Yes, there is a new architecture and yes, there are new features, but, when working on business applications with long lifecycles you want to look beyond the obvious topics for evangelism and measure the risks.

There are six areas to consider in evaluating ASP.NET Core and it’s impact on business and operations.

Six Areas To Evaluate ASP.NET Core In the Enterprise

First is understanding ASP.NET Core’s relationship with the new .NET Core framework. That’s the topic for this post. In the future we’ll also be evaluating the new hosting model for ASP.NET Core, the HTTP processing pipeline, security features, the new data access landscape, and finally ASP.NET Core itself.

ASP.NET Core and the .NET Frameworks

We now have two distinct flavors of the .NET framework to choose from. First there is the full .NET framework. The full .NET framework is the mature .NET framework that has been around since the beginning, is pre-installed with Windows, and includes application level frameworks like windows forms, web forms, WCF, and WPF. The most recent version at this time is 4.6.2.  

We also have .NET Core, a new and modular version of .NET that runs on more than just the Windows operating system.

Where ASP.NET Core fits into the picture is that ASP.NET Core is an application framework that can run on either the full .NET framework or on .NET Core. Selecting a .NET framework flavor is one of your first decisions when making a move to ASP.NET Core. Do you want to run on the full framework, or .NET Core, or will you need to support both?

ASP.NET Core and Framework Flavors

When you choose to run on the full .NET framework you are running on the framework you already know. Yes, ASP.NET Core will be a bit different from the ASP.NET frameworks of the past, but your underlying framework is the same. In order to understand why you might chose .NET Core instead of the full framework we need to dig into the risk and rewards of .NET Core.

.NET Core Rewards

.NET Core is a cross-platform framework, meaning.NET Core will run on Windows, on the Mac, and on various flavors of Linux. .NET Core also works in a Docker container for those who are using or thinking about using Docker software containers.

.NET Core Home Page

One must understand that ASP.NET Core does not require .NET Core as the underlying framework. But, if you do choose to use .NET Core as your underlying framework, you will be able to author and deploy ASP.NET applications and services on all of these various platforms. Linux is, of course, a big target for server-side applications. Most enterprises are heterogeneous and already have the IT expertise to run business applications on both Windows and Linux servers. There is also the opportunity to save money as Linux servers typically run a bit cheaper, particularly when using cloud based infrastructure. On Azure, for example, a single 4 core virtual machine running Linux is currently around $90 cheaper per month than its Windows counterpart.

What’s not immediately obvious when talking about a cross-platform .NET framework is how the necessary tooling also works across platforms. .NET Core has no hard dependency on Windows or Visual Studio. All of the low level tools you need to do work will run from the command line. There is an entire new world of text editors and IDEs available that we can now use to develop .NET applications, including Visual Studio code from Microsoft, Project Rider from Jet Brains, as well as text editors like Sublime and Atom.

Editors and IDEs are plentiful

I’ve worked on more than one project over the years where there is a front-end specialist who uses a Mac. The front-end developer hasn’t been able to install Visual Studio and work with an ASP.NET project the same way a Windows developer would work with the project. This type of scenario is considerably easier with .NET Core because a developer on Apple hardware can write, run, and debug ASP.NET code just as well as a developer on Windows.

.NET Core is also an open source project. On GitHub you can find not just the code for the framework itself, but also the code for the unit tests, and the documentation. You can view bugs in the GitHub issues list and see the current status of a bug. I’ve been telling people that one of the underappreciated advantages of Microsoft’s move towards open source is not in having the source code to a framework or library. We’ve always been able to get source code, even if we had to use a de-compiler. What I’ve found valuable are the unit tests, because they often given me better insight into how a particular feature works compared to using documentation or the source code itself. The unit tests can describe a feature from several different perspectives and also tell me what a piece of software is not designed to do.

.NET Core - the CoreFx repository

In the enterprise, there is often a worry that open source projects do not have the same level of support as closed source commercial products. However, Microsoft has announced a support lifecycle of 3 years for each major and minor release of .NET Core. The .NET Core 1.0.0 release was June 27, 2016, meaning the end of support for 1.0.0 is in June of 2019, or even later if there is a Long Term Support (LTS) release in the future.

.netcoresupport

Something you’ll notice when looking at the source code on GitHub is how modular the new .NET Core has become. This is no longer a monolithic framework where you have everything or you have nothing at all. With .NET Core the fundamental pieces are smaller and integrated with the NuGet package management ecosystem. You can pull in just the pieces of .NET Core that you need to build an application.

.NET Core also supports an application deployment model known as a self-contained deployment. A self-contained deployment means you can put your asp.net core application into production with all of the .NET core assemblies the application needs to function, and these framework assemblies are all local. There is no global assembly cache, there is no framework installation required on the server. If you want a micro-services architecture with two dozen services deployed on one server, each ASP.NET Core service can deploy with it’s own version of the .NET Core framework and never need to worry about conflicting with the versions of other services or requiring the other services to upgrade. Everyone lives in perfect isolation. The downside here being that you’ll need to manage patches and updates to the framework for each deployment.

Are there other downsides?

The Risks

Making a cross platform version of the .NET framework required some hard work and sacrifices. If the full .NET framework was a diet plan, you could have doughnuts for breakfast, a deep dish pizza for lunch, and a bacon cheeseburger with egg on top at dinner time. No human can really consume this many calories in a day, but the calories are there for you if you want to try and eat them all. .NET Core is more of a lite meal with all the essential vitamins included. But, depending on your appetite, you might not find enough here.

The .NET Diet Plans

Where am I going with this analogy?

When I say that there were sacrifices made in creating .NET Core, I mean some technologies and features are missing, and some frameworks of the past will probably never appear in .NET Core.

There are generally three reasons for a feature of .NET to not appear in .NET Core. One reason is that there wasn’t enough time to port a feature to .NET core and the team is still working on expanding coverage. A second reason is that a feature might not make sense for a cross platform library and only makes sense on Windows. And finally, there are some technologies in .NET that have been around for 15+ years and are not going to move forward.

Unfortunately, many of us working in the enterprise space still use frameworks introduced in the original .NET framework of 2001. So what are the big pieces that are missing and what do you need to know?

For starters, there are entire frameworks that have not made the move to .NET Core. These are frameworks like WinForms, WebForms, WPF, Workflow, and WCF. From an ASP.NET perspective we don’t really care about desktop technologies like WPF, but there is a tremendous amount of enterprise software written using WebForms, and there are a tremendous number of services using WCF. I also know there is still software around using the predecessor to WCF, which was ASMX web services. Applications that rely on these frameworks might never move to .NET Core as they will require a re-design and a re-write. When you think about WCF in particular, a rewrite might not only impact your business but also your partner’s business.

I do want to point out that when it comes to WCF there is no server side WCF replacement. But, if you are writing a server-side application that consumes WCF services hosted in another service, there is an open source version of the WCF client libraries available. There is also some tooling (currently in beta) for Visual Studio for adding a service reference to a .NET Core application.

Gone Missing in .NET Core

There are also features that are not in .NET Core, at least not currently. Some of these may appear in the future, but these are features like the once hugely popular DataSet class. There is also no support for working with XML schemas or XSLT in .NET core. There are no distributed transactions (perhaps a good thing), no ability to communicate with LDAP or ActiveDirectory, and no class for interacting with an SMTP server. Some of these features, like LDAP and SMTP can be replaced with HTTP based cloud services or third party providers, but this will still require some work in a legacy code base.

Some features exist in .NET Core, but with small changes in the API. Examples include the reflection API (changed for performance) and the encryption API (for better cross-platform support).

When moving to .NET core you also need your third party dependencies to support .NET core. Many popular libraries like StructureMap, Automapper, Mediatr, and JSON.net all have working versions for .NET core. MongoDB, as of this writing, just released a .NET Core driver. Oracle support for the Entity Framework, however, still has plans for .NET Core. If you rely on third party libraries, you’ll need those libraries to port to .NET Core, or find an alternative, or re-write your application to remove the dependency.

One tool you might find useful in analyzing your applications is the .NET Portability Analyzer. You can run the analyzer as a Visual Studio extension, or from the command line. With the analyzer you can select a target platform, like .NET Core, or ASP.NET Core, or a specific version of the full .NET framework, and the tool can tell you what problems you’ll face.

Summary

To summarize this part of the conversation, I think we are still a few years away from seeing .NET Core play a large role in the enterprise. We have a tremendous amount of legacy code that relies on WebForms and WCF services. There might not be enough of a return on investment to re-write or port these applications, at least not at this early stage in 2016.

However, it is clear that Microsoft’s future direction is in the Core space. Yes, the last update to the full .NET framework did include improvements for ASP.NET and WebForms, but clearly the future innovation and hard work will be in the new core frameworks like .NET core, ASP.NET Core, Entity Framework core, and whatever other cores come along in the future.

I do believe that now is a good time to start some planning and start prototyping. If you have requirements for new server-side applications, I’d push to try using .NET Core first, and fall back to the full framework if there is too much pain. Running ASP.NET Core on the full .NET framework will solve many problems with missing features and third party dependencies. Yes, running ASP.NET Core on the full framework does feel like a temporary solution to use in transition, but it is a step in the right direction, even if the solution feels messy. In the enterprise, we always have to deal with messy. Plus, the expertise an enterprise can gain in these early days will pay dividends in five years.

Also In This Series

ASP.NET Core and the Enterprise Part 1: Frameworks (current)

ASP.NET Core and the Enterprise Part 2: Hosting

ASP.NET Core and the Enterprise Part 3: Middleware


Comments
gravatar Mithun Pattankar Tuesday, October 11, 2016
Scott, This series would be excellent for enterprise considering ASP.NET Core. I too strongly believe that enterprises will adopt .NET Core slowly, any existing application in production will continue for next 2 - 3 years. In fact one of my client still uses ASP.NET 2.0 and wants to continue it. ASP.NET Core and Angular 2 will gain more momentum in second half of 2017, that i feel.
gravatar Stephen Tuesday, October 11, 2016
Agreed. We require to integrate with ADFS using WS Federation, which sadly is not available yet in ASP.Net Core, even targeting the full .Net Framework. I'm sure there are a number of enterprise customers using ADFS who would have the same issue.
gravatar prakash p Tuesday, October 11, 2016
Hi Scott Thanks for the article. Love your courses on pluralsight. So, if we host .net core on full .net framework, would we be sacrificing the speed? ASP.net published some benchmarks recently saying they hit 3 million requests per second on ASP.net using .net core Thx
gravatar Scott Allen Tuesday, October 11, 2016
@prakash: That would be an interesting benchmark. I think I'll have to try that.
gravatar Aftab Ansari Wednesday, October 12, 2016
Great content. mostly same as your recent Webinar on pluralsight. Waiting for part2.
gravatar Shahzad Hassan Wednesday, October 12, 2016
Scott, I am a big fan of your courses on Pluralsight, thanks for that also thanks for this great article. We are working on a huge ecommerce application using Asp.Net core but targeting full framework. We started off with core run time but reverted back to full framework as when we started, the mocking frameworks were not supported on asp.net core. Despite the fact that features are missing from Asp.Net core but that doesn’t stop us referencing anything as a nuget package. This provides flexibility to reference third party libraries written in full framework which cannot be referenced directly into xproj. So create a full framework class library using csproj model, add a reference to third party dll. Create a nuget pacakage and reference it in .xproj We will be going live in few months time and that would be an enterprise level application. What I am really interested to see is how Kestrel would behave on a high transactional enterprise site. We have done some load testing here and we are getting 502 Bad Gateway errors. We couldn't find a workaround. There is open discussion on this on Github here https://github.com/aspnet/IISIntegration/issues/245. Any suggestions would be really appreciated. Thanks
gravatar Prasad Thursday, October 13, 2016
As always, great post. Thanks much Scott.
gravatar Kevin Adams Thursday, October 13, 2016
This was a great post. I think it was the first one I've read that clearly explained .NET core, ASP.NET Core, and why we may or may not want to choose Core. Thanks.
gravatar Allen Conway Thursday, October 13, 2016
Excellent article Scott.
gravatar Christopher Haws Saturday, October 15, 2016
You didn't mention the massive performance improvements with ASP.NET Core (if I remember correctly the request per second went from 70K to +5M). This could mean less server load, meaning you could potentially get rid of excess servers resulting in less support and runtime costs.
gravatar Scott Allen Saturday, October 15, 2016
@Christopher I haven't gotten to that part yet, but the benchmarks don't hold up in real apps. More on that in part 2.
gravatar Robert Slaney Tuesday, October 18, 2016
Hey Scott, Any guidance for creating enterprise library packages that can be consumed from both 4.6.x and .NET Core as part of this series would be greatly appreciated
gravatar Andrew Brad Tuesday, October 18, 2016
Definitely one of the most objective and impartial breakdowns I've seen of .Net Core thus far. The fact that the intended audience is the enterprise crowd is something I think was sorely missing from existing commentary out there on full .Net vs. Core. Thanks!
gravatar Dave Vorgang Monday, October 24, 2016
Hi Scott, One thing that is confusing to me is that there is the ASP.NET Core Application Framework that can run the full .NET framework or the .NET Core. Correct? If so, does that mean I can create Web Forms, VB.Net, WCF using the ASP.NET Core Application Framework going against the full .NET framework? What advantage is it to use the ASP.NET Core Application Framework if I'm going against the full .NET framework? Sorry to bother with these basic questions but I'm just little confused and the naming of the "Application Framework" and ".NET framework" doesn't help any. Thanks
gravatar Dave Vorgang Monday, October 24, 2016
Not sure I understand. Let me rephrase it. If I use ASP.NET Core against the full framework can I use WCF or Web Forms or whatever the full framework (I'm assuming it's 4.6.x) allows? Or, am I limited and what is that limitation? Again, sorry, I am very new to this.
gravatar Scott Allen Tuesday, October 25, 2016
@Dave - sorry, my previous comment was not well worded. I deleted it to avoid confusion. The answer is no. If you have an ASP.NET Core project, there is no way to add WebForms or WCF to the project, even if you run Core against the full framework.
gravatar Dave Vorgang Tuesday, October 25, 2016
Thanks Scott. I really like your videos on PluralSight. Any chance of creating a ASP.NET MVC and Aurelia video? Thanks
gravatar Dave Wednesday, October 26, 2016
@Dave - yes, I'd like to do that one. Just need more hours in the day! I might work it in somewhere in an upcoming course.
gravatar Kwame Friday, November 11, 2016
Could you do a Pluralsight video on a full Asp.Net Core web application using Angular 2? There's absolutely nothing of the sort out there - it's either standalone Angular 2 or Asp.Net Core..
gravatar Scott Allen Saturday, November 12, 2016
@Kwama: I've been using aspnetgenerator-spa with yo to setup the projects. I'll probably not be doing any Angular 2 content with Pluralsight, sorry!
Comments are closed.

My Pluralsight Courses

K.Scott Allen OdeToCode by K. Scott Allen
What JavaScript Developers Should Know About ECMAScript 2015
The Podcast!