Frozen Collections

.NET 8 (Preview 1) introduces new collection types including FrozenDictionary and FrozenSet. Both types are frozen counterparts of Dictionary<TKey, TValue> and HashSet<T>. These types reside in the System.Collections.Frozen namespace in SystemCollections.Immutable.dll package.

The frozen semantics mean, that these collections resist to change once they become frozen: they are immutable. However, they are different to the existing immutable collections, as these are being even more restrictive to change. While immutable collections allow change by creating a new immutable collection frozen semantics discourage such operations. Immutable collections use 'clever' data structures in memory that make operations like Add and Remove (relatively) cheap given the underlying data may not change. Contrary, frozen collections can optimize for lookups (or for construction, but more on that later).

For example, ImmutableStack<T> uses a linked list implementation instead of using an array as backing data structure. It has two fields: a head which contains data stored by a user, and a tail which is a pointer to the next item on the stack. Pushing a new item to the stack creates a new instance of ImmutableStack<T> where the head field stores the new data pushed, and the tail references the previous instance of ImmutableStack<T>.

Note, that these are the actual field names in the implementation of ImmutableStack at the time of writing this blog post.

Find out more


Pooling IBufferWriter

In the .NET 7 area some high performance APIs offer overloads for dealing with raw data via IBufferWriter<T>. IBufferWriter is a contract for buffered writing. High performance APIs typically offer an overload of their methods with IBufferWriter<T> along with byte[], Stream or Memory<T>. However, this is not the case for every API.

IBufferWriter<T> offers three methods:

  • GetMemory() and GetSpan() get a piece of writable memory.

  • Advance() to notify the buffer writer that data has been written.

.NET 7 offers two implementations of IBufferWriter<T>: Pipe (via PipeWriter) and ArrayBufferWriter<T>. Pipes help to solve the problem of parsing high performance streaming data. ArrayBufferWriter<T> offers an array-based buffering solution by implementing IBufferWriter<T>.

Find out more


Protobuf Source Generator

I have recently faced a challenge where significant amount of custom types had to be serializable with protobuf-net. A requirement for the task was to avoid attributing all properties with [ProtoMember]. A solution to this problem is using C# source generators to generate partial types with properties that are serializable. Such a source generator is described below and implemented in LaDeak.ProtobufSourceGenerator nuget package and GitHub project.

A source generator that generates partial helper classes where member properties are attributed with ProtoMember attribute for serialization with protobuf-net.

Getting Started

Install nuget package:

Find out more


Output Caching gRPC is Bad Idea

In this post I investigate how to enable ASP.NET Core's Output Caching for an ASP.NET Core gRPC service. Primarily, this is done for the sake of curiosity. The concept, design and code below should be avoided in production grade applications.

Output Caching

Output caching is a new type of caching introduced with ASP.NET Core 7.0. It positioned between response caching and in-memory (or distributed) caching. With output caching the server responses are cached on the server. However, it gives less flexibility on choosing custom keys or caching strategy compared to in-memory caching provided by .NET runtime.

Output cache varying allows caching based on keys composed from query parameters, header parameters or by chosen value given the HTTP request. While output cache provides features like cache revalidation and cache invalidation, in this post I will not explore them in detail. Output caching is typically used for caching Razor pages, static HTML content, etc. in GET and HEAD HTTP requests. The default output caching policy behavior bypasses caching responses for authenticated requests or responses that sets cookies.

Find out more


Required Keyword

C# 11 introduces a new keyword: required. This keyword can be applied onto fields or properties to make them required to be set during initialization. In this post I will focus on using required properties.

In the past developers could create init properties that could be set only at initialization time by the type's constructor or object initializer. However, the compiler did not require the developer to explicitly set a value to a property.

Required properties make object initializers issue a compiler error when the developer does not set a required property.

In this post I will explore the following topics for required properties:

Find out more