.NET Core 2.0 for Enterprise .NET Developers

It’s finally here!  The .NET Team at Microsoft released .NET Core 2.0 last week (August 14, 2017) along with .NET Standard 2.0, ASP.NET Core 2.0 and Entity Framework Core 2.0.  This release is provided 10 months after the release of .NET Core 1.1.  Here is a simplified timeline of the major releases for .NET Core.


I’ve seen many enterprise developers waiting to implement .NET Core and they are still wondering if its ready for their use cases.  In this post I will highlight the features of .NET Core that Enterprise .NET developers should care about.  To be clear, these will be a mix of features from .NET Core 1.0 and 2.0.


As you can see from the timeline above the .NET Team has been busy and deploying previews/releases very often (there are even more preview releases not shown in the timeline as well).  No longer are they constrained by Windows for releases as they were with the full .NET framework.

The .NET Team has made big changes to the foundation of .NET Core based on learnings and shortcomings from the full .NET Framework.  Many of these changes just couldn’t be made to the full framework because of early design decisions that limited them.  As a result, there is less cruft in the framework and modern features built right in.  Dependency Injection for example is now provided by the framework.  It can also be replaced if you prefer a third party option.

Large enterprises will have to be more agile to continue to stay relevant in an environment of small startups that are popping up to compete with and steal their market share.  Many enterprises have already started their  journey to agile but it’s hard to be agile with a non-agile development platform.  They need a platform that will adjust and evolve as quickly as the industry does.  .NET Core provides the agility to support and facilitate agility for developers.


One of the best new features in Core is the ability to deploy framework runtime versions side-by-side.  Unlike full .NET Framework releases that built on top of prior versions, each version of the .NET Core runtime is completely separate.  Changing runtime versions for an application is as easy as providing a global.json file in your directory.  Here is a sample of the contents of the JSON file:

   “sdk”: {
      “version”: “2.0.0”

The .NET Core tooling also provides a new command line interface (CLI) which makes application compilation, execution and packaging easier.  The CLI allows for easy integration into continuous integration and continuous delivery systems.  The following is an example of creating a new Console app, restore its Nuget packages, compiling the project and finally running the app all from the commandline:


But don’t worry, if the command line isn’t your favorite, you still have all the great GUI goodness of Visual Studio as well.

.NET Core was built with containers in mind as well.  Just like virtual machines changed how we operate in IT, I believe containers will have the same or greater effect and we must be ready with a platform that supports containers as a first class citizen and actively works to support them.

Enterprises have to increase their speed of delivery to remain relevant.  .NET Core provides all the speed and flexibility you need to deploy quickly through improvements to runtime deployments, a new CLI and the support of Docker.

Open Source

.NET Core has been built in the open on Github by the .NET Team.  This means anyone can see the source code for .NET Core and even submit pull requests if they want to fix a bug or add a feature.  Further the Microsoft engineering teams are working out of Github day to day so they are more accessible than ever.  You can open issues and questions through Github and receive a reply from the team working on that repo.

This is a huge change for Microsoft.  Looking around, few companies have embraced open source like Microsoft.  Enterprises need access to the source they are using and the teams that build it.  Microsoft has always been pretty good about building community and being available for customers but this takes it to a whole new level.


Both .NET Core 2.0 and ASP.NET Core 2.0 have significantly better performance over previous versions.  ASP.NET Core is now 4x faster than NodeJS for serving plain text over the web based on the 3rd party TechEmpower benchmark scores and they aren’t done yet.  The team is committed to working on performance with every release and have a passion for showing how fast .NET can be in comparison to other frameworks.  Checkout more details on the benchmarks page.

I see performance issues in software from enterprise development shops all the time.  It’s a struggle to balance new feature development and performance with the business.  Usually the business only wants better performance when a customer complains and then they scold the developers for making it slow.  Anytime we can get performance improvements from the underlying framework that is a big win.

More APIs

The early versions of .NET Core were missing many heavily used .NET APIs.  It was a great starting point to test the waters but not a reasonable choice for most legacy systems/applications.  With .NET Core 2.0 and support for .NET Standard 2.0 over 30,000 APIs are now included.  As a result, approximately 70% of existing Nuget packages will work with .NET Standard without modification.  This means its even easier to update your legacy applications to .NET Core.  I’ve personally followed several projects that couldn’t be updated to .NET Core 1.0 because of missing APIs but now work with .NET Core 2.0.

Who else is using it?

From large enterprises to small innovative startups, all kinds of business are using .NET Core in production with great success.  Here a few well know companies:

  • Raygun
  • Jet.com
  • StackOverflow
  • Age of Ascent
  • Alaska Airlines
  • Azure CosmosDB

Check out the .NET Customer Stories page for more details and the full list of customers.


The .NET team has been  working hard to complete a 2.0 version that is ready for prime time and they delivered!  I’m actively working to get my enterprise development teams migrated over and believe most .NET shops should be doing the same. There are too many benefits to ignore it now. 

What do you think?  Share your thoughts and questions in the comments below to keep the conversation going.

Leave a Reply