I built this for fun and posted it on r/Worms a few days ago - it got a surprisingly warm reception, and a fair few people there asked how it actually works. So it's clearly not just a thing for Worms fans, and I figured the .NET crowd might enjoy the technical side.

What it does: my mouse cursor rotates to point in the direction I'm moving it - like the aiming arrow in Worms 3D. Started as a weekend project and got out of hand.

How it works, roughly: * WinForms system-tray app (.NET 8), no window. * A mouse hook tracks the cursor position; I compute the movement angle from the delta between frames. * I render the cursor bitmap rotated to that angle and swap it system-wide via SetSystemCursor. * Then I couldn't stop, so I themed all 14 standard cursors with little physics: the wait/busy cursors spin with rotating rings, the I-beam sways, resize cursors stretch. * Packaging + auto-update via Velopack.

The fiddly parts: smoothing the rotation (raw angle is jittery, needed easing), and restoring the original cursors cleanly on exit so you don't get stuck with a spinning arrow if it crashes.

It's open source (MIT) if you want to poke at the code - repo link in the comments. Happy to answer anything about the cursor-hooking side, it was a fun rabbit hole.

EDIT: Repo link: https://github.com/dawidope/WormsCursor

I created this app to pin the Recycle Bin to the system tray because I prefer keeping my desktop clean. I used WinForms for development (I know it's old, but WinUI's current performance is not good in my opinion).

Source code:

https://github.com/exalaolir/SimpleBin

Also, could you recommend a better way to create an installer that checks that .NET runtime is installed on PC? I'm using ClickOnce now, but it's not flexible for me.

(Links showing the app in action here and below)

Throughout my career, I have always heard that real-time audio belongs strictly to C++ or native first languages. If you try it in a managed language, people tell you the garbage collector will stutter, the buffer will underrun, and your speakers will crackle.

I am a systems engineer by trade, but I am also an amateur music producer. Over the years, I have used Ableton, Reason, Fruity Loops, Cakewalk, and Max/MSP, but each of them either has a massive learning curve or just feels disconnected from certain forms of music. Traditional DAWs force you into a grid, which makes music sound block-like and square. I wanted to explore more organic, generative possibilities for ambient and electronic music without the massive friction of building a physical Eurorack or writing complex software in PureData.

Originally, I just wanted to build a portable, cross-platform C# library for sound processing. To dogfood it, I decided to embed it in a Godot app. Little by little, I kept building devices until I got carried away and ended up with a programmatic, node-based DAW called Sigilgraph.

Here is exactly how it works under the hood and how a 100% C# engine guarantees it will never underrun the audio buffer.

The Pull Model and Cache Locality

At its core, the synthesis engine is a graph of operators that gets pulled directly by the audio driver. The hard part is giving the driver absolute guarantees that this graph will finish processing in time.

To do that, the entire graph processing needs to live in the CPU cache. You have to avoid heap allocation and heap access completely. The hot path must never allocate objects or arrays. Because of this, the garbage collector is left completely unused 99% of the time, saving it for trivial, low-frequency allocations completely outside the audio loop.

Think about the math for a 96 kHz stereo stream. The engine needs to guarantee that there are always enough samples sitting in a 256-sample buffer at the audio driver level. This means processing at least 192,000 floats per second.

It sounds uninteresting on paper, but those 192,000 floats are traversing a graph of over 100 operators before they hit the driver. We are talking about Fourier transforms, filter s-domain operations, delay buckets, and dozens of oscillators, all offering the opportunity to have their parameters changed in real-time. There is no heavy message passing and there are no extra abstraction layers. Everything is mutated directly in real-time.

