ASP.NET Core 3, IIS and empty HTTP headers

HTTP headers are key/value pairs sent at the beginning of a request or response. According to the grammar in RFC 7230, a field could have an empty value. In practice, it probably doesn’t make much sense: semantically, a header with an empty value or the absence of that header are equivalent. However, some client or server implementations actually require that a given header is present, even if it’s empty. For instance, the validation tests for WOPI (an HTTP-based protocol used to integrate Office for the Web with an application) require that the X-WOPI-Lock header is included in the response in certain situations, even if it’s empty (even though the spec says it can be omitted).

Exposing a custom type as a JSON string in an ASP.NET Core API

Sometimes your API needs to expose a non-primitive type that has a “natural” string representation. For instance, a standard representation for a duration is the ISO 8601 format, where “1 month, 2 days, 3 hours and 4 minutes” can be represented as P1M2DT3H4M (note that this isn’t the same as a Timespan, which has no notion of calendar months and years). A duration could be represented in C# as a custom type, like the Duration structure in my Iso8601DurationHelper project.

Git tip: how to fix an accidental commit on the wrong branch

Oh no, you just accidentally commited to master, when you were supposed to work on a feature branch! How to fix it? It’s actually pretty easy with Git! A common Git workflow nowadays is the “feature branch” workflow: you can’t push directly to the “main” branch (usually master, but it can be something else); instead you have to create a branch from master, commit to that branch, publish it and submit a pull request.

Exciting new features in C# 9

Last week at Microsoft Build, there have been a lot of exciting annoucements! .NET 5, Blazor WebAssembly, .NET MAUI, WinUI… But the thing I’m most eager to get my hands on is C# 9, which introduces many interesting new features, so let’s take a quick tour! There’s a long list, so I won’t cover all of them here, but I will highlight the ones I find the most interesting. Note: Unfortunately the new C# features aren’t supported yet in the latest SDK preview, so we can’t test them in actual projects.

Things every C# developer should know #1: hash codes

Created by Wireform from the Noun Project Things every C# developer should know
As a C# developer, there are obviously a lot of skills you need to master to be effective: language syntax, framework classes, third-party libraries, databases, regular expressions, the HTTP protocol, etc. But there are a handful of things that I consider to be really fundamental, and I often see C# developers, even experienced ones, who don’t master them. So, I’m doing a series about those things! Today: hash codes. The GetHashCode method OK, I realize that most developers don’t need to implement their own hash table, or even implement GetHashCode very often, but still, it’s important to know about this.

Moving my blog to Hugo

If you’re a regular reader of my blog, you probably noticed that the design has changed. In fact, it’s not just the design, it’s just about everything! My blog used to be hosted on WordPress. It did the job, but honestly, I didn’t really like WordPress. It’s slow, bloated, and the editing and publishing experience is a bit of a mess (or at least, it’s not a good fit for the way I like to work).

Using the OAuth 2.0 device flow to authenticate users in desktop apps

Over the last few years, OpenID Connect has become one of the most common ways to authenticate users in a web application. But if you want to use it in a desktop application, it can be a little awkward… Authorization code flow OpenID Connect is an authentication layer built on top of OAuth 2.0, which means that you have to use one of the OAuth 2.0 authorization flows. A few years ago, there were basically two possible flows that you could use in a desktop client application to authenticate a user:

Lazily resolving services to fix circular dependencies in .NET Core

The problem with circular dependencies When building an application, good design dictates that you should avoid circular dependencies between your services. A circular dependency is when some components depend on each other, directly or indirectly, e.g. A depends on B which depends on C which depends on A: It is generally agreed that this should be avoided; I won’t go into the details of the conceptual and theoretical reasons, because there are plenty of resources about it on the web.

Handling query string parameters with no value in ASP.NET Core

Query strings are typically made of a sequence of key-value pairs, like ?foo=hello&bar=world…. However, if you look at RFC 3986, you can see that query strings are very loosely specified. It mentions that query components are often used to carry identifying information in the form of “key=value” pairs But it’s just an observation, not a rule (RFCs usually have very specific wording for rules, with words like MUST, SHOULD, etc.

ASP.NET Core: when environments are not enough, use sub-environments!

Out of the box, ASP.NET Core has the concept of “environments”, which allows your app to use different settings based on which environment it’s running in. For instance, you can have Development/Staging/Production environments, each with its own settings file, and a common settings file shared by all environments: appsettings.json: global settings appsettings.Development.json: settings specific to the Development environment appsettings.Staging.json: settings specific to the Staging environment appsettings.Production.json: settings specific to the Production environment With the default configuration, environment-specific settings just override global settings, so you don’t have to specify unchanged settings in every environment if they’re already specified in the global settings file.