Microsoft .Net Core review: Finally ready for prime time

It’s risky and often foolish to rush into a new software development framework, programming language, or technology platform too early in its lifecycle. Beyond the usual issues of too much hype and too little stability, new tech tends to lack staying power. You might end up investing precious time and effort into learning the ways of a tool that becomes abandoned or, worse, eliminated. It happens more often than you might think.

So if you have resisted the adoption of .Net Core, no one could blame you. When “ASP.Net vNext” was announced in 2014, its advantages—modular, small footprint, more speed—were immediately interesting to every .Net developer. When the first release candidate of .Net Core arrived the following year—supporting cross-platform .Net development, hosting ASP.Net on Linux, and open source code—the new platform became even more compelling. But it was also very alpha, with showstopping shortcomings.

For starters, there was no tooling for vNext; Visual Studio support didn’t arrive for months. The platform was also missing crucial APIs and lacking in documentation. In what has become a cautionary tale, Microsoft threw a wrench into the works by switching to a new project file format, then switched it back. All of the name changes (ASP.Net vNext to ASP.Net 5 to ASP.Net Core 1.0; .Net Core 5 to .Net Core 1.0; Entity Framework 7 to Entity Framework Core 1.0) only added to the confusion.

It hasn’t been a short or easy wait, but thankfully the wait is over. In recent months the .Net Core and Visual Studio teams have put the pedal to the metal and rallied to deliver a production-ready platform. As we’ll see, we finally have the tooling, the packages, and the documentation we need to get going with the new platform. If you’re beginning a .Net project today, especially an ASP.Net solution, you should think seriously about using ASP.Net Core instead of ASP.Net MVC.

Visual Studio 2017 to the rescue

The major red flag out of the gate was the lack of tooling for the new platform. The barrier to getting started with vNext on day one was so high that even seasoned veterans were frustrated. Instead of being supported in Visual Studio 2013, the platform was held together by PowerShell scripts and one-off console apps. Even Visual Studio 2015 took a while to gain basic tooling. Periodic updates to Visual Studio 2015 added desperately needed .Net Core tools, but these were limited and very rough around the edges.

With the betas of Visual Studio 2017, the tooling for .Net Core really started to take shape. There was a rough patch with the project file format switch up, but with the GA release of Visual Studio 2017 a few weeks ago, things are looking great. Project templates are solid, front-end build tools are working, major freezes and crashes are gone. This is the Visual Studio experience you’d expect, and I would recommend making the switch from Visual Studio 2015 as soon as possible.

There is no more messing with complicated setup procedures, no more reliance on the command line or PowerShell (unless you want to). Simply install Visual Studio 2017 and get started. Almost all of the tooling for .Net Core MVC development is available now as well (except Tag Helper IntelliSense—come on!). With Visual Studio 2017, we finally have a modern, flexible front-end development environment with support for Node.js, NPM, Bower, Gulp, Docker, browser link, and more. And the community edition is free.

An end to project flux

A number of early design changes in .Net Core caused major pains for early adopters. The biggest was Microsoft’s decision, starting in Visual Studio 2015 and continuing through the Visual Studio 2017 betas, to change the project structure for .Net Core projects. Instead of using the old XML-based .csproj files, a new project format would be created in JSON call project.json. It was an opportunity to leave the past behind and start fresh with a more concise file format.

Unfortunately as more developers began using the new format, its weaknesses began to show, particularly for those who hoped to one day upgrade existing projects to .Net Core. Finally it was decided that the project file format would return to .csproj /MSBuild, albeit in a cleaner fashion. This resulted in a huge mess for users who had solutions using project.json. Projects broke and required a lot of troubleshooting to get working again. Microsoft, for its part, created conversion tools and even offered to help users port their project.json files back to the old format.

Today there is a proper road map for the long-term future of .Net Core. All of the major decisions have been ironed out and the surprises moving forward should be minimal. If you want to accomplish something in .Net Core, there is now a recommended and clear way to do it in most cases. You won’t be left scratching your head. As some consolation for the project format switcheroo, Visual Studio 2017 will now automatically perform a one-way conversion of .xproj solutions when you open them.

A unified API

It became clear early on that porting libraries to .Net Core was going to be difficult and problematic. In order to create a portable class library (PCL) that can be shared across .Net platforms, you need to guarantee that the APIs used by the library are available in each platform. This guarantee didn’t exist at the beginning of .Net Core. Because .Net Core had limited API availability and class libraries were generally written for specific versions of the full .Net Framework, most PCLs could not be used in a .Net Core project.

To address these issues, Microsoft created a unified core API called .Net Standard. All .Net runtimes, including the .Net Framework, inherit from the unified core APIs of .Net Standard. This means that where you once had to target specific versions of the .Net Framework when developing a PCL, you can now target a single base library that is implemented by all runtimes and works across all frameworks.

Microsoft