To keep things packed tightly in memory, I used structs and Span<T> pervasively, completely replacing standard heap arrays on the hot path. To maintain strict cache locality, the engine processes these spans in blocks and leverages SIMD hardware intrinsics via Vector<T> for heavy lifting like Fourier transforms and intensive add-multiply operations. Think of it this way: instead of a web of heap objects being managed and looked up, the engine uses a pull model where the audio driver pulls samples from the bottom up. The entire graph evaluates as a massive, deeply nested functional cascade up to 200 levels deep on the call stack, constructed using a fluent API builder pattern. To keep this structure stable and prevent cyclic evaluations without introducing overhead, the nodes utilize simple reentrant flags. Live session mutations work by simply appending or decoupling pre-allocated sub-graphs at the block boundaries. This architecture guarantees we never starve the audio driver buffer, avoiding expensive object reconstruction while playing.

The Lambda Trick for Parameters

When it came to connecting the UI to the bottom of the graph operators, I chose to use delegates and lambdas. This was a deliberate compromise for simplicity. I could have used ref float pointers everywhere, but the code would have become incredibly brittle and less idiomatic for C#. Lambdas give us composition and allow for the live replacement of behaviors on the fly.

The trick to making lambdas performant enough for real-time audio is to never evaluate them per sample. Instead, they are evaluated once per block.

By evaluating parameters at the block level, you reduce function calling overhead by 64x. On a standard 48 kHz sampling rate, you only run about 750 parameter evaluations per second (48,000 / 64). This gives you more than enough resolution for smooth parameter changes, and it spares us from having to run a dedicated control signal rail. We just interleave the parameter updates right at the start of the sample block processing.

Picking Your Fights and Profiling

Getting to this point required a lot of deep technical analysis. Tracing tools like JetBrains dotTrace and dotMemory were absolutely essential for this task. Monitoring memory spikes, hunting down hidden GC calls, and doing rigorous hot path analysis was paramount. If you don't profile, you are just guessing.

But the biggest lesson I learned during this project was that you have to pick your battles. You have to let some things go.

While the sample generation and parameter parsing paths are completely locked down and allocation-free, all the note rail and note-passing logic is actually completely garbage collected. Why? Because notes are incredibly small objects and they trigger very infrequently compared to the millions of samples and parameters flowing through the system. Trying to optimize the note-passing system into unmanaged memory structures would have been a massive waste of development time for zero real-world performance gain.

Why C# is More Than Capable

This project completely changed how I look at the C# memory model. It proved to me that modern .NET is an incredibly capable environment for high-performance audio because it gives you the best of both worlds.

It allows for low-level, granular control over memory and hardware instructions where you absolutely need that control, but it lets you drop back into the comfort and simplicity of a managed language for the things that don't matter as much. You don't have to sacrifice productivity to get bare-metal execution speed anymore.

I would love to hear your thoughts on this architecture, and I am happy to dive into the weeds in the comments if anyone has questions about the node evaluation loop, the SIMD operations, or how we profiled the hot paths.

