by ·6 Comments

It’s hard to read an intro to .net core without someone also introducing .net standard and then quickly moving on, leaving you to wonder just what is the .net standard. I’ve seen the same questions come up over and over again.  Is it another framework I have to learn? Is it the old .net? Is .net standard and .net core the same? Hopefully we can answer all those questions today!

.net Standard Is Exactly That. A standard.

.net standard is for lack of a better word, a standard. It’s a description of the core interfaces that every .net platform should implement if they wish to say “I support .net Standard 2.0” for example.

An easy way to see what exactly the standard defines is actually the nuget package here : https://www.nuget.org/packages/NETStandard.Library . If you scroll down you will see descriptions of what each standard defines. So for example, .net Standard 1.1 introduces System.Linq. If you would like to use System.Linq, you will need to use a platform that implements .net Standard 1.1.

That brings us to the next point….

What Is A Platform?

It’s may be also good to take a step back and look at what exactly is a platform. At the moment the Microsoft .net platform list looks like .net Framework (Old .net), .net Core, Xamarin, Universal Windows Platform (UWP), Windows Phone and now also Mono.

Each platform version will implement a specific .net standard version. So for example, .net Framework Version 4.6 implements the .net Standard 1.3, whereas .net Core Version 1.0 implements .net Standard 1.6. If I were to write a library that I wanted a developer to use in both .net Framework Version 4.6 and .net Core Version 1.0, then I would have to target the lowest .net Standard that these platforms implement. That being .net Standard 1.3 in this case.

Microsoft have released an easy to view “chart” that tells you which version of each platform implements each version of the standard. You can see it here.

It’s important to note that each platform can implement it’s own features. Windows Phone for example may implement phone specific classes and interfaces, but it will also expose a classes and interfaces of it’s corresponding .net standard.

When Do You Have To Worry About It?

If you are writing for a particular platform, you usually don’t have to worry about .net standard at all. You may at times wish to look up the standard to see what would be coming to your platform next release, but that’s about it.

If you are developing your own library that you wish to be used across multiple platforms, that’s when the .net standard comes in handy. If you write a library that you want working on .net Core, UWP, Windows Phone and .net Framework, you will need to only use classes that are available on all of those platforms. How do you know what classes are available on all platforms? The .net Standard!

What we will likely see in the future from library developers is the requirements changing from “You need .net Framework version 4.6” to, “This is built on top of .net standard 1.6”. And from there you can go and look up what platforms use that standard.

A Web Analogy

Let’s try and think about this in a web sense. It’s not a direct analogy, but we’ll try. Let’s take ECMAScript or Javascript as an example. ECMAScript is a standard. It’s defined in a way that browsers then have to implement. Each browser implements ECMAScript, but they can also do their own things on top (In terms of favourites, addons, plugins etc). This is similar to how a .net platform would work, they implement the standard, but then they can add their own platform specific items on top.

Now if you are writing a website and you wish to use a certain feature of javascript, you have to look at what browsers have implemented that feature. Then you make the decision, either you support “old” browsers, or you only outlay your support for certain modern browsers. This is similar to how it would work if you were writing a .net library. You look at what platforms you wish to support, but if they are old, crusty and are only implementing an old version of the .net Standard, then you can forgo supporting that platform and target a higher standard.

There is one big difference however. Unlike ECMAScript (And other web technologies like CSS), it’s hoped that platforms implement an all or nothing approach when it comes to moving up the .net standard ladder. Either you implement .net Standard 1.5 or 1.6, but you don’t release a platform version that implements 1.5 and a few features from 1.6. Remember, .net Standard is supposed to make it “easy” to determine what classes and interfaces you have available.

Questions?

I’ll admit, I’m still wrapping my head around how .net standard works. But it’s early days yet. You can go to the Microsoft Github and see people still discussing how things should work long term, so it’s not just your everyday developer trying to work it out. If you have any questions feel free to comment below and I’ll do my best to answer.

by ·0 Comments

It’s not like the war of Pascalcase vs Camelcase hasn’t been going on for a very long time, but in ASP.net core it flared up again with a breaking change in ASP.net core 1.0. You can read the actual change request here on Github, and then the subsequent announcement with some unhappy campers here.

To be clear.

