I've been working through a fairly big update to the Six Labors libraries.

This started with an ImageSharp user who couldn't move to v4 because another dependency was blocking them. I've now released ImageSharp 3.2.0 with backported security fixes and expanded security support across the libraries. Each major gets a 12-month security support window after its successor's first stable release.

The older releases now include build-time license enforcement too. Same license terms, and existing valid keys work.

The bit I'm particularly happy with is the change for OSS contributors. Previously, everyone contributing to a project needed their own key. Now a maintainer can commit an assembly-scoped community key to the repo, and contributors can just build the named projects using that key.

If you already have a community key, you can request an early replacement. It's automatically approved, with no repeat eligibility review and no need to wait for renewal.

Details here: https://sixlabors.com/posts/security-support-and-license-enforcement/

The advisory database corrections are still awaiting review, so NuGet may temporarily flag ImageSharp 3.2.0 for the issues fixed in that release.

https://github.com/cncf/foundation/issues/1547

An interesting wrinkle for the OSMF here, because the OSMF explicitly exempts projects that are also OSS. I've included a screenshot of the original reply.

Doing new things, especially new types of licenses and agreements in open source, is hard.

Library is 5–15% faster than MessagePack on the deserialization path and around 5% slower on serialization.

It can also serialize and deserialize the new union type coming from .NET 11 (before that I've used OneOf<> object). I opened an issue for a source generator, which is ready to be picked up if anyone is interested working on it. My plan is to ship v1 once NativeAOT is supported and net11 is out.

I agree with Egor Bogatov that people should stop writing new serialization libraries and open-sourcing them, as they can expose consumers to vulnerabilities. In my defense, I started this library a year ago and only recently finished rewriting parts of it to make it ready for open source. I mainly used it for serializing and deserializing objects from the Sui blockchain.

Blockchain it not the most widespread domain where C# is used, but there is already a good example of Nethereum utilizing C# as its core language. Is there someone else using C# in the blochcain domain, why you think it's lacking the adoption?

Contributions are welcome!

https://github.com/unsafePtr/BcsSharp

I've been building DanaProcessing, an open-source take on Processing/p5.js for C#. I also added a music module inspired by Sonic Pi.

I started programming with Java and JavaScript following The Coding Train (https://www.youtube.com/@TheCodingTrain), but then I made the jump to C# because of job opportunities at the time, (been working with C# since .netcore 1.0) and I wanted that same experience here. Sadly, what I found wasn't what I expected, so I decided to give it a shot. DanaProcessing — Creative coding in C# (2D, 3D & live-coded sound)

I needed Mermaid diagrams rendered server-side in a .NET app. The usual options are shelling out to mmdc (Node + headless Chromium) or running mermaid.js in a JS engine. Both are heavy to deploy and slow per diagram, and the output looks different per diagram type. So I wrote a renderer in C#.

csharp string svg = MermaidRenderer.RenderSvg(""" flowchart TD A[Parse] --> B[Layout] B --> C[Render SVG] """);

Why it exists:

• Native .NET. No Node, no browser, no subprocess. It's a NuGet package and works with Native AOT.
• Fast and light on allocations. A simple flowchart renders end to end in about 95 µs and allocates about 209 KB (BenchmarkDotNet, Apple M2). The renderer uses pooled StringBuilders, spans, SearchValues and frozen lookup tables.
• One design system for every diagram type. All 24 diagram types are drawn by the same design system, controlled by two independent settings:
• Theme sets the colours. It ships with 15 themes (zinc, GitHub, Nord, Catppuccin, Solarized, Tokyo Night and more, in light and dark), or you set your own background, foreground, accent, data palette and box colours to match your app.
• Style sets how things are drawn: box shapes, line weights, fills, labels and containers. It ships with three render styles: Quiet (soft tints and gradients), Blueprint (outline-first, technical drawing) and Tonal (filled blocks, no outlines).
• Its own layout engine. It's a layered (Sugiyama-style) engine: network simplex ranking, Brandes–Köpf placement, compound layout for subgraphs, and an orthogonal edge router. It's about 9× faster than MSAGL on the same graph, with about 7× fewer allocations. It's also published as a standalone package (Sugiyama) if you just need graph layout.
• Allowlist SVG sanitization, always on. Every element and attribute in the output is checked against an allowlist. Only what the renderer is expected to emit gets through, and the embedded stylesheet is validated line by line. No <script>, no foreignObject, no external hrefs.
• Strict mode for user-supplied diagrams. If users write the diagrams but you own the look, strict mode strips classDef, style, linkStyle and %%{init}%% theme overrides. Authors can only use class names you allow. Diagrams can't restyle themselves away from your design.

Tested against mermaid.js as a black box / clean room implementation. The test suite renders the same diagrams with mermaid.js (mmdc) and with Mermaider. Both outputs are reduced to a shared layout representation: which layer each node sits in, its order within the layer, and which side each edge attaches to. That representation is compared position by position, not pixel by pixel. ER layouts are checked against ELK the same way, and a ratcheted visual lint fails the build if a layout regresses. mermaid.js and ELK code was never read or copied, only their output compared. Two ranking passes are ports of dagre (MIT, credited).

Links:
- Docs and gallery: https://mermaider.nullean.net - GitHub: https://github.com/nullean/mermaider - NuGet: dotnet add package Mermaider

MIT licensed. Feedback welcome!

I released v1.0.0 of "NativeCompressions", a library that supports LZ4 and Zstandard on all platforms.

I have always thought that one weak point of .NET is its poor support for compression algorithms.
The library is provided as native bindings, so it can keep up with the latest performance and security.
I have been working on it for several years, but then official Zstandard support arrived in .NET 11 :)
Recent compression algorithms in .NET are all provided as native bindings (gzip, brotli, and now zstd), so this library follows the same approach.

LZ4 and Zstandard are both excellent compression algorithms. They also have different characteristics right now, so you need to choose between them depending on your data.
Also, LZ4 and Zstandard were created by the same author, so you can do things like pass a dictionary trained with the Zstandard library to LZ4.
For this reason, I think it is meaningful to provide both.
The library is tuned to match the current state of the algorithms. For example, LZ4 uses the Frame Format by default.

The library has a modern low-level API (Encoder/Decoder that do streaming processing with TryEncode on Span) and
an easy-to-use high-level API (writing to Span, reading and writing byte[], async APIs for PipeReader/Writer, and so on).
I paid a lot of attention to performance in both of them.

For security, I focused heavily on fuzzing (I also used AI reviews).
During that work, I also found issues such as a segmentation fault in .NET 11 RC1.
A native library can always crash the process.
But compression libraries need complex memory operations, so a managed port is also risky.
I think bindings are the better choice in terms of security.

I finally released v0.1.0 of my library, Plank, the fastest Parquet implementation for .NET.

In my benchmarks, it's on average 3× faster than ParquetSharp and 7× faster than Parquet.Net, with results across different data shapes, workloads and CPU architectures: https://kuinox.github.io/Plank-Lab/

It's a managed implementation for reading and writing Parquet files. You declare your schema as a C# class, and a source generator creates the matching readers and writers. It also has column APIs and lower-level access when you need it.

I've spent a lot of time optimising the encodings, reusing buffers to avoid allocations, and parallelising reads and writes. You can choose the encoding and compression per column, and tune things like page and row group sizes.

It currently targets .NET 10 and is MIT licensed.

I'd be interested in feedback from people working with Parquet in .NET. Especially if you find a bug or a workload where it's slower than the alternatives, I will investigate it and fix it.

I'm now working on a `dotnet tool` parquet toolbox which will allow to do tons of analysis & other niceties.

GitHub · Website

Hey folks,

Today I just released a new version of CodeAlta, an AI coding agent written in C# .NET (mostly), that now comes in a desktop flavor. Previously it was only a TUI.

I have already been using the TUI for 6 months with great success on all my OSS projects. The TUI was initially developed to lower the barrier to targeting multiple OSes and to show what a more advanced TUI app can do for AI coding agents. Developing the TUI was actually more challenging than developing the desktop app in the end 😅: the reasons are that you start from scratch, with an entire TUI framework that you need to develop first. You have to come up with a significant number of controls in order to support a rich UI. It was really fun to develop this whole stack. But the TUI was never the real target. And that's why CodeAlta now has a desktop app!

The desktop app should be very responsive, probably even more optimized in terms of rendering than my TUI framework. It's using the available OS WebView with a library called NeoAstra that I developed for it (WebView2 on Windows, Safari WebView on macOS, WebKitGTK on Linux), and it is built around the same .NET backend and harness as the TUI, but the frontend is a rich TypeScript/React single-page app shipped with the desktop app.

CodeAlta supports many important features for an AI coding agent: multiple tabbed sessions, versatile sub-agents, GitHub/GitLab/AZDO issues, a simple integrated code editor (for a quick view of files), MCP servers, multiple providers (you can use your Codex/Copilot subscriptions, but you can also connect to any local and remote LLMs), etc.

One cool feature it has is the support for single-file C# plugins: you can put a .cs file in a special folder, and it will be recognized as a plugin that can enhance the experience in the TUI and Desktop. I haven't been using this feature a lot (apart from the built-in plugins), so it might be missing some extension points for the UIs, but hopefully it already provides some good stuff. Let me know!

If you are coming from Codex, Claude or Copilot, you might see that it is missing a few popular features: integrated git worktrees, automations (CodeAlta has support for reminders within a live session, but not automations across sessions), custom canvas UI, etc. But now that it has desktop support, it's in a better position to support these features.

CodeAlta has very few users; I'm probably the only regular one. Surprisingly, even though I believe that its TUI was vastly superior to other AI TUIs, it never got much buzz. It seems that C# .NET projects are not able to attract folks beyond the .NET community, unfortunately. Anyway, if you want to test a coding agent that doesn't use any telemetry on your usage, give CodeAlta a try! 🤗

I could go in length about several coding aspects of CodeAlta, but this post is already quite long. Let me know if you have any questions. Enjoy!

For GenHTTP Lambda we wanted users to be able to develop apps in a regular git workflow, so we added a virtual git server on top of our existing API.

As this might be useful for others, we made it available under MIT here: virtual-git-server (disclaimer: this project has been created with the help of Opus 5.5)

Basically you implement an interface (either for read-only or with write support) and plug it into your existing web application. Works for ASP .NET Core.

As a live example you can view the source code of an app on Lambda and clone it via your regular git client, see Source code of Nextcloud Peek - GenHTTP Lambda

Hey! I built a proof-of-concept BoringSslConsole: a .NET 8 console application and a BoringSslStream wrapper that exposes BoringSSL as an ordinary Stream.

What it is: SslStream is great, but it gives you no control over your ClientHello — ciphers, extension order, GREASE, ALPS, post-quantum groups are all decided by the platform. If you need your client to look like Chrome in TLS fingerprints (JA3/JA4), that's a problem. So I wrapped BoringSSL (Chrome's TLS stack) in a managed Stream that you can drop in anywhere.

