Thanks to Xamarin, C# developers can use a lot of their existing knowledge even when interacting with native Android (and iOS) APIs. However, some APIs still break the idioms we're used to in .NET. When I recently had to integrate Firebase Cloud Messaging into a Xamarin application, I encountered an asynchronous call that couldn't be awaited. The method even returned a Task. It just wasn't the right Task.
Posts about C#
Interfaces usually have methods that return tasks because they were designed to be asynchronous. But how should you implement such a method when you don't need to call any asynchronous methods inside it?
Immutable objects can't change after they've been created. Because of this, all data needed for their initialization must be passed into them through the constructor. This can result in constructors with (too) many parameters. With the builder design pattern, this can be avoided.
One of the less talked about new features in C# 8 are using declarations. That's not too surprising since it's essentially just syntactic sugar for using statements. However, the exact location in the code where an object is disposed might be different than with using statements. Since other methods might be called implicitly when an object is disposed, this might change the behavior of your code making it incorrect.
In August, I was invited by the organizers of the .NET DeveloperDays conference to have a session about C# 8 in Warsaw at the end of October. After a few exchanges with them and a short consideration, I decided to take on the challenge of speaking at a conference of such size for the first time. As promised at the end of my session there, I'm making the slides and sample code available for download.
This Tuesday, the Slovenian Developers User Group organized the annual meetup with the highest-voted sessions from the NT conference. Unfortunately, the second speaker couldn't make it back to Slovenia in time due to unforeseen circumstances. Since we couldn't find a different speeker on such a short notice my session about C# 8 was the only one at the event.
Yesterday the NT Conference 2019 concluded in Portorož. This year I had three sessions there. On Tuesday, I talked about the new language features in C# 8. On Wednesday, I repeated my session about application architecture from this year's Global Azure Bootcamp. My final session on Thursday was about global tools in .NET Core.
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.
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.