There are still versions of .Net Standard of course, but they are much more predictable. Each subsequent version of .Net Standard has more APIs available for use. With the soon to be released .Net Standard 2.0, you’ll have complete coverage across all .Net runtimes in a single base library. At the moment .Net Standard v1.6 is sufficient for many .Net developers, myself included. Version 2.0 is basically the final hurdle for mass .Net Core adoption, and it’s close!

Microsoft

Then there are the third-party libraries. In the early days of .Net Core you’d open up NuGet and look for a critical package you use all the time, only to discover it didn’t exist yet for .Net Core. Porting to .Net Core was hard. Some APIs used by these packages simply were not available, so there was no choice but to wait. Even when the APIs were there, all of the tooling problems previously discussed made the work difficult and time-consuming, especially for programmers who maintained these libraries in their spare time.

With the .Net Standard API, life got better quickly for package maintainers. Third-party libraries ported to .Net Core have grown considerably. Today the number of NuGet packages for .Net Core still pales in comparison to the packages for the full .Net framework, but the most popular ones are there alongside hundreds of others ready to go. In the most recent project I started, I’ve found that all of the libraries I needed were available for .Net Core.

Documentation has caught up

The final hurdle to .Net Core adoption was inadequate documentation. Microsoft did a wonderful initial job of populating the ASP.Net site with detailed tutorials, deep dives, documentation, code samples, and videos for vNext through Core 1.0. But as major changes were made in the frameworks, the documentation became stale. At any point after the initial docs were written, a newcomer could begin a .Net Core tutorial, follow every instruction to the letter, and end up with a program that would not compile. That is the kind of pain that can turn a newcomer against the platform for life. Even for me, someone who has been developing C# and ASP.Net since their inception, the experience of testing out a new project using .Net Core at various points in its history was horrible. It was so full of head fakes that it felt like a cruel game.

Today the vast majority of the documentation and tutorials have been updated to correct the major discrepancies between versions. You can now safely follow a guide or read about a feature without being misled … for the most part. There are still a few cases where the docs need updating, but in comparison to the old .Net MVC docs, the documentation on .Net Core is clear and robust.

Current documentation isn’t important for only developers new to .Net. It might be even more important for those intimately familiar with .Net Framework and ASP.Net MVC development because so many core concepts have changed. I know from my own experience that reading every page of the tutorials, fundamentals, and MVC sections was necessary to understand the new way of doing things and to make sure that .Net Core was a good fit for my project. The docs are also useful for learning when to use the full framework, which features are not yet supported, or when a feature you need (like SignalR) is coming, if at all.

A good time to dive in

Of course, .Net Core isn’t perfect. There are still issues to be addressed that could be deal breakers for some. But if you’re a .Net developer, the time is right to start learning the new order of things. The tools, APIs, and documentation have fallen into place, and you can jump in without worrying that the rules will change. Best of all, the improvements .Net Core offers are both deep and vast. To summarize the highlights:

• Modern front-end web development. Visual Studio 2017 makes the new school of lightweight web development the default. When you spin up an MVC project, deployable static files like JavaScript, CSS, and image assets are separated out from your server-side code and views. Bundling and minification are added as a NuGet package by default, and Bower is hooked up for JavaScript package and dependency management. Because Node is built right into Visual Studio, getting a task runner like Grunt or Gulp running is fast and easy. Tag Helpers, another new feature, eliminate the mangled mess in Razor views caused by calling @Html.LabelFor or the like for every component.
• Dependency injection and middleware. ASP.Net Core was designed from the ground up for dependency injection. It sports an Inversion of Control (IoC) container out of the box, and you can start registering services (via the Startup class) and using Constructor Injection immediately. No additional frameworks or packages required. Likewise, Middleware is a first-class citizen with a clearly defined pipeline and configuration. Components like authentication and logging, which tried to shimmy themselves into the old ASP.Net pipeline and imitate middleware, are now added in an obvious way with an editable order, like any real middleware you might add.
• Lightweight, cross-platform, portable. Everything in .Net Core is added as a NuGet package. ASP.Net Core itself is added as a NuGet package. MVC? Another package. Even something like the System Component model must be added as a NuGet package. The upshot is that you use precisely what you need and no more, reducing threat surface area, bug exposure, and compile time while also opening the way to cross-platform development and deployment. With ASP.Net Core decoupled from the full .Net Framework, we can now develop and deploy on MacOS, Linux, and Windows.

Our shop has already moved from Visual Studio 2015 to Visual Studio 2017, which was quite painless because Visual Studio 2017 opens Visual Studio 2015 solutions without a need for conversion. And once you’re on Visual Studio 2017, you have all of the tooling you need to start developing with .Net Core. We’ve enjoyed working on our first large-scale ASP.Net Core application—so much so that we’re considering porting a recent application built on ASP.Net MVC 5 over to Core and making .Net Core our standard moving forward. The .Net Core platform has come a long way. Visual Studio 2017 is really very good, and the future is bright.