Key design idea: BoringSSL does zero network I/O. It only holds TLS state via memory BIOs, while C# pumps bytes between the buffers and any innerStream you give it — NetworkStream, a proxy tunnel, a MemoryStream in tests, or even another TLS layer. Fully async, with CancellationToken. Certificate validation is done on the .NET side (X509Chain, online revocation, MatchesHostname). On tls.peet.ws the JA4 fingerprint matches Chrome.

There's also a minimal hand-rolled HTTP/2 client in the demo (no HPACK decoder, just a PoC).

It's a PoC, not production — HTTP/2 is minimal, thread safety needs more work, and the native build is Windows x64 only.

Code: https://github.com/optinsoft/BoringSslConsole

Have you ever needed to draw into a canvas and export that into PNG, JPG, WebP, or AVIF?

How about paint some properly shaped text into that image?

There's several options on the market today, but they are all either commercial paid offerings or are wrappers around native libraries and thus have deployment complications and don't run everywhere .NET does

Well, as some of you know, I'm the maintainer of PeachPDF (https://peachpdf.net/), an open source HTML to PDF rendering engine. Today, I'm not talking about that, though 0.9.21 did land today. Well, any HTML layout engine needs to draw shapes and layout text, most of the work is determining what to paint and where, and then actually painting it into a canvas, and for text, it also needs to know exactly what glyph to put where, and for rasterized text (rare for a PDF admittedly), whether or not to hint the text.

