windows-1252 encoding in Italian e-invoices has been a persistent headache — it’s technically outside the FatturaPA spec (which mandates UTF-8), but it crops up often enough in real-world invoices from older or misconfigured billing systems that users kept running into it. The Invoicetronic stack has been updated accordingly.

Attending WPC is always exciting. The audience is large, the rooms are big and well-equipped, the energy is just right, and there’s always a chance to catch up with friends and colleagues. I especially enjoy seeing fellow Microsoft MVPs and speakers.

As promised, here is a link to the repository with the code I demonstrated; just read the README to get your bearings. Oh, and as expected, someone in the audience got nerd-sniped by that cj bash function I mentioned.

The fine guys at ASP Italia just published the video in case someone is interested.

Yeah, it is in Italian. I got a transcript from MacWhisper and then asked Claude to translate and clean it up. It did a pretty good job, so let me know if there’s any interest in an English transcript; I might post it here.

Speaking of English, I’ve started submitting to international events again, without any luck so far. The conference landscape has changed quite a bit, especially since the COVID break. I still get invited to local ones, while internationals have been elusive. I suspect my change in technology stack plays a role. It was relatively easy to speak abroad when I was into Python. With .NET, not so much. But again, I was into Python in the pre-COVID era, so it is hard to tell which factors are at play and what their weight is.

“For decades, garbage collection in .NET was a background concern. It was mostly invisible to the everyday developer and was regarded as ‘automatic’ unless (or until) something slowed down the application. However, .NET 10 changes this perspective by making garbage collection (GC) a key component of application performance.”

What .NET 10 GC Changes Mean for Developers is a good in-depth article that explores the revolutionary garbage collection improvements in .NET 10, which deliver 2- 3x performance gains through seven key enhancements: escape analysis for stack allocation, DATAS enabled by default, flexible region sizing, delegate optimizations, intelligent write barrier elimination, enhanced devirtualization, and refined heap controls for containers.

After removing the BouncyCastle dependency (v3.4.16) for signature, content extraction, and encoding purposes, a few minor behavioral changes were introduced in the library.

1. It was previously possible to extract content from documents with tampered signatures (if signature validation was flagged false)
2. Signature exceptions were being misreported as Base64 FormatExceptions for non-base64 input files

After a lengthy analysis and troubleshooting, it was determined that System.Cryptography (which now replaces BouncyCastle) cannot support the successful decoding of tampered invoices. However, this is undesirable as a feature in the first place. The result is a breaking change: attempting to read tampered documents will now invariably throw SignatureException.

Many thanks to Paolo Manili, aka Delta-38, for contributing this remarkable update.

The Fattura Elettronica open-source project allows for the validation and de/serialization of electronic invoices that adhere to the standard defined by the Italian Revenue Agency.

Exactly one year ago we were here, in this same room, at the same conference, presenting C# 12. Some of you in the audience were present back then. If so, please raise your hands. Twelve months later, here we are again, looking at a new version of C#. It’s the new normal; this has been happening, give or take, since the advent of .NET Core and C# 8 in 2019. Previously, C# had a new release every 2–3 years, so the release rate has doubled or even tripled recently. Is this good news? If you’ve followed forums or social media, you might have noticed some controversy about the topic. The main complaint is that the language is changing too quickly, “chasing trends,” with no valuable addition to its core.

Most of these complaints come from old-timers around my age (maybe even ten years younger because I’m seasoned) and have been in the .NET environment for many, perhaps too many years. There’s always a certain inertia, a form of resistance to change, especially when it’s rapid. But I’m seasoned enough to remember when complaints went in the opposite direction: back then, the .NET Framework (the historical, monolithic, Windows-only version) moved like a dinosaur while the world was racing ahead. New languages were blooming. Old competitors were evolving at double or triple the speed, constantly innovating, and—this is key—attracting hordes of developers. There was a critical moment when this attraction became so intense that more and more developers set aside .NET and C# to explore new directions. I know because I was one of them.

Around 2010–11, I was set to create a new, rather complex platform of REST services, and instead of reaching out for my usual .NET toolchain, I chose Python. That marked the beginning of an adventure that lasted years and included the unexpected release of some reasonably successful open-source Python projects. The reasons I decided to abandon .NET and C# were several—not least the frustration with the lack of transparency and a clear path for the .NET ecosystem, its languages, with oh-so-many frameworks enthusiastically presented and then abandoned, changes of direction, and above all, in my case, it all being closed source, which didn’t allow me to dig deeper and understand why certain things didn’t work as expected. I clearly remember when I was writing my first REST service in Python and realized that in this new ecosystem if I didn’t understand what was happening behind the scenes (in my case, with the Flask framework), I could quickly look at what was going on because the entire Flask source code, like Python’s for that matter, was available not only for consumption but it was also open to contribution. Coming from the enterprise closed-source world, it was an empowering sensation.

The discovery of Flask was an absolute revelation, not for its intrinsic features (which were great) but because it was just one of the many options. In Python space, there were dozens of web frameworks at varying stages of maturity. There was a choice and often many different approaches to solve the same problem. I could experiment freely and decide what was best for my use case. Not only was I facing a vast and diverse world, but I could also use the operating system I wanted. Linux was much less demanding, let alone less expensive, for deployment than Windows, and behold! I could use a Mac for development. Open-source, cross-platform, with a vast community not only adopting the language and the standard library but constantly forging new solutions, making them available to the same community, almost always for free. It was the way forward.

I envied that such a thing was unthinkable in my world. But unbeknownst to many, Microsoft was watching and taking notes. To the best of my knowledge, it was mainly the developers inside the corp —the dev team—who, glancing out of the ivory tower, began a campaign of internal lobbying, initially scattered and disorganized and later increasingly coordinated, which in turn led to endless meetings, discussions at coffee machines, and gradually, slowly and then more rapidly, to the advent of the .NET Core project. The metaphor of a snowball slowly rolling down a slope until it becomes an unstoppable avalanche perfectly applies here.

So, years after my departure (not an actual departure—I still worked in .NET for our legacy products), a new and unexpected .NET appeared on the scene. It was open-source, cross-platform, and open to external contributions. We could and perhaps should have a lengthy discussion on the openness to external contributions, but we can all agree that a revolution occurred and was historic in scale. At the same time, Microsoft opened up to other stacks, mainly because of Azure. I was shocked when I was proposed for a Microsoft MVP Award for my work on Python, not C#, at a time when Python had little to nothing to do with Microsoft. It made sense, as there was an urgent need to speak to developers outside its ecosystem—and perhaps even more so to those like me who had left: Hey, look, we’re back, we’re on track, and we’re not evil anymore.¹ 

And there I was, finding my old stack (which I secretly, I admit, considered only museum-worthy) back to relevance, competing on equal footing with the rest of the scene. The delay was costly, though. Even today, I meet colleagues who think modern .NET is just a new version, if not a simple rebranding of the Windows framework of old, and C# is more or less the same, way behind the new kids on the block. It’s a shame, and there are responsibilities. Some choices could have been bolder and more disruptive, starting with naming the new framework—but that’s another story.