In earlier versions of Web API and indeed early versions of ASP.net core, the default serialization of an object to JSON results in Pascalcase names. When a C# app is talking to another C# app, the casing actually doesn’t matter. You can send JSON data with mYVaRiAbLE and it will still be deserialized into MyVariable in C#.

The issue usually reared it’s head when you were using javascript to consume your Web API. Afterall, when Mozilla, Google, jQuery, WordPress and countless others cite camelCase as the standard for Javascript naming, it’s probably what most people expect to see. If you are binding a model using Angular or similar from a Web API, you probably want to keep with the same naming format. Not have properties that came from your API suddenly be in Pascal Case.

It mostly comes down to the 80/20 rule. I would say a large majority of people using ASP.net core are also using some sort of javascript framework to bind models. And for that, camelCase is best.

So, what are your options if you are still #TeamPascalCase?

Change To PascalCase In ASP.net Core 1.0+

Probably the most annoying thing about this change is that you need to change the ContractResolver for the Json Serializer. The thing that gets people’s goat is that the resolver that makes things PascalCase is actually called the “DefaultContractResolver”…. Even though in version 1.0 and onwards it isn’t the default at all…..

In anycase, in your startup.cs file, find your ConfigureServices method. You should already have an AddMVC call, and tack onto it like so :

Change To camelCase In ASP.net Core <1.0

Just incase you are behind with the times in ASP.net Core versions and you want to move to camelCase by default (Possibly in preparation for upgrading), you can do so by doing similar to the above, but instead making the contract resolver camel case like so :

by ·0 Comments

So you’ve heard about ASP.net Core and you’re considering the move, but you want to know if it’s really worth it. You will always have to weigh up the pros and cons, especially if you are intending to move an existing app into .net core. But here’s 5 reasons you should definitely consider ASP.net core for your next project.

It’s A Small Learning Curve

Yes it’s true that there is a learning curve when learning .net core, even if you’re a seasoned ASP.net developer, but it’s not as big as you might think. For example, the language is still C#, namespaces are often the same or have been lifted and shifted to an easy location, and many classes/pieces of code you already have are usually able to be moved without too much hassle.

With that being said, there are a few notable exceptions. Things like cryptography services have either been severely changed. In some cases classes like the FTPWebRequest have been completely removed, much to the annoyance of some (Although should be added back in the future). If you are doing a small test application in .net core or have full embraced microservices, you will quickly be able to validate if .net core has everything you need. If you are attempting to port a massive monolith, it might be worthwhile researching into the few things .net core is currently lacking before setting off.

Multi Platform

Usually seen as the number one reason to make the switch. ASP.net Core is able to be run (And developed) on Windows, Mac and Linux. While Visual Studio is still Windows only, VS Code and Jetbrains Rider are available on all OS to develop .net core solutions. Your devops team will no doubt love you with the ability to now deploy the code on cheaper (And to some people, more reliable) Linux machines too!

It’s not like you are left on your own to work it out either. Microsoft has published documentation on getting ASP.net core running on Ubuntu, documentation on getting ASP.net core running on Apache with CentOS, and even how to get everything up and running on Docker. Imagine that happening just 5 years ago!

One Web Framework To Learn

In previous versions of ASP.net you had a difference between MVC controllers and API controllers. It seemed simple enough, but you then ended up with different ways to configure your web app. You could be half way through a ModelBinding tutorial before you realized it was for MVC only and you had to do something slightly different to get it working in the API. It was super frustrating! But in .net Core, It is all one and the same. One action can return JSON data, one can return an ActionResult, all in the same controller!

It’s Light

Previously you had to have the .net framework installed on your target machine when deploying. Not anymore! When deploying .net applications you can package up everything your app needs into a single zip and deploy only that. That means that your only shifting exactly what you need, as well as reducing the complexity of a machine setup if you are doing horizontal scaling.

It’s Fast

While the results are somewhat disputed on how “useful” and “real world” they are. The current benchmarks of ASP.net core’s web server (Kestrel), can currently serve over 1.2 million requests per second. For comparison in that benchmark, standard IIS can server around around 60k per second. These are plaintext benchmarks so it’s not running actual .net core code, but it’s still interesting to see the huge improvement in web server performance.