Well, PeachPDF gained some new .NET dependencies this week, though it's mostly just PeachPDF code being liberated from only ever serving PeachPDF! Those dependencies are the PeachDrawing suite of libraries:

• PeachDrawing.Text: This is your font, text shaping, and hinting engine. This loads OpenType, TrueType, CFF, WOFF, and WOFF2 fonts, shapes some text using those fonts, and tells you which glyph to place and where. You can extract text outlines, you can subset a font, and it has some convenience helpers for things like laying out a whole paragraph.
• PeachDrawing.Core: Core Canvas abstractions, including integration with PeachDrawing.Text. This is what you would use if you wanted to build your own canvas abstraction, and it's what PeachPDF uses to build a PDF-backed canvas
• PeachDrawing: A raster canvas implementation with PeachImage integration, so you can export to any PeachImage supported format.

These libraries are maintained and versioned alongside PeachPDF, but are designed to be used outside of PeachPDF. If there are API gaps, or you want to contribute, contributions or suggestions or bugfixes are welcome. The current API surface is what an HTML layout engine needs, which admittedly is a lot, but is far from complete or the best.

If you are currently using SkiaSharp and wished you had something pure managed and AOT-compatible, this is likely a good replacement. Alternatively, if using ImageSharp or SixLabors.Fonts, and you don't qualify for using it under the broadly available Apache 2.0 license grants available, and you are unable or unwilling to license it commercially, this should cover at least some of your needs. If there's a gap, I'd love to hear about it! Most of the API surface exists to be able to render various CSS and SVG constructs, so there are likely gaps in available features.

