Getting Started With ASP.NET Core

Over the course of the last month, I’ve had the opportunity to learn, experiment with, and implement a Web API project utilizing ASP.NET Core. While this has been a very edifying experience, I found that the details of the newer technology is a bit spread out across multiple sources. My aim of this post is to compile those details, describe how I’ve started out, and explain what’s available and possible.

The first thing that I’d like to review over is probably my favorite part of .NET Core as a whole: portability. Do you want to use the rich features of Visual Studio to develop your application? Great, that still works as before. Would you rather just pull up Visual Studio Code or other simpler editor to make changes, big or small, and then build the code easily? The dotnet CLI gives you that capability, along with being able to create new projects, run tests, publish, and others. Do you want to develop .NET software, but don’t have an installation of Windows? No worries – .NET Core can be installed on Linux and Mac.

Next, we tackle one of the concerns that I’ve had – dependencies. Many well-used Nuget packages simply aren’t compatible with .NET Core. One would think this is a deal-breaker, but that’s not quite the case. Many third parties, such as the xUnit team, have created a .NET Core-specific Nuget package to be used in this instance. As of the writing of this blog post, I’m successfully using xUnit 2.2.0-beta5-build3474 and xUnit.Runner.VisualStudio 2.2.0-beta5-build1225 (the runner is used to run the tests in Visual Studio’s Test Runner). These versions can be found in the Nuget Package Manager by checking the box to ‘Include prerelease’ packages, which is next to the search box. As further proof of this point, I’m also using NLog.Web.AspNetCore version 4.3.1 for logging, and Swashbuckle.AspNetCore version 1.0.0-rc3 to bring in the visual documentation tool Swagger UI.

For anyone who has created an ASP.NET/Web API project in the past, you may find that some namespaces have either moved, or are not implemented at all. An example of this is when pulling settings from a configuration file. With the full version of .NET, one may likely use ConfigurationManager. However, as Jonathan Danylko succinctly states here, it is not available in .NET Core. Not all hope is lost for configuration-file based settings – dependency injection can be used to pass around the settings (see his post on the matter, or the documentation, for more information). Thus far, I’ve found nothing of this nature that prevented me from continuing with the project. The pieces seem to all be there, and may just be implemented in a different way.

From logging to dependency injection, unit testing to data access, and many things in-between, ASP.NET Core has proven to me that it is a stable, reliable option to make cross-platform APIs. If you have a project coming up that could use flexibility, extensibility and mobility, and/or you would like to work with some really interesting technology, I recommend this stack to you.