Notes on .NET, XAF, and building things
Twenty years of XPO, application frameworks, and lately a lot of applied AI. 325 articles and counting.
Browse by topic
All topics →Latest articles
View all →
Jev Alternatives for .NET: What Actually Replaces It, and What Doesn't
After I wrote about Jev — the 'System One' model that returns a type instead of writing JSON — the obvious question landed in my inbox: do I actually need Jev, or can I get the same thing from tools I already have? Mostly the latter. 'Constrained output' is a commoditized technique now; a dozen things do it. There's even an MIT-licensed open-source Jev that runs on a Mac. So here's the honest, .NET-first menu of alternatives, grouped by where you deploy — and the one thing that's genuinely still hard to replicate.
System One in C#: Testing Jev, and Turning Any Local Model Into One
I wrote about Jev — the model that returns a type instead of writing JSON. Then I wanted two things a .NET dev actually needs: how do you test it from C#, and can you get the same behaviour from a local model you already have? The answer to both is one small interface. 'System One' isn't a special model, it's a harness: never let the model free-write, force it to pick from your options, read the distribution. Here's a tiny .NET library that puts Jev, a local llama.cpp model, and a test fake behind the same contract — with the tests to prove it.
Jev: The Model That Doesn't Write JSON — It Returns a Type
Every time you've asked an LLM for JSON, it has done the same silly thing: written the JSON out one character at a time, and left you to parse it and pray it's valid. Jev, the first model in TypeSafe's new 'System One' class, refuses to play that game. You hand it text and a schema, and it returns a typed value chosen from your options in a single forward pass — no JSON string, no parsing, no chance of a malformed field. It's fast, absurdly cheap, and it cannot write you a paragraph. Here's what it actually is, the honest caveats, and why the name is a warning.
Emulate the Device, Not the Radio: Building a BLE Pendant I Don't Own
I'm building an app that pairs with a wearable audio pendant — and for a while I didn't physically have one. Waiting for hardware blocks development, and even one unit is a bad test rig: nondeterministic, a single audio source, no way to press 'battery = 5%' on demand. So I emulated the device. A Linux box running BlueZ becomes a BLE peripheral that speaks the pendant's exact protocol, and the app can't tell it from the real thing. This is the story of that rig, and the one rule that kept it honest: emulate the device, never the radio.
Patching .NET Assemblies: How License Cracks Actually Work — and Why Client-Side DRM Is Theater
A compiled .NET assembly is not a locked box — it's IL plus metadata that decompiles almost perfectly back to C#. That means any logic you ship, including 'is this licensed?', is visible and editable on the customer's machine. This is a defender's tour of how license checks actually get patched — branch flipping, method stubbing, IL round-trips, Cecil scripts, runtime reflection — demonstrated on a toy check I wrote myself, and why none of the usual defenses (strong naming, Authenticode, obfuscation) change the underlying math. The real lesson is architectural, and it's the only thing that holds.
More topics
All topics →
What Actually Is a .NET Assembly? A Look Inside the File You Ship
We say 'the DLL' or 'the assembly' a hundred times a week without ever opening one up. But when you build a .NET project, what actually comes out? An assembly is not machine code — it's a container of intermediate language plus a remarkably complete description of your own program. This is a tour of what's really inside that file: the PE wrapper, the IL, the metadata tables, the manifest, and the identity — and why that structure is the thing that makes .NET both wonderfully introspectable and impossible to truly hide.
NPU vs CPU, Same Model, Same Machine: I Tried to Benchmark It, and the Result Surprised Me
The plan was clean: run the same model on the same machine on the NPU and on the CPU, and show the speedup. I got a result — it just wasn't the one I planned. The NPU is real and reachable, Foundry Local loads QNN models onto the Hexagon, but the shipping NPU build errors on the very first attention layer of every prompt, in a layer type every modern small model shares. This is what NPU LLM inference on Windows-on-ARM actually looks like right now. Part 3 of 3.
The Cheapest 3× Speedup: Stop Sending Your Local Model Verbose JSON
Before I moved my local automation brain onto the NPU, I found a speedup that cost nothing and needed no new hardware: I was feeding the model twice the tokens it needed. On a CPU, prefill is the whole cost, and prefill scales with tokens sent. Swapping verbose JSON candidates for a terse line format cut the prompt 63% and prefill 65% — 2.7× fewer tokens, 2.9× faster — with no accuracy trade-off. Part 2 of 3.
Running Local AI Models on the NPU of a Snapdragon Surface — with Foundry Local
I have a Copilot+ Surface with a 45-TOPS Hexagon NPU that had never run a single inference. This is the note I wish I'd had: how to actually put a language model on that NPU with Microsoft's Foundry Local, why prefill-heavy automation workloads are exactly what an NPU is built to eat, and the session-0 gotcha that wastes an afternoon when you drive the machine headless over SSH. Part 1 of 3.
Voice Activity Detection: The Cheap Gate That Makes Your Speech Pipeline Fast
Most of the audio in a real recording is silence, and if you send that silence to a speech-to-text model you pay full price to transcribe nothing. Voice activity detection is the cheap gate you put in front of the expensive stuff: a tiny model that tells you, 32 milliseconds at a time, whether the current slice of audio is speech. This is what it is, why it belongs in front of every ASR pipeline, and a small working C# example built on Silero VAD and ONNX Runtime — including the one undocumented detail that makes everyone think the model is broken.