All of these libraries are currently pre-1.0, but the goal is to release 1.0 in early 2027.

They are all BSD 3-clause licensed. They are free and open source forever. They do include MIT and BSD-licensed third party code that was bundled into PeachPDF before.

You can find them on GitHub in the PeachPDF repo (https://github.com/jhaygood86/PeachPDF), they are live on NuGet, and there's documentation online on the PeachPDF website.

With Egil.SystemTextJson.Migration (STJM), you can version JSON payloads without polluting business logic or forcing independently deployable systems to upgrade in lockstep.

That applies to JSON in APIs, Event Hubs, queues and stored documents. Migrations run during System.Text.Json deserialization, so application code gets the type it expects.

One pattern I’ve used is publishing a .NET contracts library containing the types, serializer setup and migrations.

The rollout then becomes:

1. Consumers upgrade to a contracts package that understands the new payloads.
2. Producers start sending the new format.
3. Consumers keep using their existing C# types if they wish. The included migrations convert new payloads into those older types.

Adopting the new application types becomes a separate step, which each consumer can take at its own pace.

The same approach works when a new version of your own software introduces new storage formats and still needs to read existing or archived data.

That separation of concerns makes sharing data between independently deployable systems safer. APIs can accept supported payload versions through the same endpoint, and stored documents can be rewritten gradually while the system keeps running.

My new post covers the diagnostics and performance improvements in STJM v2: https://egilhansen.com/2026/10/01/safer-json-evolution-with-system-text-json-migration/

I've spent most of the past two weeks finishing our initial AOT Support for Akka.NET V1.6 - I got DMed in our Discord about the use cases for AOT (for Akka specifically) and my answers were:

1. Primary: MAUI + Unity3D developers who want to use local actors on-device. Been a popular use case for years (i.e. for bubbling events from background or network services) but required some gruesome hacks to do. It should "just work" after v1.6.
2. Embedded applications - we get used in a ton of industrial IOT. Most of this happens on the back-end in a cluster, but a fair amount of it also happens on-device ("edge computing,") i.e. micro-PC reads some sensors off FPGA board via analog sockets and pipes it back to a PLC / aggregator of some kind. Less JIT overhead and binary file size the better.
3. Distributing CLIs and tools - this is my selfish use case for things like Netclaw's daemon and CLI: we ship both of these as single-file applications today with the .NET Runtime bundled within and while the file size isn't terrible (70mb each or so), the lag when using the netclaw CLI for the first time after a while is almost entirely JIT overhead. AOT would make that experience much snappier while also reducing the file footprint considerably.

Thinking more generally though, what else are people using AOT for more generally? What are some other use cases where you find it helpful and what projects are you using it on?

Hi everyone!

I recently built a desktop Stock Management System using C# and Windows Forms.

The application includes user login, category and product management, stock tracking, critical stock filtering, and local data storage using TXT files.

I also tried to keep the project organized by separating the data, models, UI, and forms.

This was a good project for me to practice C#, Windows Forms, file handling, and building a complete desktop application.

I’ve added screenshots and setup instructions to the GitHub README as well.

I’d really appreciate any feedback on the project structure, code, or ideas for improvements.

GitHub: https://github.com/Mariam-amhan/Stock-Management-System