Today, I create REST services with Minimal APIs on my Mac and deploy them on Linux via Docker at zero or near-zero cost, just as I would with Python, JavaScript, Rust, Go, or any other stack. The performance is far better than Python’s (C# REST services make circles around Python’s), and the toolchain is rich and powerful, especially around the command line, while many think .NET is still a GUI/Windows thing. Quick release cycles are essential to compensate for lost time (and there was lots of it) and stay on the cutting edge, sending a continuous signal that the platform is alive, thriving, and constantly expanding.

Aldus Manutius, the renowned Venetian printer and publisher of the Renaissance, adopted the Latin motto Festina lente, which translates to Make haste slowly or Hasten slowly. This paradoxical phrase encapsulates achieving careful, deliberate progress quickly and precisely, balancing urgency with caution. I feel that, consciously or not, the .NET team is on track with Manuzio’s goal: they iterate rapidly to achieve progress, balancing urgency with caution.

Nowadays, both .NET and C# focus on performance and while there’s room for growth, the current achievements are extraordinary. We’re competitive with most stacks, if not significantly ahead of them. Frequent, more minor C# releases allow for quick adjustments. Attentive developers adopt them continuously. Meanwhile, those who aren’t in a rush (probably most of Microsoft’s long-time customers, slow-moving conglomerates and the like) benefit from performance gains and technological advantages (multi-platform deployment!) at a low cost because, while the framework and language evolve, great effort is put into preserving backward compatibility. In most cases, migrating to .NET Core and newer versions of C# requires minimal effort.

C# 12 introduced two significant features: primary constructors and collection expressions, with the latter being predominant in terms of syntactic, semantic, and performance importance. They weren’t the only new features but certainly the key ones. C# 13 innovates further but subtly—there’s less syntax and more semantics, building on last year’s new features. The improvements may be less flashy but guide developers in the right direction, often ensuring better performance at zero cost, sometimes even without us having to do anything. As we shall see, it happens because in recent releases—let’s say the last two or three— features were introduced primarily to improve the framework, which is also written in C#. Our higher-level applications benefit from all of this. It is a pattern we’ll observe repeatedly throughout this presentation.

We have two ASP.NET 8 applications behind NGINX; one is a regular web app, and the other is an auth server built with Duende Identity Server. When the user attempts to log in to the web app, they are sent to the auth server; once logged in, they are sent back to the app, and that’s when NGINX returns a weird 502 Bad Gateway. Upon inspecting the NGINX logs, I found the following error:

upstream sent too big header while reading response header from upstream

Some digging revealed that NGINX has a pretty small default buffer size, and proxying auth requests (with their typically above-average-size headers) back and forth is prone to breaking that limit.

The fix is straightforward: raise those buffer sizes. Most blogs suggest doing that globally, but that seems overkill, as NGINX buffering can be configured per server and location blocks. You may want to keep the global defaults and only raise them (along with memory consumption) for locations that need it.

  location {
    ...
    proxy_buffers 4 256k;
    proxy_buffer_size 128k;
    proxy_busy_buffers_size 256k;
    ...
  }

Mind you, the above values (that I found in almost every blog dealing with this problem) are likely too big and should be trimmed down. That’s my next task, using this excellent article for guidance.

Anyway, in the pause, I glanced at my e-mails and discovered I had been again granted the Microsoft MVP Award. It is the ninth consecutive year, and I’m grateful and happy the journey continues. At this point, I should put in some extra effort to reach the 10-year milestone next year.

The scenario goes like this. I have an ASP.NET Core app that authenticates with Open Id Connect. It receives a bearer token from the authentication server. Besides OIDC claims, this token has been forged with additional custom claims for use in the app. However, only ODIC claims exist when I parse HttpContext.User.Identity.Claims in my middleware. If I retrieve the token with HttpContext.GetTokenAsync and decode it, I confirm it contains all the claims I need. Where have my custom claims gone? Or, how can I get User.Identity to provide them along with the OIDC ones?

As it turns out, one must hack them into the User.Identity.Claims collection by hand. That’s done by leveraging the OnTokenValidated event handler like this:

authenticationBuilder.AddOpenIdConnect("oidc", options =>
{
    options.Authority = "authority";
    options.ClientId = "client_id";
    options.ClientSecret = "secret";
    options.ResponseType = "code";

    ...
    options.GetClaimsFromUserInfoEndpoint = true;
    options.SaveTokens = true;
    options.Events = new()
    {
        OnTokenValidated = context =>
        {
            // adds custom claims from the token into Principal.Identity
            if (context.Principal?.Identity is not ClaimsIdentity claimsIdentity) return Task.CompletedTask;
            
            var accessToken = context.TokenEndpointResponse?.AccessToken;
            if (string.IsNullOrEmpty(accessToken)) return Task.CompletedTask;
            
            var handler = new JwtSecurityTokenHandler();
            if (handler.ReadToken(accessToken) is not JwtSecurityToken jsonToken) return Task.CompletedTask;
            
            foreach (var claim in jsonToken.Claims)
                if (claimsIdentity.Claims.All(c => c.Type != claim.Type))
                    claimsIdentity.AddClaim(claim);

            return Task.CompletedTask;
        }
    };
});

Is there a better and less hacky way to achieve the same result? Please let me know.

• I love collection expressions. Like primary constructors, collection expressions will see a significant adoption in the long run.

• Collection expressions introduce a new way to initialize common collection values in a terse, unified syntax.

• This is how we initialize collections today:

var x1 = new int[] { 1, 2, 3, 4 };
var x2 = Array.Empty<int>();
WriteByteArray(new[] { (byte)1, (byte)2, (byte)3 });
List<int> x3 = new() { 1, 2, 3, 4 };
Span<DateTime> dates = stackalloc DateTime[] { GetDate(0), GetDate(1) };
WriteByteSpan(stackalloc[] { (byte)1, (byte)2, (byte)3 });

Notice how the code is diverse depending on the type and the context. It is also verbose. Look at how we initialize an empty int array (second line); it’s lengthy and starkly contrasts with the previous line, where we initialize the same type with some actual values. In many situations, casting is needed; again, take a look at the WriteByteArray and WriteByteSpan calls.

• With collection expressions, it becomes like this:

int[] x4 = [1, 2, 3, 4];
int[] x5 = [];
WriteByteArray([1, 2, 3]);
List<int> x6 = [1, 2, 3, 4];
Span<DateTime> dates1 = [GetDate(0), GetDate(1)];
WriteByteSpan([1, 2, 3]);

We enclose items within square brackets, and that’s all. An empty collection is empty brackets. We can, of course, call functions or use variables.

• In many scenarios, the compiler will perform several optimizations. It can allocate the correct capacity or avoid copying data when unnecessary. The compiler can do that because the supported collection types are well-known and have been for a long time. We get these performance boosts for free when we switch to collection expressions.

• Let’s look at that WriteByteArray call. Let’s say that at some point, maybe months or years after it’s been used in many places, we decide to refactor the method and change the argument type from byte[] to int[]. We’d have to refactor the old-style caller to eliminate the casting, which is now an error. We don’t need to do any fix with collection expressions as they come with enhanced inference that will resolve the casting for us.

• On the first line, we’re initializing a new array (we aren’t calling a method with a signature), so with collection expressions, if we try to use var, it won’t work. In that case, we need to be explicit about the type.

• The spread operator allows us to insert variables and constants and to sort of “unroll” another collection within the new one, and it does so with optimal performance.

int[] numbers1 = [1, 2, 3];
int[] numbers2 = [4, 5, 6];
int[] moreNumbers = [.. numbers1, .. numbers2, 7, 8, 9];

foreach(var number in moreNumbers)
    Console.WriteLine(number);

It would be nice if lambdas were allowed in collection expressions, like in other languages (Python), but that’s not yet an option.

• What about custom collections? But let’s imagine I have built a LineBuffer class that inherits from IEnumrable<chrar>; it offers some custom features over its base class. I get an error if I try to use collection expression syntax on it. It is not a common .NET type, and the compiler doesn’t know how to go around it.

public class LineBuffer : IEnumerable<char>
{
    private readonly char[] _buffer = new char[80];

    public LineBuffer(ReadOnlySpan<char> buffer)
    {
        int number = (_buffer.Length < buffer.Length) ? _buffer.Length : buffer.Length;
        for (int i = 0; i < number; i++)
            _buffer[i] = buffer[i];
    }

    public IEnumerator<char> GetEnumerator() => _buffer.AsEnumerable<char>().GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator() => _buffer.GetEnumerator();

    // etc
}

// this causes a compile error
LineBuffer line = ['H', 'e', 'l', 'l', 'o', ' ', 'W', 'o', 'r', 'l', 'd', '!'];

• We can support collection expressions in our custom types, though. It’s a two-step process. First, we implement a builder method, then decorate the class (or struct) with a CollectionBuilderAttribute. The attribute maps our type to the builder method.

[CollectionBuilder(typeof(LineBuffer), nameof(Create))]
public class LineBuffer : IEnumerable<char>
{
    private readonly char[] _buffer = new char[80];

    public LineBuffer(ReadOnlySpan<char> buffer)
    {
        int number = (_buffer.Length < buffer.Length) ? _buffer.Length : buffer.Length;
        for (int i = 0; i < number; i++)
            _buffer[i] = buffer[i];
    }

    public IEnumerator<char> GetEnumerator() => _buffer.AsEnumerable<char>().GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator() => _buffer.GetEnumerator();

    internal static LineBuffer Create(ReadOnlySpan<char> values) => new LineBuffer(values);
}

The official documentation says the builder must be named “Create,” but that’s false. We can name it however we want as long as it matches the attribute (it’s probably still worth adhering to the suggested practice.)

• Adding collection expression support to custom types is helpful in your codebase, even more so if you’re a library author.

• The syntax of collection expressions is symmetric with that of slicing and pattern matching, a nice touch that keeps the language tidy and coherent. Take a look at this pattern matching switch:

public Grade GPA => Grades switch
{
    [] => 4.0m,
    [var grade] => grade,
    [.. var all] => all.Average()
};

• Visual Studio, VS Code, JetBrains Rider and most other IDEs offer full support for refactoring old-style collection initializations to collection expressions.

• What about dictionary expressions? They are common in other languages (again, Python). When asked, Kathrine Dollard of the C# design team answered that they’re thinking about it, mostly trying to understand the best design, so there’s a chance that we’ll see dictionary expressions in the language in the future.

Also see: C# 12 Primary Constructors.

In a follow-up post, I plan to address Collection Expressions (done) and maybe “type any aliases”; this is about Primary Constructors.

• We can now add a list of parameters to a struct or class declaration. This way, we avoid writing an explicit constructor method, sparing us some boilerplate code.

• What I refer to as ‘primary parameters’ are unique in that they are in scope throughout the type definition; this means they can be used anywhere within the type.

public readonly struct Distance(double dx, double dy)
{
    public readonly double Magnitude { get; } = Math.Sqrt(dx * dx + dy * dy);
    public readonly double Direction { get; } = Math.Atan2(dy, dx);
    public override string ToString() => $"{nameof(Magnitude)}: {Magnitude}, {nameof(Direction)}: {Direction}";
    public double Dx { get; } = dx;
    public double Dy { get; } = dy;
}

• It’s important to note that primary constructor parameters are not class members; therefore, this. cannot be used on them. They can be considered static values, but unlike typical static values, they can also be used in non-static methods, offering a unique advantage (some black magic happens behind the scenes.)

• We no longer need to define and assign a type-level field; the compiler will do that behind the scenes when needed; if a behind-the-scenes backing field is unnecessary, it won’t be created.

• Primary constructor parameters don’t become properties and are inaccessible outside the instance. We can create properties to expose their values if needed. Record types are an exception. Constructor parameters become properties with records, and it makes sense because records are generally used as DTOs, whereas we want the option with class and structs.

• Secondary and parameterless constructors can be added to a primary constructor. They must invoke the primary, passing its values along.

public Distance() : this(0, 0) { }

• With primary constructors, we do not have a method body; how do we handle argument validation? One pattern is to perform validation at property assignation.

public string AccountID { get; } = ValidAccountNumber(accountID)
    ? accountID
    : throw new ArgumentException("Invalid account number", nameof(accountID));

public static bool ValidAccountNumber(string accountID) => accountID?.Length == 10 && accountID.All(c => char.IsDigit(c));

• I like this pattern because it brings property declaration and validation close to each other, making it easier to process and reason about the domain logic. When we perform argument validation in an old-style constructor method, we tend to separate validation and declaration, making it difficult to reconcile the two aspects, especially when we have hundreds of lines between constructor code and property declaration.

• Derived types can have a primary constructor, too; it must invoke the base class’ primary constructor.

public class CheckingAccount(string accountID, string owner, decimal overdraftLimit = 0) : BankAccount(accountID, owner)

• Old-style derived types can still derive from a primary constructor type; a regular constructor will invoke the base primary, as we’ve always been doing.

• Regarding inheritance, we can mix and match primary constructor types with old-style types, making it easy to refactor our libraries to use primary constructors. We know that adopters will have no problem deriving from our refactored types.

• Watch out for “nested captures” of primary parameter values in derived types. If both the derived and the base type capture them, and one (or both) change their captured values, we may end up with non-aligned instance values. Roslyn’s analyzer will raise a warning so we can fix our code or mute the alert with a pragma.

• Visual Studio and Visual Studio code offer built-in support for primary constructors (refactorings, etc.) That’s true for JetBrains Rider or any other IDEs leveraging Roslyn.

• The primary constructor’s original implementation dates back to C# 6 in 2015. It was publicly available in one of those version previews for a short period. Then, it was taken back to the drawing board, only to resurface with record types in C# 9 (?) and custom types in C# 12.

Also see: C# 12 Collection Expressions.

I am thrilled to have the opportunity to present at an international conference once again. On May 9th, I will speak at the ABP Donet Conf'24. My session, titled C #12: What’s New and Interesting, is on a topic I’m passionate about.

With the alignment of C# and Dotnet Core release cycles, the C# release cadence has increased (we’re on a yearly cycle now), while feature quantity has reduced for individual releases, which is good. The faster, smaller iterations allow for quicker course corrections, and introducing fewer new features makes it easier to embrace the changes.

The ABP Dotnet Conf'24¹ will be held online on 8-9th May; the lineup and agenda look great, so reserve a ticket before they are sold out, and see you there!

I am always particularly excited when I can present the stuff I’m currently working on. Being forced to share as I learn encourages me to go deeper into the topic to reinforce my comprehension and better explain it to the audience—a win-win situation.

While the Rome conference is free, if you are considering WebDay in Milan (you should), feel free to use my speaker coupon P-SPEAKER10 for a 20% discount. If you come to any, don’t be shy and come to say Hi!

We upgraded our web application from .NET 7 and let the CI pipeline do its work. Finally, we checked the application in the browser to ensure everything was okay, but unfortunately, we got a 502 Bad Gateway error. The Nginx logs revealed that the app was rejecting connections, which was unexpected because we didn’t make any changes there. Further investigation showed that the web app listened on port 8080 while Nginx was reverse-proxied to 80. So that was the problem. But why did the port change?

The change to the port number was made because of the need to provide a good usability experience when switching to a non-root user. Running as a non-root user requires the use of a non-privileged port in some environments. Since port 80, the previous default port, is a privileged port, the default was updated to port 8080, which is a non-privileged port (source)

It all makes sense now. In hindsight, it was our mistake. We should have explicitly declared the port in our launch settings anyway. As the Python Zen says, “Explicit is better than implicit.”

It is in Italian¹ and you need to login in order to see it (sorry, I don’t have control over it.)

I was puzzled as the same container ran smoothly in our test environment but not in production. I ruled out resource problems (memory or disk full, maybe?) but then compared the Docker Engine versions we run in test and production. Both were old (20. xx when 25 is available), but interestingly, the production version was older. I searched online and found a two years-old ticket hinting at some problems between .NET 8 and older Docker versions.

I updated the Docker Engine to the latest version, and guess what? The .NET 8 container now starts without making a dent.

PKCE is an extension to the Authorization Code flow to prevent CSRF and authorization code injection attacks. [..] It was originally designed to protect the authorization code flow in mobile apps, but its ability to prevent authorization code injection makes it useful for every type of OAuth client, even web apps that use client authentication (source).

In a nutshell:

1. The client requests a single-use authorization code to an authorization server. In doing that, it includes a code_challenge with the request.
2. The server responds with the authorization code if the client is recognized and authorized.
3. The client requests an access token in exchange for the authorization code. It includes the code_verifier used to generate the original code_challenge;
4. The server confirms that the verifier is the same one used to generate the code challenge; hence, the client is the same.

Plenty of excellent documentation is online (like here.)

I was interested in code_verifier and code_challenge generation. Here’s my implementation:

/// <summary>
/// Provides a randomly generating PKCE code verifier and it's corresponding code challenge.
/// </summary>
public static class Pkce
{
    /// <summary>
    /// Generates a code_verifier and the corresponding code_challenge, as specified in the rfc-7636.
    /// </summary>
    /// <remarks>See https://datatracker.ietf.org/doc/html/rfc7636#section-4.1 and https://datatracker.ietf.org/doc/html/rfc7636#section-4.2</remarks>
    public static (string code_challenge, string verifier) Generate(int size = 32)
    {
        using var rng = RandomNumberGenerator.Create();
        var randomBytes = new byte[size];
        rng.GetBytes(randomBytes);
        var verifier = Base64UrlEncode(randomBytes);

        var buffer = Encoding.UTF8.GetBytes(verifier);
        var hash = SHA256.Create().ComputeHash(buffer);
        var challenge = Base64UrlEncode(hash);

        return (challenge, verifier);
    }

    private static string Base64UrlEncode(byte[] data) =>
        Convert.ToBase64String(data)
            .Replace("+", "-")
            .Replace("/", "_")
            .TrimEnd('=');
}

Usage is as simple as:

var (challenge, verifier) = Pkce.Generate();

In ASP.NET Core you don’t usually need to mess with PKCE as the framework supports it very transparently, but the project I’m working on right now is bare and to the bones, with no ASP.NET Core in sight, so I had to bring my own implementation. Fun stuff.

I presented on the same subject at a DevRomagna meetup a few months ago when C# 12 was in preview and still had several moving parts. Now that the final release is out, it will be interesting to return to the topic to consolidate my knowledge. I suspect that of the many reasons I challenge myself to speak publicly, enriching my knowledge is prevalent. As the adage goes, for learning a subject, nothing beats explaining it in front of a knowledgeable audience.

If you will attend the conference (you should!), remember to meet me and say hi!

Update: the session is now available online.

    await using var sw = new StringWriter();
    await using var w = XmlWriter.Create(sw, new() { Async = true });
    ...
    await w.FlushAsync();
    return sw.ToString();

Will emit this output:

    <?xml version="1.0" encoding="utf-16"?><...

There’s nothing inherently wrong with UTF-16, but XML is usually UTF-8, so one must do something about it. StringWriter exposes an Encoding property, but it is read-only for unknown reasons. One might think that given that the XmlWriter allows setting its own Encoding value, something like this would work:

    await using var sw = new StringWriter();
    await using var w = XmlWriter.Create(sw, 
        new() { Async = true , Encoding = Encoding.UTF8});
    ...
    await w.FlushAsync();
    return sw.ToString();

But it doesn’t. Over time, I’ve seen a few different ways to get out of this dead end, some more performant and or less verbose than others, but my favorite is resorting to a custom StringWriter:

    public class Utf8StringWriter : StringWriter
    {
        public override Encoding Encoding => Encoding.UTF8;
    }

Armed with this, it is trivial, as it should have been from the get-go, to obtain the desired output:

    await using var sw = new Utf8StringWriter();
    await using var w = XmlWriter.Create(sw, new() { Async = true });
    ...
    await w.FlushAsync();
    return sw.ToString();

    // returns  <?xml version="1.0" encoding="utf-8"?><...

The whole .NET framework has seen fantastic performance improvements, top-class multi-platform support, and remarkable streamlining, but some baffling pitfalls are still hidden in some of its less obvious parts. StringWriter not supporting UTF-8 out-of-the-box is one of them.

.NET 6 and its successors have the method built in within LINQ, but I needed it in a .NET Standard 2.0 class library, so I was out of luck. My implementation is simple, not different from others I found online, and should also work fine with old .NET releases. Here it is:

    public static IEnumerable<TSource> DistinctBy<TSource, TKey>(this IEnumerable<TSource> source, Func<TSource, TKey> keySelector)
    {
        var keys = new HashSet<TKey>();
        foreach (var element in source)
        {
            if (keys.Contains(keySelector(element))) continue;
            keys.Add(keySelector(element));
            yield return element;
        }
    }

In the following usage example, I will get back all unique objects from the original sequence, distinct by their Name property:

    var uniques = mySequenceOfObjects.DistinctBy(x => x.Name);

I later went to check the official .NET 6+ implementation. They support an optional equality comparer , which I don’t need, but their base implementation is similar to mine (they use deferred execution as well).

By the way, years after its open-sourcing, I still get thrills when I realize I can always look at, let alone contribute to, the .NET source code.

• Work on my open-source projects
• Present at conferences and local meetups
• Write some articles here and there
• Blog as usual

Then, one day, someone nominated me for the award. I was surprised, baffled and thankful, and I did not expect to pass the selection process. I was genuinely shocked when I received the first award. Being in the MVP program has been a happy and rewarding ride, and I’m glad the journey continues for another year.

It took me an embarrassing time to realize that, while successful, my docfx updates (dotnet tool update -g docfx) were being ignored. An old, Homebrew-installed version of docfx was being executed at my launches —a simple which docfx revealed the issue. brew uninstall docfx finally set the updated, dotnet-installed version free of its chains, and it is now merrily churning websites.

A similar issue emerged between Homebrew and .NET 8 Preview only a few days ago. Lesson learned I’m not installing dotnet tools via Homebrew anymore. Or maybe, I might stay clear of Homebrew altogether.

Installation went well, but then I turned to the command line only to find that dotnet --list-sdks was still and only showing version 7. Yet, the 8 Preview was sitting there at its canonical location at /usr/local/share/dotnet/sdk, where the v7 was also listed.

Puzzled, I tried a few things, but the quick fix was to simply brew uninstall --ignore-dependencies dotnet and, boom, both versions 8 Preview and 7 became immediately available. I suspect that brew uninstall only removed the symlink from .NET canonical location to the Homebrew cellar, which magically solved the SDK visibility problem.

TL; DR. Homebrew recipes don’t play nicely with .NET canonical installer. To make all my SDK versions visible to .NET, I had to forego the Homebrew installation, which did not uninstall the SDK itself, but simply unlinked it.

Once enabled, the new logger shows you the restore phase, followed by the build phase. During each phase, the currently-building projects are at the bottom of the terminal, and each building project tells you both the MSBuild Target currently being built, as well as the amount of time spent on that target.

The new MSBuild terminal logger is not the default. It must be opted-in with the tl option of the dotnet build command. Here’s what it looks like for a complex, multi-project and multi-target solution:

Now, if you’re doing .NET programming within an IDE like Rider of Visual Studio, this all might seem of little importance to you, but rest assured as soon as you have to look at CI logs or if you use the command line in your workflow a lot as I do, this is pure bliss.

Interestingly, this marks only the first step in a series of upcoming MSBuild UX improvements: “We hope to use this logger as the foundation for a new batch of UX improvements for MSBuild, including aspects like progress reporting and structured errors in the future.” Color me excited.

This release refines how the one-cent tolerance is accounted for in validation checks of types 00421 and 00423. As is often the case, there are subtle differences between the theoretical implementation defined in the official specs and the actual validation implemented by the same Agency that released said specs. See the relevant ticket for the details.

The init keyword defines an accessor method in a property or indexer. An init-only setter assigns a value to the property or the indexer element only during object construction. This enforces immutability so that once the object is initialized, it can’t be changed again.

Consider the following class:

    public class Person
    {
        public string FirstName { get; init; }
    }

You can initialize it like this:

    var person = new Person { FirstName = "John" };

But this will fail:

    var person = new Person();
    person.FirstName = "John";  //Not allowed

For my project, which is a .NET Standard 2.0 library, I thought this approach might be preferable to a parameter-enforced class constructor alternative.

To my surprise, however, when I tried the above, I got the following error:

The predefined type 'System.Runtime.CompilerServices.IsExternalInit' must be
defined or imported in order to declare init-only setter

As it turns out, The IsExternalInit type is only included in the net5.0 (and subsequent) target frameworks, so one cannot use it right away in a NetStandard 2.0 (or 2.1, for that matter) library.

In the dotnet world, when I encounter “type is not defined in version X” scenario, I know I can get around the issue by making up the type on my own. A quick lookup confirmed that this was the case, and the workaround is to add the following somewhere in my source code:

    namespace System.Runtime.CompilerServices
    {
        internal static class IsExternalInit {}
    }

And presto, the init keyword is now fully available to my library.

While researching this matter, I stumbled into PolySharp, a lovely package that takes this workaround approach to new heights. What is it?

PolySharp provides generated, source-only polyfills for C# language features, to easily use all runtime-agnostic features downlevel. The package is distributed as a source generator, so that it will automatically detect which polyfills are needed depending on the target framework and project in use: just add a reference to PolySharp, set your C# language version to latest, and have fun!

And it works! Just add a PolySharp reference, and almost all modern C# language features become automagically available to your project, with no tricks around polluting your code. What’s also nice about PolySharp, is that it isn’t a dependency for your library; it only needs to be there at compile time.

Do you know what’s funny? After all, I took a different route; no init keyword is used anymore in my library, but that’s for another story.

Blazor United is all experimental at the moment, but I’m confident it will land in one form or another, either in .NET 8 or later. I remember a few years ago at a Microsoft MVP Summit in Redmond when Steve first introduced Blazor as “an experiment”. If he puts in the effort to present his experiments to the public, he’s got approval for that, which means the project is a little more than just an experiment at this point.

Blazor weakness so far has been more with the tooling than the features. Should Blazor United come with some solid tooling, it will be a huge hit.

Our use case is simple. We use what the ASP.NET Core 7 documentation defines as a “fixed window limiter.” It uses a specified time window to limit requests. When the time window expires, a new time window starts, and the request limit is reset. Consider the following code (for convenience, I’m using an extension method):

public static void ConfigureRateLimit(this IServiceCollection services)
{
    services.AddRateLimiter(x => 
        x.AddFixedWindowLimiter(
                policyName: "fixed", options =>
                {
                    options.PermitLimit 1;
                    options.Window = TimeSpan.FromSeconds(10);
                    options.QueueLimit 1;
                }));
}

It sets a window of 10 seconds. Within that window, a maximum of one request is allowed. Exceeding requests will be queued and served at window reset. Notice that we defined “fixed” as the policy name.

Once our policy is configured, we must instrument the app instance to use the rate limiter, then we call RequireRateLimiting on our endpoints:

app.UseRouting();  // I'm mentioning this line for good reason, see below
app.UseRateLimiter();
app.UseEndpoints(endpoints => { endpoints.MapControllers()
    .RequireRateLimiting("fixed"); });

Nothing else is needed, really, for such a simple scenario. We could be more sophisticated. We could opt for more advanced options, like a “sliding windows limiter” or a “bucket token limiter”; we could apply rate limiting only to specific endpoints or controllers or mix and match these options. I chose to ditch hard-coded settings and read them from the configuration file. My appsettings.json contains the following (with different vaues):

  "RateLimiter": {
    "PermitLimit": 1
    "Window": 10,
    "QueueLimit": 1
  }

The RateLimiter class maps the json structure:

public class RateLimiter
{
    public int PermitLimit { get; set; }
    public int Window { get; set; }
    public int QueueLimit { get; set; }
}

The updated code looks like this:

public static void ConfigureRateLimit(this IServiceCollection services, 
    IConfiguration configuration)
{
    var rateLimiter = new RateLimiter();
    configuration.GetSection("RateLimiter").Bind(rateLimiter);
    
    services.AddRateLimiter(x => 
        x.AddFixedWindowLimiter(
                policyName: "fixed", options =>
                {
                    options.PermitLimit = rateLimiter.PermitLimit;
                    options.Window = TimeSpan.FromSeconds(rateLimiter.Window);
                    options.QueueLimit = rateLimiter.QueueLimit;
                }));
}

I wish I could say it all worked splendidly on the first try. The API was running fine, but it was not rate-limited. It looked like the middleware was not being invoked, or it somehow failed miserably and silently. After an embarrassingly long time, I figured out the problem: UseRateLimiter must be called after UseRouting.

Before:

app.UseRateLimiter();
app.UseRouting();
app.UseEndpoints(endpoints => { endpoints
    .MapControllers().RequireRateLimiting("fixed"); });

After:

app.UseRouting();
app.UseRateLimiter();
app.UseEndpoints(endpoints => { endpoints.MapControllers()
    .RequireRateLimiting("fixed"); });

Simply switching two lines saved the day. I looked high and low but could not find any reference to this requirement. If intended, it should be mentioned in the documentation. If it is a bug, it should be fixed (and I should probably open at ticket about it.)

Anyways, now the API is rate-limited via the new middleware. The first request sent via Postman goes through. The second, rapid-fired one is queued and served at window reset, as expected. A third request within the same window is bounced back.

However:

1. You get a 503 Service Unavailable response. I’m not in favor of 500 replies for this case. Five-hundreds should be reserved for server errors, and that’s not what we are dealing with here. My previous implementation served a more appropriate 429 Too Many Requests.
2. No Retry-After header is included with the response. I think it’s mandatory to instruct clients on what to do next.

Luckily, the rate-limiting middleware allows for ample customization. On defining our policy, we can attach a custom function to the OnRejected event. The code below is updated to address both issues above:

public static class ServicesConfiguration
{
    public static void ConfigureRateLimit(this IServiceCollection services, 
        IConfiguration configuration) {

        var rateLimiter = new RateLimiter();
        configuration.GetSection("RateLimiter").Bind(rateLimiter);
        
        services.AddRateLimiter(x => 
            x.AddFixedWindowLimiter(
                    policyName: "fixed", options => {
                        options.PermitLimit = rateLimiter.PermitLimit;
                        options.Window = TimeSpan.FromSeconds(rateLimiter.Window);
                        options.QueueLimit = rateLimiter.QueueLimit;
                    })

                // new code here:
                .OnRejected = (context, _) => {

                // inject Retry-After header (too much line wrapping, I know)
                if (context.Lease.TryGetMetadata(MetadataName.RetryAfter, 
                    out var retryAfter)) {
                    context.HttpContext.Response.Headers.RetryAfter =
                        ((int) retryAfter.TotalSeconds).ToString();
                }
                // return a different status code
                context.HttpContext.Response.StatusCode = 
                    StatusCodes.Status429TooManyRequests;
                return new();
            });
    }

And that’s all there is to it. I dropped the AspNetCoreRateLimiting dependency. That is one great piece of software, and I am grateful to its author Stefan Prodan and his contributors. As mentioned in My Top 7 New Features in .NET 7, they recently released a package that allows using Redis as a rate-limiting backend. I might adopt it in the future.

Complete documentation for ASP.NET Core 7 rate-limiting middleware is available here.

My second best is the fulls upport for WSL2 remote development. This one took a good while to come out of the trenches, but better late than never, I’d say.

And the new experimental UI? That’s neat too.

The full list of updates is available on their What’s New page.

1. Performance

Since the initial release of “new dotnet” (.NET Core), performance has always been a critical goal for the .NET team. Starting with .NET 5, performance gains have been skyrocketing. .NET 6 was a lot faster than 5, and now, well, I’m surprised by the remarkable performance improvements in .NET 7. Stephen Toub posted a remarkably long (255 printed pages!) in-depth analysis of the performance improvements in .NET 7. one That was followed by articles dedicated to ASP.NET Core 7 and MAUI 7 performance gains. At .NETConf 2022, a particular slide caught everyone’s attention.

I recall seeing the same slide at the .NET 5 release, so this one is must be updated version. I’m more impressed with the gRPC graph than the big “11x faster than Node” one. Being faster than Node doesn’t break the news these days, but being quicker than Go, C++ and Rust? That’s one bold statement you have right there.

An exciting article surfaced a while ago on this specific topic. In it, Dustin Moris Gorski presents an in-depth analysis of the ASP.NET Core 7 code used for the TechEmpower Framework Benchmark referenced in the above slide. The results are… fascinating. That code is undoubtedly not what mere mortals tend to run in their production systems. It is super-performance-optimized, often ditching canonical, built-in, and wildly adopted features in favor of low-level, high-performance and precisely hand-crafted alternatives. Dustin’s article is a masterpiece for several reasons; I suggest you invest your time reading it.

But yeah, despite this glitch, the takeaway is that .NET 7 is speedy, faster than previous versions, and on par with, if not (far?) superior to, most stacks and frameworks. The Stephen Toub’s article is a testament to the massive work done and the achievements obtained.

Most importantely, we get most of these speed benefits for free, just by upgrading to .NET 7. And the good new is, the upgrade is as easy as changing the framework moniker from, say, net6.0 to net7.0 and upgrading the Microsoft dependencies to v7.0.0.

2. C# 11 required modifier

As a consequence of the C# release cycle alignment to that of.NET itself (which is much faster), recent versions of C# see fewer features announcements than in the past. A good thing in my opinion. Of the several appreciable new features coming with C# 11, a remarkable one is the required modifier.

When you enable nullable checks in a project, non-nullable string properties are flagged with warning that they should be initialized with a non-null value when exiting the constructor:

A common workaround has been these properties them with a null! value. That is like telling the compiler that we know they should be initialized with a non-nullable, but well, let’s initialize them with a null value first, just in case. It’ll all be sorted later in the code. Somewhat awkward and prone to errors. Also, battling the compiler like that is a tedious task.

Enter the required keyword. When you flag a property with required, the IntelliSense engine will report an error if the property value is not set at initialization, not at declaration.

When someone initializes our class instance, he/she’s required to set an explicit value for our property. Notice how we went from a warning (which will compile) to an error (which won’t compile). Once you start using this feature, it feels so obvious and natural that you wonder why it wasn’t there right from start.

3. C# 11 raw string literals

In C# 11, wrapping a string with triple-double-quotes makes it a raw literal. Its main benefits are that no escaping of double-quotes is necessary, and newlines are allowed within the string.

var xml = """
          <element attr="content">
            <body>
            </body>
          </element>
          """;

The code looks natural, and no runtime costs for specialized string manipulation are required. One caveat is that string literals naturally remove the indentation when producing the final literal value. The snippet above prints as:

<element attr="content">
  <body>
  </body>
</element>

We can disable indentation removal like so:

var xml = """
          <element attr="content">
            <body>
            </body>
          </element>
""";

String interpolation is also supported:

var json = $$"""
             {
                "summary": "text",
                "length" : {{value.Length}},
             };
             """

In hindsight, like the required modifier, raw string literals appear as obvious.

4. Built-in container support

.NET 7 has built-in container support, meaning that dotnet publish can now output to a container image instead of a directory. We control image names, tags, and other settings (like the base image) via dedicated .csproj tags. Two requirements:

• Docker must be running when we issue the publish command;
• The Microsoft.NET.Build.Containers package must be added to the project as a package reference.

In my demo, I had a small console application that I published to a docker image by simply issuing the following command:

$ dotnet publish --os linux --arch x64 /t:PublishContainer -c Release

I did not mention a Dockerfile, and that’s because it is not needed anymore. All my projects deploy to docker containers and are already migrated to .NET 7. I’m currently using Dockerfiles, but I’ll be experimenting with this alternative in the coming weeks, both with builds and remote CI builds.

5. Native AOT

Native AOT produces a standalone executable in the target platform’s file format, with no external dependencies. It’s native, with no IL or JIT involved, and provides fast startup time and a small, self-contained deployment.

In my demo, I just needed to add a <PublishAot>true</PublishAot> tag to the .csproj, and then the dotnet publish -c Release command produced a single-file, macOS native executable. You can set the destination platform at build-time like so:

$ dotnet publish -r win-x64 -c Release

Native AOT will be determinant in a number of use cases, like multi-cloud-deployments, lambda functions, and, in general, hyper-scale services. ASP.NET Core is currently not supported, so we’re limited to console apps.

6 and 7. Rate-limiting and output caching

Ok, these are two, not one. Luckily, my pal Ugo, who was demoing ASP.NET Core 7 parts after me, took charge of showing these.

I briefly mentioned that rate-limiting and output caching are key features in mature production systems. Until today, we had to bake them in-house or rely on third-party packages. I’ve been using LazyCache and AspNetCoreRateLimit myself. The latter recently acknowledged the arrival of rate-limiting in .NET 7 and embraced it in a new package that offers Redis as a rate-limiting backend. Rate-limiting and output caching are now part of the ASP.NET Core framework, and that’s where they belong.

8. Minimal APIs group routes

I know I said 7. I don’t use minimal APIs in production yet, but group routing is beautiful and something I’ll be employing on the first occasion. During the meetup, an interesting (and much-expected) discussion ensued on the usefulness of minimal APIs. Veterans of many battles don’t deem them necessary, especially in real-world use cases, which is actually accurate: one can keep relying on the canonical MVC approach. The sentiment was that Minimal APIs are mostly targeted to newcomers, which is probably true². As someone coming from the Python REST ecosystem, I dig them a lot. They evolve rapidly and I’m sure we’ll soon see them in action in complex, real scenarios.

Be aware that this release anticipates support for v1.7.1 of the specification going into effect on October 1, 2022. For more information, see the appropriate ticket and the changelog.

Being a member of the MVP community has been a very positive experience for me, especially in the years before COVID, when the MVP Summit, the main MVP event, was held in person in Seattle at the Microsoft HQ. That assembly of experienced developers from all over the world is an exhilarating experience. Smart guys and gals from different cultures gather to meet the people responsible for their daily drivers’ tools and technologies. There are countless networking possibilities, both with fellow MVPs and Microsoft personnel.

For the last two years, the Summit has been an online event. I admit I’ve had a hard time following the sessions as work and family tended to get in the way. The networking was, of course, next to zero. I miss the original MVP Summit. In the absence of it, even just meeting the Italian MVPs has been a rare occurrence. Hopefully, things will return to normal this year, although I’m doubtful.

I’m looking forward to giving the same session in English sooner or later, but I should first win my laziness and start looking for exciting events with open CFPs. If you happen to know one, please let me know.

In a nutshell, they want to spare us a lot of boilerplate. Code like this:

public static void M(string s)
{
    if (s is null)
    {
        throw new ArgumentNullException(nameof(s));
    }
    // Body of the method
}

Would be abbreviated by adding !! to the parameter name:

public static void M(string s!!)
{
    // Body of the method
}

Code will be generated to perform the null check. The generated null check will execute before any of the code within the method. For constructors, the null check occurs before field initialization, calls to base constructors, and calls to this constructors.

My initial reaction was, we don’t need this; we got Nullable Reference Types. NRTs however help at design time, to know whether a null is possible, while parameter null-checking is meant for runtime.

According to Kathleen Dollard, the .NET Runtime itself removed nearly 20,000 lines of code using this new null-check syntax. That’s one heck of a lot of boilerplate removed.

I don’t think I like the syntax, though. It’s super concise, which is good, and I appreciate putting the !! on the parameter rather than the type since the parameter’s value is being checked. Still, the two-punctuation character seems a bit clumsy. Someone suggested adopting notnull instead:

public void M(string s notnull) { // code }

I like this suggestion. I wouldn’t want notnull on the left of the parameter name. To the right? Count me in.

The official ASP.NET Core 5.0 to 6.0 migration guide was my first stop. It offers the perfect entry point, rich with in-depth links. At this stage, I am not interested in switching to the new .NET 6 minimal hosting model (aka Minimal APIs). I think it’s a significant improvement, and we will likely adopt it for new projects, but our production projects aren’t going to be refactored right away. Should minimal APIs also prove to be remarkably performant, we’ll reconsider them¹.

The first step was updating the target framework moniker to net6.0.

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>
</Project>

Then, I updated all Microsoft.AspNetCore.* and Microsoft.Extensions.* package references to version 6.0.0.

<ItemGroup>
  <PackageReference Include="Microsoft.AspNetCore.JsonPatch" Version="6.0.0" />
  <PackageReference Include="Microsoft.Extensions.Caching.[...]" Version="6.0.0" />
</ItemGroup>

That’s all I needed to do to update the MVC application. The only other thing left for me was to update Dockerfile’s FROM statements to pull the new .NET 6 image:

# build stage
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /build
[..]
# final stage/image
FROM mcr.microsoft.com/dotnet/aspnet:6.0
[..]

Migrating the WebApi/REST services required more work. I got a few errors and warnings, either at compile or runtime. Let’s go through them one by one.

New JsonSerializer source generator overloads

The call is ambiguous between the following methods or properties: ‘JsonSerializer.Serialize(TValue, JsonSerializerOptions?)’ and ‘JsonSerializer.Serialize(TValue, JsonTypeInfo)’"

In .NET 6, the Sytem.Text.Json.JsonSerializer acquired two new overloads that support pre-generated type information via source-generators. Previously, you could write code that passed null (or default) as the value for the JsonSeralizerOptions parameter:

entity.Property(e => e.Value)
    .HasConversion(
        v => JsonSerializer.Serialize(v, null),
        v => JsonSerializer.Deserialize(v, null));

However, the new source-generator-enabled overloads will cause ambiguity if you pass null. The solution was to add simply an explicit cast to the intended target:

entity.Property(e => e.Value)
    .HasConversion(
        v => JsonSerializer.Serialize(v, (JsonSerializerOptions)null), 
        v => JsonSerializer.Deserialize(v, (JsonSerializerOptions)null));

The RNGCryptoServiceProvider is now obsolete

SYSLIB0023: RNGCryptoServiceProvider is obsolete

As it turns out, RNGCryptoServiceProvider is marked as obsolete in .NET 6. The new preferred way to generate a random number is using one of the RandomNunmberGenerator static methods.

  // old
  using var rng = new RNGCryptoServiceProvider();
  var uintBuffer = new byte[sizeof(uint)];
  rng.GetBytes(uintBuffer);
  var num = BitConverter.ToUInt32(uintBuffer, 0);

  // new
  using var rng = RandomNumberGenerator.Create();
  var uintBuffer = new byte[sizeof(uint)];
  rng.GetBytes(uintBuffer);
  var num = BitConverter.ToUInt32(uintBuffer, 0);

The two issues above are essentially the only ones I met with .NET 6 itself. As mentioned, I also encountered a few EF Core 6 annoyances. They are listed below.

New IModelCacheKeyFactory.Create() overload

The requested configuration is not stored in the read-optimized model, please use DbContext.GetService<IDesignTimeModel>().Model.

If, like me, you happen to have a custom IModelCacheKeyFactory implementation, you will likely get this error at runtime. Starting with EF Core 6, you must implement the new overload of the Create method that handles design-time model caching.

// old
public class DynamicModelCacheKeyFactoryDesignTimeSupport : IModelCacheKeyFactory
{
   public object Create(DbContext context) => 
     context is DynamicContext dynamicContext
       ? (context.GetType(), dynamicContext.UseIntProperty)
       : (object)context.GetType();

    public object Create(DbContext context) => Create(context, false);
}

// new
public class DynamicModelCacheKeyFactoryDesignTimeSupport : IModelCacheKeyFactory
{
   public object Create(DbContext context, bool designTime) => 
     context is DynamicContext dynamicContext
       ? (context.GetType(), dynamicContext.UseIntProperty, designTime)
       : (object)context.GetType();

    public object Create(DbContext context) => Create(context, false);
}

Nested optional dependents with no required properties

Entity type ‘[EntityType]’ is an optional dependent using table sharing and containing other dependents without any required non shared property to identify whether the entity exists. If all nullable properties contain a null value in database then an object instance won’t be created in the query causing nested dependent’s values to be lost. Add a required property to create instances with null values for other properties or mark the incoming navigation as required to always create an instance.

The message above is a consequence of a high-impact breaking change introduced in EF Core 6.0. In the past, you could have models with nested optional dependents sharing the same table, each with no required properties. In such circumstances, data loss could occur (see the documentation for details and examples). My solution was to mark at least one property of dependent models with the RequiredAttribute (which, in every single case, was the right thing to do anyway)

The EFCore.NamingConventions package is missing a method

Method ‘GetServiceProviderHashCode’ in type ‘ExtensionInfo’ from assembly ‘EFCore.NamingConventions"

The message says it all: there’s currently a missing method in the latest stable version of the EFCore.NamingConventions package. At the time of this writing, v6.0 of the package has not been released, but there is a pre-release available that includes the missing implementation. Switch to v6.0.0-rc.1 and you’ll be fine (ticket is here). I’m sure the new stable release will be out by the time you read this.

Update: EFCore.NamingConventions v6 has now been released.

The Npgsql timestamps breaking change

While the above situations were quick to fix, the new, updated Npgsql provider offers a different threat level. There’s one significant breaking change that impacts DateTime fields (timestamps). As the documentation suggests, it is possible to opt out of this change to preserve backward compatibility, but I decided to take the plunge and embrace it. The short version is that Postgres’s timestamp fields (’timestamps without timezone’) are changed to timestampz (’timestamps with time zones’). In the application, when dealing with Npgsql, DateTime properties must be treated as UTC by setting the Kind property to DateTimeKind.UTC. When you run the migration tool, a migration is created to accomodate the change, which can impact existing data. Make sure you read the detailed notes to assess the impact on your data. I let the migration run, then updated models configuration by setting a custom DateTimeUtcValueConverter for DateTime properties:

// custom DateTime converter
protected readonly ValueConverter DateTimeToUtcConverter = 
  new ValueConverter<DateTime, DateTime>(
    v => DateTime.SpecifyKind(v, DateTimeKind.Utc),
    v => v);

// Entity configuration 
internal class MyEntityConfiguratin : IEntityTypeConfiguration<MyEntity> 
{
  public override void Configure(EntityTypeBuilder<MyEntity> builder)
  {
    builder.Property(o => o.Date).HasConversion(DateTimeToUtcConverter);
  }
}

Now Postgres timestamps are stored as ’timestamp with timezone (timestampz). Actual values are UTC as before. A custom converter is attached to the Date property at the application level to ensure that values are correctly handled.

Our stack is now fully running on .NET 6. Upgrading a standard ASP.NET 5 project to .NET 6 revealed to be relatively straightforward. The EF Core 6.0 migration can be more involved, while the Npgsql 6 migration requires some attention but, remember, you can always opt-out of the delicate timestamps change. Was the upgrade worth it? I think so for a few reasons. First, .NET 6 is LTS, while .NET 5 will be out of support in six months. Second, .NET 6 is the fastest yet, with a remarkable margin (EF Core 6 alone is 70% faster.) While the primary migration is done, there are a lot of changes and new features that are worth considering for our codebase, which is something we will be doing in the upcoming weeks.

Unfortunately, the worst-case scenario pictured above, or worse, appears to be happening these days, not to me, but to the many open-source maintainers who, in recent years, agreed to move their projects under the .NET Foundation umbrella. The drama is unfolding in these very same hours, and it is painful. On my Twitter feed, I first noticed Eric Sink’s note on the issue. The next day, a detailed article surfaces on The Register. Then, just yesterday, the Executive Director of the DNF posted an I am Sorry message on GitHub, which most maintainers consider disappointing, to say the least. Maintainers see the ownership of their projects being moved over to DNF. Some projects are transferred to GitHub Enterprise for no apparent reason. DNF Executive Director opened a Pull Request, which was closed by the maintainers and then reopened (twice!) by the Director (who also happens to be a former maintainer). You can get all the details at the links above. The I am Sorry thread is especially worth reading.

I think the foundation is well-intentioned. I question whether independent open-source projects should belong there, though—maybe very few major and commercially inclined ones. To offer legal protection, DNF needs some control over its projects, and that’s something not every maintainer is willing to give away. On the other hand, maintainers might have underestimated the consequences of moving their projects to DNF. I can feel their pain.

Overall, this is all concerning. As someone commented on Hacker News, with the .NET ecosystem, Microsoft has made so many surprisingly good moves in recent years that there is room for a couple of fuck-ups, but this is a big one. Besides, most maintainers involved in this drama are highly influential and very well respected individuals in the .NET world. The DNF needs to get its acts together and react immediately, at the risk of losing all of its credibility.

Update: Executive director [has resigned][7]. Updates from DNF are due as earsly as next week.

Do I have to migrate to the new hosting model

No, you don’t have to. It’s the preferred way to host ASP.NET Core applications from .NET 6 and onwards but you aren’t forced to change your project layout. This means you can upgrade from .NET 5 to .NET 6.0 by changing the target framework in your project file from net5.0 to net6.0.

.NET6 Release Candidate is out, so the guide is unlikely to receive updates, but I’m sure that David will be ready to do so if required.

We are about to release several brand new web services in the coming weeks. They are all ASP.NET 5, currently in beta, but before release we’re likely to upgrade them to NET6. NET6 is LTS, NET5 isn’t, and offers significant advantages, remarkable [performance gains][2] included.

For .NET 6, we have made FileStream much faster and more reliable, thanks to an almost entire re-write. For same cases, the async implementation is now a few times faster! We also recognized the need of having more high-performance file IO features: concurrent reads and writes, scatter/gather IO and introduced new APIs for them. TL;DR File I/O is better, stronger, faster!

If you have the time, make sure you read the whole blog post. Learning about the low-level details on how they achieved such (pretty phenomenal) results is fascinating. They’re not stopping at file IO either. In another lengthy blog post, they had to add a table of contents, or we would get lost in the myriad of improvements.

Don’t worry, I don’t cover all of them here, but grab a large mug of your favorite hot beverage, and settle in: this post takes a rip-roarin’ tour through ~400 PRs that, all together, significantly improve .NET performance for .NET 6.

There are a ton of new things coming up, too, of course.

It turns out that under NETCore/NET5+, to read Windows-1252 encoded files, we first need to take a dependency on System.Text.Encoding.CodePages:

dotnet add package System.Text.Encoding.CodePages

Then, we register a CodePagesEncodingProvider instance from the package:

Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);

Finally, on creating the XmlReader instance, we can set the encoding. To do that, we need to pass an XmlParserContext instance, which allows us to specify custom encoding:

# Create the parser context and set the encoding
var context = new XmlParserContext(null, null, null, XmlSpace.None)
context.Encoding = Encoding.GetEncoding(1252);

# Use the custom parser when reading the Xml
using (var r = XmlReader.Create(fileName, null, context))
{
    ...
}

And sure enough, all those troublesome XML files are no problem anymore. It works on all platforms: Linux, macOS, and Windows. That’s a lot of tinkering for a small task that required no effort in the past. However, it makes sense as .NET is now cross-platform, and we want to reduce the app’s footprint as much as possible.

var app = WebApplication.Create(args);
app.MapGet("/", () => "Hello World!");
await app.RunAsync();

If you’re a seasoned ASP.NET MVC/WebApi developer, the snippet caught your attention because, pre-.NET 6, achieving the same result will have you messing with a lot of extra cruft². I suspect, however, that this feature is not primarily targeted at existing .NET developers. Developers new and old looking at .NET for the first time, or those like me returning after a long break; these are, I think, the designated audience.

A long time ago, I left C# and .NET behind precisely because I had to write REST APIs, and back then, the options available in .NET were, to put it mildly, cumbersome. Admittedly, there were other reasons for switching, like .NET not being cross-platform - I wanted to run my APIs on Linux - and general dissatisfaction with the Microsoft ecosystem. Long story short, I went with Python. Check out this snippet from Flask’s renowned Quickstart:

app = Flask(__name__)

@app.route("/")
def hello_world():
    return "<p>Hello, World!</p>"

Launched with the compelling motto ‘web development, one drop at a time’ and presented as a ‘micro’ web framework, Flask immediately caught my attention³. Cruft-free and elegant APIs are not a Flask (or Python, for the matter) exclusive. A Node code snippet for a REST API would be similar. Now, with NET 6 Minimal APIs, we’re finally matching the industry standard for code clarity and simplicity. Moreover, .NET has better performance⁴ and strongly typed languages that offer excellent type inference (F# reigns supreme there, with C# catching up nicely.) I’d dare to say that the C# snippet is a winner. I mean, look at that inline lambda, with no casts!

Minimal APIs typical use-case is everyone’s favourite, microservices. I do not doubt the delivery⁵⁶. The challenge, I think, is the actual adoption rate. Whether veterans will adopt them or not (over time, they will) is relatively significant, I guess. The critical question is, will Minimal APIs succeed in attracting new developers to .NET?

That will mainly depend on communication. Will evangelism be robust, persistent and persuasive enough? That’s the tricky part. Every time I speak to the Python or JavaScript crowd, I am amazed that the majority don’t even know that .NET is now open-source, cross-platform, and blazingly performant. Most, if not all, are tied to the old idea of a Windows-only, cumbersome, black-boxed, enterprise-oriented offering. That’s not the case anymore. .NET is on par with the other cool stacks or is getting there very rapidly. I am afraid it’s just a little bit too late for the vast majority of the web development crowd to take notice. It will take an enormous, coordinated effort to bring the message across.

With the platform now ready, effective communication, branding, and evangelism will eventually change the tide. Tutorials, getting-started guides, conference talks, YouTube videos, and workshops should all be explicitly conceived for new developers. The process started already. The observant can see the numerous efforts being made in this area. Will it be enough to attract new crowds? It is a hard bet, but I sure hope so because C# and F# are great languages, and NET 6 is modern, robust, feature-rich, and powerful enough to go at war, and with no fear.

The recording is in Italian and is available below here.

Listen to “Python, Eve, open source e fattura elettronica. Con Nicola Iarocci” on Spreaker.

This method returns the value associated with the specified key, if the key is found; otherwise, the default value for the type of the value parameter is returned (source)

The devil hides in details. TryGetValue returns the default value for the type of the value parameter. So, if you use TryGetValue to look into a dictionary of strings, null is returned on a missing key. That is probably ok in most cases. Howewer, if your logic requires a custom default value instead, then you are out of luck. You have to set it yourself on TryGetValue failure. A typical implementation would be:

    var result = MyDictionary.TryGetValue("key", var out value) 
        ? value
        : "not found";

It is a minor annoyance but still a hassle. Our solution has always been a homemade GetValueOrDefault extension method, something like this:

    public static TValue GetValueOrDefault<TKey, TValue> 
        (this IDictionary<TKey, TValue> dictionary, TKey key, TValue defaultValue)
    {
        return dictionary.TryGetValue(key, var out value) 
            ? value
            : defaultValue;
    }

Usage:

    var result = MyDictionary.GetValueOrDefault("key", "not found");

We’ve been using it since forever, and we are still using it even in recent projects.

Today, as I was looking at something only tangentially related, I learned that our extension method is obsolete, and it’s been for a while. NetStandard 2.1 and NetCore 2 added a new extension method to the official API. It’s called, you guessed it, GetValueOrDefault. It extends ÌReadOnlyDictionary<TKey, TValue>, so it applies to all generic dictionaries, which is cool.

We could continue with our extension method. It has the advantage of working across all .NET platforms, not just recent ones. Implementations are likely similar, and there’s probably little (if any) performance difference (I am too lazy to compare). With NETCore (now NET5), APIs have not only acquired cross-platform compatibility and improved performance but they have also been expanded and amended, something often not very apparent. Not to me, at least.

The point I want to make here, I think, is that nothing is set in stone. Today’s little event shows how my knowledge becomes stagnant over time. Setting apart the time to learn new things is good, but acquired ones need sharping too.

We don’t recommend using the SmtpClient class for new development because SmtpClient doesn’t support many modern protocols. Use MailKit or other libraries instead. (source)

Interestingly, Microsoft is recommending a third-party open-source library as an alternative. I hope we’ll see more of that in the future.

I just finished integrating MailKit in our backend. I must say that I’m pleasantly surprised by its rich feature-set and the elegant and straightforward design, which makes getting on-board super easy. It’s built on top of the excellent MimeKit, after all, and authored by the very same author Jeffrey Stedfast.