Upgrade to Visual Studio 2015 Update 3 and .NET Core Tooling

Yesterday I installed the Visual Studio 2015 Update 3 and began playing with a new ASP.NET Core API project. But the NuGet packages needed to be updated and when I tried to update them, they could not be found.

Clue: Pay attention to the little black flag in the upper right corner of Visual Studio 2015 (flag) and install the .NET Core 1.0.0. VS 2015 Tooling Preview 2.


The install took a fair amount of time, but when it was done, I created a new ASP.NET Core API project and bada-bing, everything seems happy.

Upgrading to .NET Core RTM and CamelCasing

This post is primarily a place holder and reminder to review Rick Strahl’s post on this topic a few more times.

The change in default serialization does not yet affect me because I was not relying on RC2 for anything serious. However it is critical to note this default behavior for future reference because many of my APIs serialize “as is” so most of my JSON is PascalCase and changing that midstream would bork every client that relies on case sensitivity in the data.

I particularly like Rick’s take on this:

“Personally I prefer to see stuff like this as an easily accessible option, and not something that is rammed down your throat - serialization shouldn't arbitrarily change the naming of properties. While that is often desirable I'm betting there are plenty of scenarios (especially when dealing with .NET to .NET) where you'd much rather have the serialized content reflect the original naming.

“It's especially frustrating in that this doesn't just affect server code where you could easily refactor, but client side code that may already be running. It also makes it harder to port existing code to ASP.NET core and it's not exactly something that's super easy to find if you're searching unless you already know that there serializer settings being sent to JSON.NET somewhere in the framework.”

Well, now the real play begins with .NET Core 1.0 RTM.

ASP.NET Core Environment Startup Conventions

I'm liking the Config[Environment](IApplicationBuilder app) method for Startup class convention


And I like the Startup[Environment] class convention mentioned here


But I am not sure which one I like more. Some experimentation is called for.

And more research to do on writing my own middleware.


Exploring .NET Core 1.0

After a busy year working on coding up REST services with ASP.NET Web API 2.0 and doing zero blogging, I’m finally taking a little time to explore the .NET Core 1.0 bits released recently in RC2 and watching a number of presentations. I’m very excited about what I’m learning and will blog more about it but here’s a list of links that I’ve found most instructive and useful.

First, the announcement of RC2: announcing-asp-net-core-rc2

Next, the install: https://www.microsoft.com/net 

The unforgettable Scotts at TechEd: Introducing ASP.NET Core 1.0 

And the ASP.NET Core Deep Dive into MVC that followed.

After some experimentation with the preview tooling, trying to figure out how to create a .NET Core class library NuGet package was made easier with this very helpful article: how-to-create-a-nuget-package-with-your-library

And understanding the IIS deployment story was made so much more clear just the other day by the always helpful Rick Strahl: Publishing-and-Running-ASPNET-Core-Applications-with-IIS

Then I went looking for something similar for using Apache as the reverse proxy in front of a Kestrel app and found this: linuxproduction

Which finally led me to clone the KestrelHttpServer.

Exploring the code and the repo has been interesting. I especially noted with interest the recent pull request to Downtarget Kestrel to NETStandard 1.3.

The comment that Kestrel needed no functionality beyond 1.3 and that this allowed greater flexibility with current scenarios was very interesting.

The most important piece of learning so far has been the very brief discussion of the Libuv library used by Kestrel: http://libuv.org/

This amazing little library is used by Node.js and now by the ASP.NET Core web server called Kestrel and according to reports in Microsoft presentations has served up 3.2 million requests per second on a single bare metal machine. Even with a beefy machine, that is impressive.

Seeing how Kestrel uses Libuv is even more interesting and makes me think I ought to explore it as the next engine for a ServiceWire and ServiceMq implementation that could be deployed as a Docker container.

I was especially interested to see how .NET Core 1.0 utilizes native libraries in the Kestrel integration and use of Libuv as a NuGet package: KestrelHttpServer Internal Networking

The runtimes contained in the Libuv package used by Kestrel were also interesting to note:


This concludes about a week of research on the side where I could sneak in an hour or two here or there. I’m eager to keep learning.