Today I was happily migrating some C# projects to Net 5 when I stumbled upon something unexpected. My focus was on a library (a NetStandard2.0 REST API client, an SDK) and its associated test suite. The test project was a NetCore 3.1 application.

As you can imagine, being a REST API client, the library does a lot of talking with a remote Web Service. It does that by leveraging the almightly System.Net.HttpClient. The library has a private, static HttpResponseMessage parser method. Its job is, well, to parse all responses from the remote. It looks for known, expected headers, gracefully handle them, and then deserializes the response content, if there is any.

The test suite has one primary task: to ensure that the SDK can adequately handle the request-response cycle. It does that by mocking a HttpMessageHandler, which is then used by the library HttpClient on every test run.

Until this morning, all 239 tests were passing just fine. Then, I switched the test project’s target framework moniker (TFM) to net5.0. Suddenly, most tests went red.

With no code changes, only a rebuild after the TFM switch, I knew I was up to something weird.

A couple of debug breakpoints later, I was back looking at my little response parser, contemplating the following, rather innocent-looking line:

if (httpResponseMessage.Content == null) return (response, token);

Its purpose is to skip deserialization if there no content in the response. I knew all the failing tests had no response content.

When the caller (the test suite in this case) is a NetCore 3.1 application, it passes a HttpResponseMessage whose Content value is null, as expected. Instead, it appears that when a NET5 application invokes the same method, the HttpResponseMessage.Content carries an obscure EmtpyContent value. Unexpected and, more importantly, undocumented (at least to my knowledge1.)

A not-so-quick investigation revealed that, in fact, sometime during the NET5 development process, the type of HttpResponseMessage.Content has changed from nullable to non-nullable2.

if (httpResponseMessage.Content == null || 
    httpResponseMessage.Content.Headers.ContentLength == 0)
    return response;

The double condition makes sure that no matter the calling moniker, we’ll handle it just fine.

There we go. All tests are green again.

Enjoyed this post? Subscribe to the newsletter or follow @nicolaiarocci on Twitter.

Join the mailing list or subscribe to the RSS feed. Follow me on Mastodon or X.