What is a Binary Breaking Change?
And why you should use properties instead of public fields
Fields and properties
You’ve probably always been told that you should use a public property instead of a public field, right?
The reason is that a property can provide functionality to control what values are set, eg. you may have a field of type Int32 called NumberOfUsers and want to make sure the value set is >= 0, this logic can be set up in a property but not in a field.
But most of the time you don’t have any logic like this, you just have an auto property with a get/set and no logic, isn’t this just as good as having a field?
If you one day need logic to control what value is set, couldn’t you just change the public field to a property?
Binary breaking change
You could just change a field to a property. However, if your code was used as a class library by other developers, you would introduce a binary breaking change. We’ll find out what this means in a moment.
Example project
Let’s set up an example project to see what’s going on behind the scenes when we change a field to a property.
The class library
Create a very simple .NET class library project that looks like this, and compile it:
Here is the CIL that gets generated:
As you would expect, the compiler generated a string field called SomeString.
The calling code
Set up the following console app project that accesses the field from the SomeClass library and writes it to the console.
Get David Klempfner’s stories in your inbox
Join Medium for free to get updates from this writer.
You’ll need to add a reference to your SomeClassLibrary dll which should be located in the SomeClassLibrary\bin\Debug folder.
Take note of the generated CIL:
Running the console app
Navigate to CallingLibrary\bin\Debug and double click on CallingLibrary.exe to run the app:
The breaking change
Now let’s change the field in SomeClass to a property.
Here’s the new CIL code. Notice that behind the scenes, a backing field and two methods are created, one for get and one for set.
Now copy over your SomeClassLibrary dll to your console app’s debug folder:
Now navigate to CallingLibrary\bin\Debug and double click on CallingLibrary.exe to run the app:
It can’t find the field! The C# code is fine, because accessing a field is the same syntax as accessing a property. However as you’ve seen above, the CIL code is very different and uses methods behind the scenes.
This is the breaking change I was talking about, your source code is compatible but your CIL is incompatible with the new dll.
The fix
To fix this, you just need to recompile your console app so that it generates the right calls to the property in CIL.
Go ahead and compile your console app and take a look at the new CIL code:
As you can see the new CIL code correctly calls the get/set methods from SomeClass rather than trying to access the field.
Conclusion
I hope you now have a better understanding of what a binary breaking change is, and why it’s better to use public properties instead of fields.
This is only really an issue if you’re creating class libraries and you want your consumers to be able to overwrite the old dll without having to recompile.
Source and binary compatible change
You might be wondering if there is ever a situation where you could change the code and not have to tell your consumers to recompile. This is known as a source and binary compatible change.
An example would be if you changed the implementation of a public method, but left the method signature untouched. This changes your source code so you will need to provide your new dll, however because the public interface to your method didn’t change, only the implementation did, your users are able to copy over the new dll without having to recompile!
Reasons to use properties
There are other reasons to use properties instead of fields. Properties are needed for data binding, and you can put a breakpoint in a setter to track when the value changes, that’s not possible with a field.
