Await events

Some legacy API-s provide an event-based mechanism to achieve an asynchronous behavior. In this case typically a sync method starts a longer running async operation and an event notifies the consumer when the operation succeeds or fails.

For example, a hypothetical code below sends a message to queue and also subscribes an event for completion.

_queue.Completed += (sender, args) => // message is sent
_queue.Send(msg);

Code quickly gets complicated in case the caller wants to wait for the completion of the send operation. In more modern C# one would represent this operation with a Task. A Task could be then awaited at the call site:

Find out more


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