An Update On My ASP.NET Core Project

My previous post reviewed over utilizing ASP.NET Core to create a Web API endpoint. In that post, I stated that there was nothing as of that writing that prevented me from continuing the usage of ASP.NET Core and .NET Core. However, as time went on, it was decided to use OData. This is where my roadblock appeared. As of the writing of this post, OData support does not currently exist for ASP.NET Core. I’ve got a separate project that didn’t make sense to use OData, so we’re going with ASP/.NET Core for that project. I’m pretty excited about that, considering all the benefits I’d talked about in my previous post.

For those unfamiliar, OData (Open Data Protocol) is a standard that defines how to build and utilize RESTful APIs. This standard is utilized in the .NET world via the Microsoft.Data.OData Nuget package, and can be utilized in an ASP.NET project using the Microsoft.AspNet.OData Nuget package (both described in more detail here). With OData, a client can specify what data they would like returned via a query string or other parameter. This in turn is translated into a specific query that only returns the specified dataset. This is very useful for minimizing data traffic and ensuring the client gets what they need.

For the project in question, we had a project returning JSON data with multiple fields and child objects. The total payload, including all objects and fields, was over 600MB. For a mobile experience, this would be unacceptable. There would also be multiple clients requesting different pieces of this data at any given time. While the clients could receive the full payload, and just ignore the fields and objects they don’t need, this is a waste of traffic. I could also create different endpoints for each need, but that could become difficult to manage over time as more needs arise. OData gave us the opportunity to specify a generic endpoint, and allow the client to decide what data they receive.

Looking into OData support for ASP/.NET Core, I found nothing. Looking deeper into the documentation, I found the RESTier project. At face value, this seems to be utilizing a more ASP.NET Core approach to creating an OData endpoint. However, it is also not supported for ASP/.NET Core at this time. Perhaps some time in the future, this may change.

In the meantime, I’ve pulled that project over to a full .NET 4.6.2 and AspNet.Mvc 5.2.3 project. That process was not too difficult; I created a new ASP.NET MVC project, added the existing files to it, switched IActionResults to IHttpActionResults, changed NoContent() results to StatusCode(HttpStatusCode.NoContent) results, and swapped out the Core Nuget packages for full .NET packages and using statements. Overall, it wasn’t too painful, even if I’d rather avoid doing it again.

Thanks for reading!


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.