There is a current proposal that’s getting traction (By some) to make it into C# 8. That’s “default interface methods”. Because at the time of writing, C# 8 is not out, nor has this new language feature even “definitely” made it into that release, this will be more about the proposal and my two cents on it rather than any specific tutorial on using them.

What Are Default Interface Methods?

Before I start, it’s probably worth reading the summary of the proposal on Github here : https://github.com/dotnet/csharplang/issues/288. It’s important to remember is that this is just a proposal so not everything described will actually be implemented (Or implemented in the way it’s initially being described). Take everything with a grain of salt.

The general idea is that an interface can provide a method body. So :

interface IMyService
{
    string HelloWorld() { return "Hello World"; }
}

A class that implements this interface does not have to implement methods where a body has been provided. So for example :

class MyService : IMyService
{
    // Absolutely no body required.
}
....

IMyService myService = new MyService();
var helloWorld = myService.HelloWorld(); //Returns the string "Hello World"

The interesting thing is that the class itself does not have the ability to run methods that have been defined and implemented on an interface. So :

MyService myService = new MyService();
var helloWorld = myService.HelloWorld(); //Error
....
//But if we cast to the interface we are good to go
var helloWorld2 = ((IMyService)myService).HelloWorld();

The general idea is that this will now allow you to do some sort of multiple inheritance of behaviour/methods (Which was previously unavailable in C#).

interface IMySecondInterface
{
    string HelloWorld { return "Hello World 2";}
}

class MyService : IMyService, IMySecondInterface
{
}
.....
var myService = new MyService();
var helloWorld = ((IMyService)myService).HelloWorld(); // Returns Hello World
helloWorld = ((IMySecondInterface)myService).HelloWorld(); // Return Hello World 2

There are a few other things that then are required (Or need to become viable) when opening this up. For example allowing private level methods with a body inside an interface (To share code between default implementations).

Abstract Classes vs Default Interface Methods

While it does start to blur the lines a bit, there are still some pretty solid differences. The best quote I heard about it was :

Interfaces define behaviour, classes define state.

And that does make some sense. Interfaces still can’t define a constructor, so if you want to share constructor logic, you will need to use an abstract/base class. An interface also cannot define class level variables/fields.

Classes also have the ability to define accessibility of it’s members (For example making a method protected), whereas with an interface everything is public. Although part of the proposal is extending interfaces with things like the static keyword and protected, internal etc (I really don’t agree with this).

Because the methods themselves are only available when you cast back to the interface, I can’t really see it being a drop in replacement for abstract classes (yet), but it does blur the lines just enough to ask the question.

My Two Cents

This feels like one of those things that just “feels” wrong. And that’s always a hard place to start because it’s never going to be black and white. I feel like interfaces are a very “simple” concept in C# and this complicates things in ways which I don’t see a huge benefit. It reminds me a bit of the proposal of “Primary Constructors” that was going to make it into C# 6 (See more here : http://www.alteridem.net/2014/09/08/c-6-0-primary-constructors/). Thankfully that got dumped but it was bolting on a feature that I’m not sure anyone was really clamoring for.

But then again, there are some merits to the conversation. One “problem” with interfaces is that you have to implement every single member. This can at times lock down any ability to extend the interface because you will immediately blow up any class that has already inherited that interface (Or it means your class becomes littered with throw new NotImplementedException() ).

There’s even times when you implement an interface for the first time, and you have to pump out 20 or so method implementations that are almost boilerplate in content. A good example given in the proposal is that of IEnumerable. Each time you implement this you are required to get RSI on your fingers by implementing every detail. Where if there was default implementations, there might be only a couple of methods that you truly want to make your own, and the default implementations do the job just fine for everything else.

All in all, I feel like the proposal should be broken down and simplified. It’s almost like an American political bill in that there seems to be a lot in there that’s causing a bit of noise (allowing static, protected members on interfaces etc). It needs to be simplified down and just keep the conversation on method bodies in interfaces and see how it works out because it’s probably a conversation worth having.

What do you think? Drop a comment below.

I’ve recently been playing around with all of the new features packaged into C# 7.2. One such feature that piqued my interest because of it’s simplicity was the “in” keyword. It’s one of those things that you can get away with never using in your day to day work, but makes complete sense when looking at language design from a high level.

In simple terms, the in  keyword specifies that you are passing a parameter by reference, but also that you will not modify the value inside a method. For example :

public static int Add(in int number1, in int number2)
{
	return number1 + number2;
}

In this example we pass in two parameters essentially by reference, but we also specify that they will not be modified within the method. If we try and do something like the following :

public static int Add(in int number1, in int number2)
{
	number1 = 5;
	return number1 + number2;
}

We get a compile time error:

Cannot assign to variable 'in int' because it is a readonly variable

Accessing C# 7.2 Features

I think I should just quickly note how to actually access C# 7.2 features as they may not be immediately available on your machine. The first step is to ensure that Visual Studio is up to date on your machine. If you are able to compile C# 7.2 code, but intellisense is acting up and not recognizing new features, 99% of the time you just need to update Visual Studio.

Once updated, inside the csproj of your project, add in the following :

<PropertyGroup>
	<LangVersion>7.2</LangVersion>
</PropertyGroup>

And you are done!

Performance

When passing value types into a method, normally this would be copied to a new memory location and you would have a clone of the value passed into a method. When using the in  keyword, you will be passing the same reference into a method instead of having to create a copy. While the performance benefit may be small in simple business applications, in a tight loop this could easily add up.

But just how much performance gain are we going to see? I could take some really smart people’s word for it, or I could do a little bit of benchmarking. I’m going to use BenchmarkDotNet (Guide here) to compare performance when passing a value type into a method normally, or as an in  parameter.

The benchmarking code is :

public struct Input
{
	public decimal Number1;
	public decimal Number2;
}

public class InBenchmarking
{
	const int loops = 50000000;
	Input inputInstance;

	public InBenchmarking()
	{
		inputInstance = new Input
		{
		};
	}

	[Benchmark]
	public decimal DoSomethingInLoop()
	{
		decimal result = 0M;
		for (int i = 0; i < loops; i++)
		{
			result = DoSomethingIn(in inputInstance);
		}
		return result;
	}

	[Benchmark(Baseline = true)]
	public decimal DoSomethingLoop()
	{
		decimal result = 0M;
		for (int i = 0; i < loops; i++)
		{
			result = DoSomething(inputInstance);
		}
		return result;
	}

	public decimal DoSomething(Input input)
	{
		return input.Number1;
	}

	public decimal DoSomethingIn(in Input input)
	{
		return input.Number1;
	}

	public decimal DoSomethingRef(ref Input input)
	{
		return input.Number1;
	}
}

And the results :

            Method |     Mean |     Error |    StdDev | Scaled | ScaledSD |
------------------ |---------:|----------:|----------:|-------:|---------:|
 DoSomethingInLoop | 20.89 ms | 0.4177 ms | 0.7845 ms |   0.34 |     0.02 |
   DoSomethingLoop | 62.06 ms | 1.5826 ms | 2.6003 ms |   1.00 |     0.00 |

We can definitely see the speed difference here. This makes sense because really all we are doing is passing in a variable and doing nothing else. It has to be said that I can’t see the in  keyword being used to optimize code in everyday business applications, but there is definitely something there for time critical applications such as large scale number crunchers.

Explicit In Design

While the performance benefits are OK something else that comes to mind is that when you use in  is that you are being explicit in your design. By that I mean that you are laying out exactly how you intend the application to function. “If I pass this a variable into this method, I don’t expect the variable to change”. I can see this being a bigger benefit to large business applications than any small performance gain.

A way to look at it is how we use things like private  and readonly . Our code will generally work if we just make everything public  and move on, but it’s not seen as “good” programming habits. We use things like readonly  to explicitly say how we expect things to run (We don’t expect this variable to be modified outside of the constructor etc). And I can definitely see in  being used in a similar sort of way.

Comparisons To “ref” (and “out”)

A comparison could be made to the ref keyword in C# (And possibly to a lesser extend the out keyword). The main differences are :

in  – Passes a variable in to a method by reference. Cannot be set inside the method.
ref  – Passes a variable into a method by reference. Can be set/changed inside the method.
out  – Only used for output from a method. Can (and must) be set inside the method.

So it certainly looks like the ref keyword is almost the same as in, except that it allows a variable to change it’s value. But to check that, let’s run our performance test from earlier but instead add in a ref scenario.

             Method |     Mean |     Error |    StdDev | Scaled | ScaledSD |
------------------- |---------:|----------:|----------:|-------:|---------:|
  DoSomethingInLoop | 23.26 ms | 0.6591 ms | 1.0643 ms |   0.61 |     0.04 |
 DoSomethingRefLoop | 21.10 ms | 0.3985 ms | 0.4092 ms |   0.41 |     0.02 |
    DoSomethingLoop | 51.36 ms | 1.0188 ms | 2.5372 ms |   1.00 |     0.00 |

So it’s close when it comes to performance benchmarking. However again, in  is still more explicit than ref because it tells the developer that while it’s allowing a variable to be passed in by reference, it’s not going to change the value at all.

Important Performance Notes For In

While writing the performance tests for this post, I kept running into instances where using in  gave absolutely no performance benefit whatsoever compared to passing by value. I was pulling my hair out trying to understand exactly what was going on.

It wasn’t until I took a step back and thought about how in  could work under the hood, coupled with a stackoverflow question or two later that I had the nut cracked. Consider the following code :

struct MyStruct
{
	public int MyValue { get; set; }

	public void UpdateMyValue(int value)
	{
		MyValue = value;
	}
}

class Program
{
	static void Main(string[] args)
	{
		MyStruct myStruct = new MyStruct();
		myStruct.UpdateMyValue(1);
		UpdateMyValue(myStruct);
		Console.WriteLine(myStruct.MyValue);
		Console.ReadLine();
	}

	static void UpdateMyValue(in MyStruct myStruct)
	{
		myStruct.UpdateMyValue(5);
	}
}

What will the output be? If you guessed 1. You would be correct! So what’s going on here? We definitely told our struct to set it’s value to 1, then we passed it by reference via the in keyword to another method, and that told the struct to update it’s value to 5. And everything compiled and ran happily so we should be good right? We should see the output as 5 surely?

The problem is, C# has no way of knowing when it calls a method (or a getter) on a struct whether that will also modify the values/state of it. What it instead does is create what’s called a “defensive copy”. When you run a method/getter on a struct, it creates a clone of the struct that was passed in and runs the method instead on the clone. This means that the original copy stays exactly the same as it was passed in, and the caller can still count on the value it passed in not being modified.

Now where this creates a bit of a jam is that if we are cloning the struct (Even as a defensive copy), then the performance gain is lost. We still get the design time niceness of knowing that what we pass in won’t be modified, but at the end of the day we may aswell passed in by value when it comes to performance. You’ll see in my tests, I used plain old variables to avoid this issue. If you are not using structs at all and instead using plain value types, you avoid this issue altogether.

To me I think this could crop up in the future as a bit of a problem. A method may inadvertently run a method that modifies the structs state, and now it’s running off “different” data than what the caller is expecting. I also question how this will work in multi-threaded scenarios. What if the caller goes away and modified the struct, expecting the method to get the updated value, but it’s created a defensive clone? Plenty to ponder (And code out to test in the future).

Summary

So will there be a huge awakening of using the in keyword in C#? I’m not sure. When Expression-bodied Members (EBD) came along I didn’t think too much of them but they are used in almost every piece of C# code these days. But unlike EBD, the in  keyword doesn’t save typing or having to type cruft, so it could just be resigned to one of those “best practices” lists. Most of all I’m interested in how in  transforms over future versions of C# (Because I really think it has to).   What do you think?

With the release of .NET Core 2.0 comes a large “meta package” with the name Microsoft.AspNetCore.All. It’s a sort of god mode package that contains all you need to get up and running on ASP.net Core without having to figure out which nuget package does what. But it does have some massive pitfalls in my opinion.

Why Have A Meta Package At All?

When ASP.net Core is split into multiple smaller packages, the “versions” of these packages start to get all out of sync over time. This is especially true if you have ever tried to upgrade a project between .NET core versions, you end up having to go through all your smaller AspNetCore packages and work out which ones you should be version bumping. Take the following for example :

<PackageReference Include="Microsoft.AspNetCore" Version="1.0.4" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.0.3" />
<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="1.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="1.0.3" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="1.0.3" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer.Design" Version="1.0.3" />

Here you have many aspnetcore and EntityFramework packages that all have slightly off versions. In ASP.net Core 2.0, using the “Microsoft.AspNetCore.All” meta package, your package references instead look like this :

<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />

What this should mean is that by updating a single package, you will be able to run on the latest ASP.net Core version. It also makes your csproj a bit easier on the eye with a single package being your “framework”, and any other package references being ones you have added explicitly.

What’s Inside The Microsoft.AspNetCore.All package

The meta package contains :

• Every single AspNetCore package published by Microsoft
• Every EntityFrameworkCore package published by Microsoft
• Any supporting packages required for the framework to run (For example Json.Net)

Now, that probably sounds huge and you will probably ask yourself,  won’t the resulting deployment be out of control? You would essentially be “shipping” the entire framework right? Well..

Deployment and Runtime Store

Microsoft have gone back to something called the “Runtime Store“. I say the words “gone back” because this functions almost the same as the GAC on .net Full Framework projects. That is, your target machine would have to have the .NET Core runtime installed on it for you to be able to use the aspnetcore meta package. When you deploy, you won’t actually deploy any of the framework packages, your code will instead utilize the ones already on the machine.

And if the machine doesn’t have the runtime installed? Well, that’s where things start to fall down. If you are looking to do self contained deployments (Which was a massive selling point of .NET Core), then you cannot use the meta package. You would need to reference packages manually. I can see how this could turn into a headache down the road because it makes the creation of the project and whether you use the meta package so important. Imagine getting to the point you are ready to deploy, and your dev ops team prefers going down a self contained deployment route. Now you will have to go back and work out which packages you are using from the meta and add them all in manually. Painful!

Getting Started

By default, when you create any project using ASP.net Core 2.0, you will be using the meta package. If you know you won’t be using self contained deployments any time soon, then it’s safe to go ahead and use, and really, it does alleviate some headaches of knowing which packages have what. I can’t tell you how many times I start a new project and I have to go back and manually add in the packages for authentication, entityframework, staticfiles etc. Give it a go and let me know what you think below!

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.

MyVariable <- PascalCase
myVariable <- camelCase

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 :

public void ConfigureServices(IServiceCollection services)
{
	services.AddMvc()
		.AddJsonOptions(options => options.SerializerSettings.ContractResolver = new DefaultContractResolver());
}

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 :

public void ConfigureServices(IServiceCollection services)
{
	services.AddMvc()
		.AddJsonOptions(options => options.SerializerSettings.ContractResolver = new CamelCasePropertyNamesContractResolver());
}