A Lesser-Known C# Feature: Nested Object Initializers
I’ve been writing C# for quite some time now, but only recently found out about the "nested object initializers" syntax in C#. Nested object initializers elegantly solve problems for which I’ve previously used workarounds. It’s not a new feature; it was introduced in C# 3.0, under section 18.104.22.168 of the language specification:
An object initializer after the equals sign is a nested object initializer, i.e. an initialization of an embedded object. Instead of assigning a new value to the field or property, the assignments in the nested object initializer are treated as assignments to members of the field or property.
Microsoft Build 2020 – Highlights for .NET Developers
Over the course of the last three days, Microsoft Build 2020 released a flood of news and announcements.
For those of us who follow the .NET ecosystem, it can be difficult to wade through them all!
I’ve collected a list of announcements that I think are interesting as a .NET developer, and added short
summaries. The announcements are grouped into four categories: ASP.NET, .NET, Visual Studio and Windows.
In addition, each category is split into "released" (you can use it now!) or "preview / announced"
(you can test it out now, or soon).
A couple of days ago, Blazor WebAssembly 3.2.0 Preview 1 was released (announcement). I’m personally excited about this release
because it’s the first Blazor release that contains native support for client-side websockets!
Previously, if you wanted to use websockets, you either had to write your own wrapper, or use a larger library like
SignalR that did the wrapping for you. However, if you just wanted to use the normal System.Net.WebSockets.ClientWebSocket class that’s built into .NET, you could not.
The Mono/WASM project has actually supported ClientWebSocket for about a year (PR 12615). However, some recent changes in Blazor allowed the Blazor project to be able to consume …continue.
I was invited to speak, and I covered the new features in C# 8.0. There are a ton!
Nullable Reference Types
Indices and Ranges
Default Interface Members
Static Local Functions
Null Coallescing Assignment
I have my presentation slides and code available on GitHub.
You can see my talk on the dotnetconf page, however the audio volume is too soft to hear. Oh well! You can get
similar content by watching Mads Torgersen’s talk (Part 1) and Bill Wagner’s talk (Part 2).
If you’ve developed .NET for any length of time, chances are you’ve run into a gnarly error like this:
System.IO.FileLoadException: Could not load file or assembly ‘AcmeCorp.Foobar.Utilities, Version=1.2.0, Culture=neutral, PublicKeyToken=367d582291c765f7’ or one of its dependencies.
The located assembly’s manifest definition does not match the assembly reference.
It’s a pretty puzzling error. It means that it found version 1.2.0 of a DLL, but did not use it because a different version was requested (e.g. 1.3.0).
There are a couple of gotchas when troubleshooting these types of errors.
Ensure you don’t have any version mismatches
As a first step, ensure that all projects in your solution reference the same version of the problematic …continue.
CoreRT is an ahead-of-time (AOT) compiler and runtime for .NET Core. It builds .NET Core applications into a single, small binary that runs without requiring .NET Core to be installed on the system. This makes distribution easy, especially to Mac OS and Linux, which may not have .NET Core installed. On all platforms, the program will have a faster start-up time and lower memory footprint.
Like most developers, I have a pet static site generator I’m working on. As it’s a command line utility that will be distributed to users that most likely won’t have .NET Core installed, I decided to try …continue.
I’m currently going through my "build a static site engine" phase that most developers pass
through at some point in their career. As part of this, I wanted to write a normal ASP.NET
Core application complete with server-side rendering, and then have the option to entirely
pre-render it to disk.
It turns out that this is quite difficult – StackOverflow and GitHub issues were a barren
wasteland of half-working answers. Most everyone assumes that you have a ControllerContext,
or at least an HttpContext! Rendering it from a command line application was unheard of!
After much experimentation, I managed to get it working! You can see a complete example in
I’ve recently been working with a lot of PowerShell at work, and the experience has been, well, less than perfect. PowerShell is a dynamically-typed scripting language, and is most often used for administering Windows systems. The combination of making system changes and the runtime errors associated with dynamically-typed languages has been frustrating. It’s quite common to get the system into a weird or inconsistent state when developing PowerShell scripts.
Ideally all your PowerShell is properly orchestrated with -WhatIf and SupportsShouldProcess functionality, but in my experience it’s common for there to be large differences in behavior between -WhatIf execution and real execution.
If you’re like me, you installed Visual Studio, installed VsVim, and then happily started coding. However, did you know that Visual Studio’s semantic understanding and manipulation of your code is exposed to VsVim?
For example, you might already know that pressing gd in VsVim will "go to the definition" of a method. But what if we want to "go to the implementation" e.g. through an interface to the underlying concrete method? The standard Ctrl-F12 requires some contortions, and maybe requires glancing down at your keyboard.
It’s easy to fix this; just add this mapping to your ~\_vsvimrc: