Enabling Command Line Completions with dotnet-suggest
I recently removed the hand-written command line parser from C# REPL and replaced it with the more standard System.CommandLine NuGet package. As part of this, it gained dotnet-suggest support. I couldn’t find much online discussion about dotnet-suggest, so I’m jotting down some notes here.
There are two parts to dotnet-suggest:
As an end-user, we configure our shell to enable dotnet-suggest shell completions.
As a developer, we use System.CommandLine to provide rich completions to our end users.
We’ll be covering both parts in this blog post, as well as how it all works under the hood. At the end, we’ll look at an interesting way all this functionality is …continue.
I’ve been building an open-source personal project (C# REPL) and spending a good chunk of time on code quality. I self-impose a zero-warning policy, use nullable reference types, track unit test coverage, etc.
After ensuring all the Visual Studio / Roslyn code analyzer warnings were fixed, I thought I’d try out NDepend to get a second opinion, and also understand its capabilities. After downloading a free trial of NDepend and spending some time with it, I was pretty impressed with its technical underpinnings as they’re exposed to the end user. Spoilers: It’s LINQ all the way down.
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 22.214.171.124 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 …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 …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 …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 …continue.