Since this week, The Absolutely Awesome Book on C# and .NET is finally available for order in its final form: in all eBook formats and with the accompanying source code.
Posts about C#
Although I could say that I understand covariance and contravariance, I still need to pause for a moment and think it over whenever I have to deal with them. It all gets even more complicated if generic type arguments aren't directly in the role of an input parameter or a return value.
Tuples, as added to C# 7, can be a nice alternative to anonymous types in LINQ when you only want to return a subset of values from the queried type. Before tuples, this was only possible by creating an anonymous type in the Select method. Now you can create a tuple instead. However, if you try to do that with EF Core, the code won't compile. How come?
Interpolated strings in C# 6 introduced a simplified syntax for most use cases of String.Format. The new syntax has several immediate advantages, but its internal implementation also lends itself to some innovative usage. In EF Core 2.0, interpolated strings can be used to write safe SQL queries with shorter syntax. Let's take a look at how this is implemented.
There's a lot of flexibility in type conversions in C#. On top of built-in implicit and explicit conversions, you can also define custom conversions. However, you might not be aware that these are not supported for interfaces.
It's the week of NT Conference 2018. I had two sessions this year. On Tuesday, I talked about a selection of common C# gotchas which can surprise even an experienced C# developer. In my second session, I explained the benefits of continuous testing and showed how to configure it for a .NET Core project in Visual Studio 2017 and Visual Studio Code.
For the second year in a row, I spent a significant amount of time in December solving the Advent of Code programming puzzles. Before writing the first line of code, I created a repository for my solutions. Unlike last year, I wanted to have all the code readily available for future reference. More than once, I actually looked up previous solutions while solving a more recent puzzle.
This week the second community organized Cancel conference was taking place in Ljubljana. It spanned over two days. Thursday was the main conference day with 20 sessions grouped in 4 tracks. On Wednesday afternoon preconf was organized at the premises of Microsoft Slovenia. I had my sessions on both days.
It's May again, which means the annual NT Conference was taking place in Portorož at the beginning of this week. This year I had two sessions scheduled, the first one on Monday and the second one on Tuesday.
Are you used to the fact that strings are null-terminated? Well, in .NET framework they are not. In this article I explore the consequences of that, explain the circumstances under which you might stumble across it, and suggest, how to avoid being affected by it.
Under what circumstances can a static field be initialized multiple times? C# language specification makes it pretty clear that static fields are initialized only once, before the class is first used. This meant, it was time for some creative thinking, when I encountered an issue, seemingly caused by the static field being initialized multiple times.
This year I had 2 sessions of my own at NT conference: What's New in C# 6 and Diagnostic analyzers in Visual Studio 2015. Slides and demos for both them are available for download.
On Tuesday Microsoft Slovenia organized the second TechDays event leading up to the 20th NT conference. The event consisted of 4 tracks; I had the opening session for the Visual Studio 2015 track. As always slides and demos from my session are available for download.
According to the C# language specification, the static field initializer should execute before it is accessed for the first time. As it seems, looking up the field value in debugger doesn't trigger the initializer.
Static code analysis is a very useful feature of ReSharper. The generated warnings can help you fix bugs which might otherwise remain unnoticed. Unfortunately static analysis is not perfect and it might detect false positives. There are a couple of ways to tell it not to warn us about specific ones any more.
No matter how well versed you with C#, the book will teach you something new about it or at least remind you about the stuff you already know without being consciously aware of it. Since the author lets you choose the price for the book, you'll certainly get your money's worth from it.
I can sincerely recommend the book to anyone, trying to get a glimpse into the world of game development. It can really only serve as the first step on the path to becoming a game developer, but it's definitely enough to see if that's something for you and worth exploring further.
The compiler does not remove static methods when calling through an instance because it does not necessarily know that you are calling through an instance. Because there are situations where it is ambiguous whether you're calling through an instance or a type, it defers deciding which you meant until the best method has been selected.
Recently the abstract override language construct has been brought to my attention. Knowing about both keywords, there isn't much doubt what it means to the compiler. The combination of both keywords can only be used in two cases.
While reading an article on the difference between const and readonly it surprised me that changes to public consts in the referenced assembly don't affect the referencing assembly unless it is recompiled using the changed referenced assembly. The C# Reference doesn't hint at such behavior at all, which means it's time for further exploration.
For anybody else like me out there who hasn't done more than an occasional DllImport call or two, the following resources should help getting to grips with the PInvoke basics.
No matter what you're doing in the static constructor, never allow it to throw an exception unless the problem is indeed fatal and you intend to quit the program immediately. In all other cases provide reasonable defaults and handle changed circumstances elsewhere in the code.