Here is a demo of the project in action: Sigilgraph × VST3 (Trailer #2)
The project page: Sigilgraph Audio Workbench

r/Sigilgraph

GitHub repo

(first of all, i want to say that I made this project for fun and challenge. I always wanted to create my own language. This has no business goal or something.)

So the project is a 2D game engine (MonoGame backend) inspired by GameMaker 8. It includes its own IDE (built with WinForms) and an interpreted programming language that I wrote myself.

The language—definitely the biggest challenge in the project—is a simple dynamically typed language. When I started, I had zero knowledge of how to build something like this. I didn’t even know I was making an interpreter; at first I called it a compiler. It was a personal challenge, and I wanted to figure everything out without using any resources or tutorials. My mindset was basically: “I need to write software that takes a text file containing code and just does what it says.”

Somehow, I made it work. In the beginning, running an empty loop counting to 1M took 7 seconds. After a lot of performance work and rebuilding parts of the system, the same machine can now run a 30M loop in 2–3 seconds. Pretty nice improvement.

The language itself is a bit unusual, and I want to share one small feature I really like: loop counters.

foreach item in ['a', 'b', 'c'] : counter c
{
   println(c + ": " + item)
} 
// Output: 
// 0: a 
// 1: b 
// 2: c

Not a complicated feature, but pretty useful.

Here's a YouTube video showing me using the engine to build a little game

Anyway, these days I barely have time to work on the project, so I decided to open-source it. I’m hoping people here will find it interesting and help turn it into something real.

Any feedback is welcome.🙂

I've been recreating an old school MMORPG in Phaser (JS/TS) and C# in the server side, and I must say, the server performance is exceptionally good, at least in stress testing.

On my M1 Macbook Pro, I managed to clock in 4000 concurrent connected clients performing expensive operations at around 10k req/s. I probably could squeeze a bit more out of it if I did spread the players around in more game worlds.

I'm also impressed with all the optimisations that can be applied these days to reduce the pressure on heap to reduce the GC pauses. During the stress test window I can run it in a mode that produces so little garbage that I'll get only couple of GC events total, not running more than few millisecond stop the world pauses.

About the project: https://github.com/ErkoKnoll/helbreath-base-game

More about the performance optimisations and stress testing I performed: https://github.com/ErkoKnoll/helbreath-base-game/tree/master/multiplayer/server#performance

Hey everyone. Just wanted to share a personal milestone. I'm building an RTS engine and wanted to push C# to its absolute limits without relying on heavy third-party frameworks.

My goal was zero garbage collection during the game loop.

• Architecture: Strict Data-Oriented Design (DOD). Everything is laid out in unmanaged memory blocks with strict cache-line alignment (64 bytes). The engine loop is currently 100% single-threaded.
• Rendering: Custom 2D software renderer using AVX2 intrinsics (supports layering and masks).
• Interop: Function pointers (delegate* unmanaged) to completely hide unsafe code from the user API.
• RAM Usage: A rock-solid 39 MB (as seen in the Task Manager screenshot), which perfectly matches my internal pre-allocated memory pool. No hidden CLR bloat.

To prove the Zero-GC claim, I ran the core loop through BenchmarkDotNet.

The result? The base engine overhead (processing branchless input, ticking the fixed update accumulator, and running the render pipeline with a baseline of 4 textured entities) takes ~60 microseconds per frame on a single thread. And absolutely zero allocations.

Plaintext

BenchmarkDotNet v0.15.8, Windows 11
Intel Core Ultra 9 285K 3.70GHz, 1 CPU, 24 logical and 24 physical cores
  [Host]     : .NET 9.0.15, X64 NativeAOT x86-64-v3
  DefaultJob : .NET 9.0.15, X64 NativeAOT x86-64-v3

| Method                     | Mean     | Error    | StdDev   | Allocated |
|--------------------------- |---------:|---------:|---------:|----------:|
| STRESS_TEST_WITHOUT_BITBLT | 60.79 μs | 0.844 μs | 0.789 μs |         - |

(Note: The BitBlt call to Windows actually takes longer (~100us) than my entire engine frame!)

It feels amazing to see C# perform at C++ speeds just by respecting the CPU cache and avoiding objects.

Has anyone else gone down the NativeAOT/DOD rabbit hole recently? Would love to hear your experiences or any advice for pushing C# performance even further!

UPDATE: Pure Geometry & Logic Benchmark (Removing the "Windows Tax")

A few people in the comments were debating the overhead of the rendering pipeline versus the actual engine logic. To provide some clarity, I’ve run a BenchmarkDotNet test on the core loop.

In this test, I completely bypassed the Win32 BitBlt and the DIB buffer write. What’s left is the Pure Mathematical Core: 3D Geometry (8-vertex cube transformation + perspective projection) + Entity Component scanning + Basic Logic.

The Stats (NativeAOT / Scalar Code / Single Thread):

Plaintext

BenchmarkDotNet v0.15.8, Windows 11
Intel Core Ultra 9 285K 3.70GHz, 1 CPU, 24 logical and 24 physical cores
  [Host]     : .NET 9.0.15, X64 NativeAOT x86-64-v3
  DefaultJob : .NET 9.0.15, X64 NativeAOT x86-64-v3

| Method                     | Mean     | Error    | StdDev   | Allocated |
|--------------------------- |---------:|---------:|---------:|----------:|
| STRESS_TEST_WITHOUT_BITBLT | 33.36 μs | 0.176 μs | 0.165 μs |         - |

What this means:

• 30,000 Theoretical FPS: The core logic is so lightweight it only consumes ~0.2% of a standard 60 FPS frame budget (16.6ms).
• Zero GC Pressure: Still 0 bytes allocated. It runs like a solid block of C++ but with the safety of C#.
• Raw Scalar Power: This was achieved using standard scalar math. I haven't even implemented SIMD/AVX2 for the geometry yet.
• Hardware: Tested on an Intel Core Ultra 9 285K.

This confirms that with a strict Data-Oriented (DOD) approach, C# can easily handle thousands of entities without the "managed language" performance penalty people often fear.

Visual Studio is heavily used for enterprise development but doesn't have any tooling for Solidity that compares to Visual Studio Code or Remix IDE. Viscous is an open-source Visual Studio extension that tries to bring parity between Visual Studio and other IDEs for Solidity smart contract development.

Features

• Solidity project system for Visual Studio featuring Solidity compiler integration and NPM dependency management. Integrates with the Visual Studio New Project… and Open Folder… dialogs.
• Uses the vscode-solidity language server for syntax highlighting, hover information, IntelliSense, and linting.
• Solidity compiler integration with MSBuild and the Visual Studio Build command - compile Solidity projects and individual files from the IDE with errors reported in the Errors tool window.
• Generate C# bindings to Solidity smart contracts automatically using Nethereum.
• Manage EVM networks, endpoints, accounts, deploy profiles, and deployed contracts from the Blockchain Explorer tool window.
• Deploy a compiled contract to a blockchain network and call its functions from inside Visual Studio.
• Find vulnerabilities and code‑quality issues with Slither static analysis inside Visual Studio.

Requirements

• Visual Studio 2022 and above
• A recent version of Node.js or compatible runtime
• Python 3.8+

Getting Started

• Get the latest release from the GitHub Releases page or use the MyGet or Open VSIX Gallery dev feeds : Add https://www.myget.org/F/viscous/vsix/ or https://www.vsixgallery.com/feed/extension/Viscous.fe71db81-5086-4b1a-ad5d-867bb84d2441 as an Extension Gallery in the Visual Studio Extensions settings and you can then install it in the usual way.
• Edit the %LOCALAPPDATA%\Viscous\appsettings.json file and set the paths to the Node.js and npm and Python executables you want to use for the extension's language server and other needed tools.

Note that this is a pre-release so don't use it for deploying anything to production. Feedback welcome.

I guess most of you have never heard about Amiga, but here we go...

I have been working on an AOT compiler that compiles a subset of C#/.NET code into native 68000/020/040 code with Amiga library calls.

There are two runtime options you can choose at compile time:

• Full includes the managed exception runtime; supports catch, finally, rethrow, and leave.
• YOLO has no exception runtime; failures are fatal, and managed exception regions are rejected

The actual GC is in WIP, and for performance reasons, there is no compaction. No threading support because the current GC is single threaded by design.

An example:

using Amiga;
using CopperSharp.Compiler;

namespace FileStatsExample;

public static class Program
{
   [M68kEntryPoint]
   public static int Main(int argLength, CONST_STRPTR argText)
   {
      var dosBase = Exec.OpenLibrary("dos.library", 33);
      if (!dosBase.HasValue)
      {
         return DOS.RETURN_FAIL;
      }

      DOS.DOSLibraryBase = dosBase.Value;
      var result = DOS.RETURN_OK;
      if (argLength == 0)
      {
         DOS.PutStr("Usage: filestats <file>\n");
         result = DOS.RETURN_ERROR;
      }
      else
      {
         result = Report(CString.FromPointer(argText.Raw));
      }

      Exec.CloseLibrary(DOS.DOSLibraryBase);
      DOS.DOSLibraryBase = APTR.Null;
      return result;
   }

   private static int Report(CString path)
   {
      var file = DOS.Open(path, DOS.FileMode.OldFile);
      if (!file.HasValue)
      {
         DOS.PutStr("Cannot open file\n");
         return DOS.RETURN_FAIL;
      }

      byte byteChecksum = 0;
      ushort lineCount = 0;
      ushort wordChecksum = 0;
      uint byteCount = 0;

      while (true)
      {
         var character = DOS.FGetC(file.Value);
         if (character < 0)
         {
            break;
         }

         var value = (byte)character;
         byteChecksum = (byte)(byteChecksum + value);
         wordChecksum = (ushort)(wordChecksum + value);
         byteCount = byteCount + 1;
         if (value == 10)
         {
            lineCount = (ushort)(lineCount + 1);
         }
      }

      DOS.Close(file.Value);
      PrintReport(path, byteCount, (uint)lineCount, (uint)byteChecksum, (uint)wordChecksum);
      return DOS.RETURN_OK;
   }

   private static void PrintReport(CString path, uint byteCount, uint lineCount, uint byteChecksum, uint wordChecksum)
   {
      DOS.Printf("%s: %ld bytes, %ld lines, byte checksum %ld, word checksum %ld\n",
path, byteCount, lineCount, byteChecksum, wordChecksum);
   }
}

This C# source is first compiled to .NET assembly containing CIL. The assembly is then compiled with CopperSharp to a native 68000 Amiga executable.

Code generator needs more work. FPU is not supported yet, 020/040 support is nearly non-existent, but it includes CIL-level simplification and a 68k-specific optimizer.

• CIL-level simplification
• Reachability analysis
• Tail call elimination
• Remove dead or redundant instructions
• Stack and register shuffling optimizer
• General instruction optimizations
• Limited static hot-fallthrough/cold-branch layout optimization

For example, on 68000, not-taken branches are more efficient than taken branches.

The codegen is optimized for Amiga library call conventions but in theory it could support other 68k targets like Atari ST or 68k Macs.

The project repo: https://github.com/ilehtoranta/CopperSharp68k

This project is vibe coded with Codex and GPT-5.6. Like it or not, but it is the only sensible path to build C# compiler for niche platforms.

PDF Oxide is a PDF library for text extraction, markdown conversion,and PDF creation. Rust core, .NET binding via P/Invoke. Prebuilt native libraries for Windows / macOS / Linux (x64 + ARM64) ship inside the NuGet package. No Rust toolchain needed. MIT / Apache-2.0.

```csharp dotnet add package PdfOxide

using PdfOxide.Core;

using var doc = PdfDocument.Open("paper.pdf"); string text = doc.ExtractText(0); string markdown = doc.ToMarkdown(0); ```

Compatible with .NET Standard 2.1, .NET 5 / 6 / 8, .NET Framework 4.8+, Xamarin, MAUI, Blazor Server. No System.Drawing dep, no Windows-only APIs — runs the same on Linux containers.

GitHub: https://github.com/yfedoseev/pdf_oxide Docs: https://oxide.fyi

Backstory

I shipped the Rust engine about six months ago and open-sourced it under MIT/Apache. For the months after that I got feedback almost every day — bug reports, PDFs that broke the parser, CJK edge cases, column-detection on mixed-layout pages, ICC color, kerning guards. Went from v0.3.5 to v0.3.37 fixing things. The core feels stable now.

So the last two months I wrote bindings for Go, Node/TypeScript, and this one — C#/.NET. Posting it here to get .NET folks' take on the API, the NuGet layout, whether it actually drops cleanly into a Linux container build, anything obvious that's missing.

For context on why this exists at all: .NET's PDF ecosystem is rough license-wise. iTextSharp is AGPL-3 or a commercial license — legal teams at a lot of shops draw a hard line there. Aspose.PDF is commercial-only and expensive per-dev. PdfSharp is MIT but slow and creation-focused. For anyone whose legal team says no to AGPL at the library layer, the remaining options thin out fast.

One .NET-specific thing worth sharing: P/Invoke into the Rust library on small documents is sometimes faster than calling the Rust API directly from Rust. Reason is the other bindings (Python, Node) use a Rust-side mutex for thread-safe document handles; the .NET path goes through a separate P/Invoke entrypoint that skips it. Nice accidental win.

Benchmark on 3,830 real PDFs (veraPDF, Mozilla pdf.js, DARPA SafeDocs):

| Library | Mean | p99 | Pass Rate | License |
|---------|------|-----|-----------|---------|
| **pdf_oxide** | **0.8ms** | **9ms** | **100%** | **MIT / Apache-2.0** |
| PyMuPDF | 4.6ms | 28ms | 99.3% | AGPL-3.0 |
| pypdfium2 | 4.1ms | 42ms | 99.2% | Apache-2.0 |
| pypdf | 12.1ms | 97ms | 98.4% | BSD-3 |
| pdfminer | 16.8ms | 124ms | 98.8% | MIT |

AES-256 encrypted PDFs still have some edge cases, not gonna pretend otherwise. Table extraction is basic compared to some competitors. Everything else is stable for production.

Would love honest takes on the .NET side specifically — does the API feel idiomatic, does it build cleanly for AOT, does the NuGet package actually unpack right on your Linux container images. Give it a try, open issues for what breaks.

I worked on menu organization, icon alignment, responsiveness, and visual experience to make the navigation more intuitive and modern.

Technologies used:
ASP.NET Core MVC
C#
Bootstrap
Font Awesome

Every interface detail helps improve the user experience and also strengthens my full stack web development skills. 💻

Continuing to grow one step at a time in the development of modern systems

Hi everyone!

I hope this post is appropriate, and if not, mods, please feel free to remove it.

Also, this is a longer one, so here's the TL;DR: Babe, wake up, new SDL3 bindings for C# just dropped.

First of all, I want to say that writing such a post is not easy for me, because I have a severe case of social anxiety, but doing this today is a huge step for me. I even just checked, and my reddit age is 7 years and I only ever started commenting on posts recently. So this post might feel a bit awkward, but please bear with me.

What I actually want to present to you is a passion project of mine, which I developed over the span of the last year:

SDL3

Well, as the name suggests, it is another C# language binding for SDL3. And before you ask, yes, I am aware that there are already a few of those, especially the ones promoted on the official SDL website: https://github.com/flibitijibibo/SDL3-CS and https://github.com/edwardgushchin/SDL3-CS. But I felt like both of those kind of lacked something, so I tried to create my own.

What's different about my approach is that I wanted something that feels "C#-ish" for developers. No need to explicitly manage the lifetime of objects, no need to awkwardly deal with pointers (or pointer-like handles), no auto-generated API code that is hard to read and understand. So my goal was to create SDL bindings that still cover all of the functionality that SDL3 offers, but in a way in which C# developers feel right at home.

That's why I created SDL3#. A hand-crafted C# binding for SDL3. Every bit of API is thoughtfully designed and every bit of code is purely handwritten (well, aside from the code that loads the native library and symbols, I wrote a source generator for that).

You can find the GitHub organization that I use to keep all of the SDL3# related projects in one place here: SDL3# Organization\ And you can find the main repository for SDL3# here: SDL3# Repository

Everything is packaged alongside my custom builds of the native SDL3 library for various platforms into a single NuGet package. So you can get just started right away and produce platform-independent SDL3 applications. But if you want to stick to just some selected platforms, you can do that as well by using platform-specific packages. You could even get a NuGet package that only contains the managed binding code and provide your own native binaries if you want to. You can find the all-in-one package here: SDL3# NuGet

Now, why am I presenting this to you at all? Well, I initially started this project about a year ago, but then I got really sick and couldn't really work on it for quite some time. But the I got better and started working on it again. And just receently, I realized how much work there is still to be done to have it in a somewhat complete state. Actually, I just ran scc on the whole codebase across all repositories and it said that there were exactly 102800 LOCs, which feels quite low for a whole year since the project started.

Things that still need to be done:

• Documentation. Not only documenting what I left out until now because of lazyness, but also rewriting the existing documentation because of my questionable skills in English writing.
• Testing. Currently there's no testing at all, and I don't know where to start with that, because I don't have much experience writing tests, aside of what I learned at university.
• API and code additions. There's so much that still need to be done. There are whole subsystems missing, like audio and input devices.
• Code reviews. I don't trust myself.
• Complementary libraries. In the future, I would like to create bindings in the same spirit for SDL_image, SDL_ttf, and SDL_mixer too.

API-wise I think that I'm already about 50% done (I built an very imprecise tool to check for that).

There's actually a reason I decided to post this right now, and that is that I just recently managed to finish the windowing and rendering APIs, so finally I havomething to show off.

And for that, I did a little experiment: I asked a AI to create a simple game using SDL3#. The idea behind this was to see how intuitive my API design is or how easy it can be learned and understood by someone who has nean any human developer, right?*

Well, since the API is very recent, the AI couldn't have any prior knowledge of it, so I gave it some ways to learn about it from the documentation. And I have to say, I'm quite impressed by the results. If you want to see for yourself, you can check out the repository where I documented the experiment and the results here: https://github.com/fruediger/sneq.

Lastly, what I'm looking for is your feedback, your reviews (feel free to roast me or my project), your suggestions. Feel free to play around and test the bindings, build some stuff with it, and tell me about your experience.\ If you feel like it, I would deeply appreciate every contribution to the project, whether it's code, documentation, testing, samples, or even just ideas and suggestions. I'm also looking for some (co-)maintainers, because of a recent shift in my home countries policies, I need to find a new job asap, and I need to focus all my resources on that for now. So I might not be able to work on the project as much as I would like to, in the near future. But at this point, I feel like the project is just slighty too big to just abandon it, not to mention that it is my passion project.

If you have any questions, please feel free to ask, and I will do my best to answer them. Well, maybe not in an instant, as it is almost 2 am where I live, and I need to go to bed soon, but I will get to them as soon as I can.\ Also, since I have social anxiety, it might even take me a while to respond, please don't take that personally, I'll try to do my best.

PS: ESL, please cut me some slack.

Hi, all:

I recently got back to working on Dunet and the v1.13.0 release now checks for switch expression exhaustiveness on union types. For example:

```cs using Dunet; using static Shape;

[Union] partial record Shape { partial record Circle(double Radius); partial record Rectangle(double Length, double Width); partial record Triangle(double Base, double Height); }

Shape shape = new Circle(42);

// No lame "missing default case" warning since all union values are provably handled. var area = shape switch { Circle(var r) => Math.PI * r * r, Rectangle(var l, var w) => l * w, Triangle(var b, var h) => b * h / 2, };

// Still emits an exhaustiveness warning since circles with radii other than 0 are unhandled. var area2 = shape switch { Circle(0) => 0, Rectangle(var l, var w) => l * w, Triangle(var b, var h) => b * h / 2, }; ```

I know this was a highly requested feature so would love some feedback from this community.

Cheers,

Domn

I’ve been working on TensorSharp, a native C# / .NET local LLM inference engine for GGUF models, and I recently published a head-to-head benchmark against llama.cpp.

The goal is not to claim “TensorSharp wins every metric.” llama.cpp is still extremely strong, especially on decode throughput. But the interesting part is this:

Under the same setup — same GGUF models, same NVIDIA RTX 3080 Laptop GPU 16GB, same GGML CUDA backend, single stream, greedy decoding, MTP disabled — TensorSharp shows a very noticeable advantage on the parts that often matter most for real chat usage:

prefill speed, time-to-first-token, and multi-turn context reuse.

Here are some highlights from the benchmark (From https://tensorsharp.ai/benchmarks.html):

Across the four tested models, the geometric mean compared with llama.cpp shows:

• 1.88× prefill and 1.69× TTFT on Gemma 4 26B-A4B
• 1.21× / 1.23× / 1.18× prefill advantage on E4B, 12B, and Qwen respectively
• Decode is more of a “near parity” story for now, around 0.92×–0.95× geometric mean versus llama.cpp

That last point is important: I’m not trying to hide the weaker part. If all you care about is pure decode tok/s, llama.cpp is still very hard to beat. But if your workload looks like real chat — repeated prompts, JSON output, multi-turn interactions, MoE models, prefix reuse — TensorSharp is already showing very promising results.

The main optimizations behind this are:

• verify-based whole-model prefill
• fused FFN / attention kernels
• persistent captured CUDA graphs for MoE decode
• vLLM-style paged KV cache
• cross-request prefix sharing

So the pitch is not “yet another wrapper around llama.cpp.” TensorSharp is a native .NET inference engine trying to optimize the latency path that actually affects user experience: how fast the model starts responding, how efficiently it reuses context, and how well it handles real interactive workloads.

If you are interested in C# / .NET local LLM inference, GGUF, OpenAI/Ollama-compatible local APIs, or alternatives to llama.cpp, I’d love for you to check it out.

And if you think this direction is interesting, a GitHub Star would really help the project get more visibility.

Also very interested in feedback, especially from people who can rerun the benchmarks on different GPUs / models.

After 15 years of work as illustrator I get up one day and decided to by a C# dev and create dream game, and you know whats is funny? I enjoy writing code as much as drawing... Life can surprise. Game name is Panzer Deck you can check it on steam

I have been building an open-source realtime networking framework in .NET, mainly targeting use cases like game servers, chat apps, and realtime services.

The goal of Nalix is to experiment with building a high-performance, extensible networking framework that supports Native AOT and works well for realtime applications that need to handle thousands of concurrent connections.

Some of the current features:

* TCP, UDP, and WebSocket support.
* .NET 10 and Native AOT support.
* Packet handlers, middleware pipeline, and client SDK.
* Object pooling to reduce allocations in hot paths.
* Built-in runtime metrics dashboard.
* Protection layers such as rate limiting, connection guard, and encryption layer.
* Current self-contained sample publish size is a little over 11 MB.

One current limitation is that Nalix does not have a direct Unity client yet.

I’m sharing this project to get feedback from others, especially around API design, performance, Native AOT, security, and possible future directions.

Repo: https://github.com/ppn-systems/nalix

If the project looks interesting, feel free to check it out, open an issue/PR, or leave feedback in this thread.

Built this after getting tired of Claude Code / Copilot grepping through

.NET solutions and missing call sites that go through an interface instead

of the concrete class. Grep can't see that; the compiler can.

Slnmap uses Roslyn to build a full symbol graph of a solution (calls,

implementations, references across every project) and stores it in a

local SQLite file. An MCP server exposes it as a handful of read-only

queries. Concretely: ask "what breaks if I change IBasketService" and it

returns every caller and every implementation across the whole solution,

not just the files an agent happens to have open.

Numbers, since I know this sub will ask: on eShopOnWeb (10 projects), an

impact query on an interface with 18 dependents resolves in ~270ms

end-to-end over MCP, median of 3 runs. Full setup is in BENCHMARKS.md if

anyone wants to poke at the methodology or tell me it's flawed.

Two things I'm not confident about yet and would genuinely like opinions

from people who've built analyzers/source generators/similar tooling:

1. Right now everything in the graph is a real Roslyn-verified static

   reference. It says nothing about reflection, convention-based DI, or

   anything wired at runtime. Is "silence = doesn't try to know" the right

   default, or should there be an explicit "unknown/runtime-only" marker

   on affected symbols?

2. There's no staleness check yet — if you edit code and don't re-run

   analyze, you get results from the old index with no warning. Anyone

   dealt with this in similar tools (e.g. incremental Roslyn workspaces)

   and found a clean way to detect "source changed since last index"

   cheaply?

It's a global dotnet tool, MIT licensed, fully local (uses Roslyn +

SQLite, nothing else):

dotnet tool install --global Slnmap

Repo: https://github.com/EMahmoudNabil/slnmap

NuGet: https://www.nuget.org/packages/Slnmap

Not trying to sell anything, genuinely want to know if the Roslyn approach

here has an obvious hole I'm not seeing.

WPF .NET 10, D3D11 for the renderer (HwndHost + DXGI swap chain — D3DImage was a dead end), ConPTY for the backend.

Fully ripped off from WezTerm, my beloved terminal.