Ten Reasons to Look at .NET Core Now

One of the top reasons I believe you may find .NET Core compelling is the strong focus on modularity. You may have heard that products built with .NET Core are much leaner than their full framework counterparts. This is true in the sense that .NET Core's code base is separated into smaller assemblies, each focused only on their intended use. It is easier to include only the pieces of the framework your product needs. Therefore, you can cut out a lot of what you don't need.

We can take this a little further and say it is much easier to pull out pieces of the framework you may need to advance the functionality in an existing project, even if that product is running on the full .NET framework. Take ASP.NET Core, for example; you may find a small assembly in the Microsoft.AspNetCore namespace that could be highly useful for your ASP.NET 4.6 application.

Do you have an interest in building an ASP.NET Core application, but would like to run it Linux? Well, .NET Core has you covered there, even if you are developing on Windows using Visual Studio. I would recommend you bookmark this page of the .NET Core documentation. It lists all of the current targetable platforms for your application; this includes versions of Ubuntu, CentOS, OS X, and more. This list is updated when more platforms are added.

And finally, take a look at this piece of documentation to guide you through the process of deploying to other platforms.

Universal Windows Platform (UWP) is the answer to this question, and it comes with a few bonuses. The first is running UWP applications on any device in the Windows family. When UWP first appeared, it allowed you to develop applications for Windows 10 Desktop and Mobile; since then, Windows 10, Xbox, and Holographic have been added to that list. It is also worth keeping in mind that UWP apps, when set to release, are set by default to be optimised and compiled along the native chain, allowing for increased performance.

ASP.NET Core represents a solution with minimal overhead and is designed to run effectively in cloud-based environments, while maintaining the flexibility to be easily deployable to on-premises hardware. The configuration system developed for ASP.NET Core allows for a variety of options, such as taking in data from JSON, XML, or INI files; environment variables; in-memory sources; and more. If you are a veteran of full framework ASP.NET, you'll also find the HTTP Handlers and Modules have been replaced with the unified Middleware Components, which are easily configurable.

ASP.NET Core MVC is not a replacement for full ASP.NET MVC (which is still being developed along its own road map), but instead is newly constructed from the group up implementation of the MVC pattern that is optimized for use with ASP.NET Core. You'll find some of the features with which you will be familiar, if you come from a full framework background, such as the Razor; but you'll also find a few things of interest that can make your life as a developer easier. One of these is that you no longer need to derive your controllers from different classes for Views and WebAPI. You can derive both of your controllers from the abstract class Controller, and its purpose is determined simply by the return type of your actions. For example…

[Route("api/[controller]")]
public class DataController : Controller
{
   public SomeData GetData()
   {
      return new SomeData() { Data = "Hello!" };
   }
}

If you looked at .NET Core in the early days, you would have found yourself noticing there were some hurdles to jump to migrate some .NET Framework code to .NET Core. However, since then, the developers have taken a direction that brings the two frameworks closer together, and eliminates many of the challenges you could face. This effort has produced what is known as the .NET Standard Library, which supports a few key scenarios:

• Defines a set of BCL APIs for all .NET Platforms to implement.
• Enables the development of portable libraries that can be used across .NET runtimes.

The CoreCLR—which represents the complete .NET Core runtime implementation—contains several components. The .NET GC and Native Interop is one, but if I were to pick one for this presentation, I'm going to go with the RyuJIT. Years in the making, the RyuJIT was included in .NET 4.6 for x64 in 2015. It's not only faster at generating code, but also generates code that is as good as or better than the x64 JIT.

Included in the CoreCLR, and receiving considerable investment in its future, .NET Core brings this high performance jitter to the other platforms we've covered. Granted, your application has increased performance along with what has already been gained by the other points we've talked about.

You can find more information on GitHub here.

ASP.NET Core ships with a built-in HTTP server implementation named 'Kestrel.' This represents an addition option when deploying your ASP.NET applications, allowing you to remove IIS from your stack. If you start a new ASP.NET Core application from the templates provided by Visual Studio—with the latest .NET Core tooling installed—you will notice the following code in your program.cs…

public static void Main(string[] args)
{
   var host = new WebHostBuilder()
      .UseKestrel()
      .UseContentRoot(Directory.GetCurrentDirectory())
      .UseIISIntegration()
      .UseStartup<Startup>()
      .Build();

   host.Run();
}

If you are missing the line UseKestrel(), add this in as shown above and you are ready to go. Under default settings, you can navigate to your application from the browser with the URL http://localhost:5000.

This is all you need; and without the over-head of IIS, you'll find your application's response time to be improved.

You can find the benchmarks used in the slide here.

If you are considering building a system organised into microservices, and given what we've already covered in this presentation, .NET Core could be the framework for you. In this environment, the reduced overhead and high performance goals of the framework can really shine in this environment. Also note that, since the release of .NET Core, you'll also find Azure support for the framework is on the increase; and I have Azure Service Fabric in mind.

Like developing using command line interface tools, or working on a platform from which you can't run the Visual Studio IDE? Well, .NET Core had CLI tools in mind during its design. Here are a few steps to get you started…

Install .NET Core.

Then, open a command window, navigate to a directory of your choosing, and type….

dotnet new

Take a look in the directory, and you'll find a very simple console application ready for development.