It seems silly to celebrate features which should have been there from the start. But I can’t help but be excited about adding deterministic build support to the C# and VB compilers. The /deterministic flag causes the compiler to emit the exact same EXE / DLL, byte for byte, when given the same inputs. This is a seemingly minor accomplishment that enables a large number of scenarios around content based caching: build artifact, test results, etc …

Errors are the mechanism by which compilers communicate incorrect program to users. Good error messages educate the user about the issue and ideally tells them how to correct it. This is the optimal situation because it allows users to self correct their code. Bad error messages though typically just state the problem, possibly quite cryptically, without any corrective advice and are little better than the compiler spitting out E_FAIL with a line number.

A reference assembly is a slimmed down version of an implementation assembly that contains the API surface but no real code. A program can reference these assemblies at compile time but cannot run against them. Instead at deploy time programs are paired with the original implementation assembly.

One of my favorite bits of .NET trivia is whether or not it is possible to observe a null value for this? Most developers I ask either say no, or yes but it requires incorrect IL / unsafe code. Since I’m writing this post you can probably guess that the answer is actually yes, this can indeed be null.

Recently I was confused about the interaction between Task and CancellationToken. In particular I couldn’t remember if a Task which was already running was marked cancelled as soon as the associated CancellationToken was cancelled or if it waited until the Task completed. The documentation wasn’t much help so I decided to write up a quick program to test out the behavior: