Adding a new plugin to this sample app is almost suspiciously easy. Drop a class into the project that implements ICommandPlugin or IStartupPlugin, build, and it just works. No services.AddSingleton<…>() to write. No attribute required. No manifest file. No reflection scan at startup.
That's not magic — it's a C# source generator doing what you'd otherwise do by hand: writing the DI registration code for you, at compile time, into a partial method the rest of the codebase already knows about.
This post walks through why that matters, using the SourceGeneratedDIRegistration sample as a hands-on example. It's small enough to read in an afternoon but hits every interesting corner of a real-world generator.
When working with large datasets, I often need a reliable large file viewer to dig through files—XML, JSON, CSV—that quickly grow into hundreds of megabytes or even gigabytes. At that scale, most tools start to fall apart. Editors freeze, search becomes unreliable, and some applications simply refuse to open a 1 GB file at all.
I’ve occasionally used LTFViewer.exe for this, which handles large files reasonably well. But I tend to prefer command-line tooling—especially for quick inspection, piping, and integration into workflows.
So instead of adapting my workflow to existing tools, I built a small one tailored to how I actually work.
LargeFileViewer is built on a different premise:
You don’t need the whole file. You only need what you’re looking at.
In most teams I’ve worked with, the real problem isn’t provisioning an Azure SQL database — it’s access. Getting RBAC and Entra-based permissions set up correctly is where things break down. Admins are understandably reluctant to grant the required rights broadly, and standard pipelines typically cannot assign SQL role memberships automatically.
When that friction isn’t resolved, teams tend to fall back to what does work: connection strings with embedded secrets. It’s faster, but it bypasses proper identity and access controls entirely.
<p>Adding a new plugin to this sample app is almost suspiciously easy. Drop a class into the project that implements <code>ICommandPlugin</code> or <code>IStartupPlugin</code>, build, and it just <em>works</em>. No <code>services.AddSingleton<…>()</code> to write. No attribute required. No manifest file. No reflection scan at startup.</p>
<p>That's not magic — it's a <strong>C# source generator</strong> doing what you'd otherwise do by hand: writing the DI registration code for you, at compile time, into a <code>partial</code> method the rest of the codebase already knows about.</p>
<p>This post walks through why that matters, using the <strong><a href="https://github.com/enijburg/SourceGeneratedDIRegistration">SourceGeneratedDIRegistration</a></strong> sample as a hands-on example. It's small enough to read in an afternoon but hits every interesting corner of a real-world generator.</p>
<p>When working with large datasets, I often need a reliable <strong>large file viewer</strong> to dig through files—XML, JSON, CSV—that quickly grow into hundreds of megabytes or even gigabytes. At that scale, most tools start to fall apart. Editors freeze, search becomes unreliable, and some applications simply refuse to open a 1 GB file at all.</p>
<p>I’ve occasionally used LTFViewer.exe for this, which handles large files reasonably well. But I tend to prefer command-line tooling—especially for quick inspection, piping, and integration into workflows.</p>
<p>So instead of adapting my workflow to existing tools, I built a small one tailored to how I actually work.</p>
<p>LargeFileViewer is built on a different premise:</p>
<p><strong>You don’t need the whole file. You only need what you’re looking at.</strong></p>
<p>In most teams I’ve worked with, the real problem isn’t provisioning an Azure SQL database — it’s access. Getting RBAC and Entra-based permissions set up correctly is where things break down. Admins are understandably reluctant to grant the required rights broadly, and standard pipelines typically cannot assign SQL role memberships automatically.</p>
<p>When that friction isn’t resolved, teams tend to fall back to what does work: connection strings with embedded secrets. It’s faster, but it bypasses proper identity and access controls entirely.</p>
<p>Over the past few months, I've been deeply immersed in <strong>agentic programming</strong> — working with AI-assisted tooling: primarily ChatGPT (including Codex) and GitHub Copilot.</p>
<p>The impact has been substantial. Not incremental. Structural.</p>
<p>Most tutorials on JWT authentication stop at "add <code>AddJwtBearer()</code> and configure the options." But the moment you need <strong>integration testing</strong> across multiple services behind bearer tokens, the configuration plumbing gets painful: every service needs the same signing key, the same issuer, the same audience, and the test project needs to mint tokens and discover service endpoints. In this article we'll look at a .NET Aspire playground that solves all of this with a single shared development JWT authority — and takes it a step further by running the test project <em>inside</em> the Aspire orchestrator so every test appears as a traced span in the dashboard.</p>
<p>In the <a href="/supercharge-your-net-logging-performance-with-loggermessage/">previous article</a> we explored how the <code>LoggerMessage</code> attribute uses source generators to create high-performance logging code via static extension methods. That approach works great for shared log methods, but it requires you to pass the <code>ILogger</code> instance on every call. In this follow-up we'll look at two features that reduce boilerplate even further: <strong>non-static partial methods</strong> that access the logger from the primary constructor, and <strong>automatic exception recognition</strong>.</p>
<p>I've been reflecting on why <strong>agentic programming</strong> works so well for my neurodivergent brain — and for me it has to do with speed, but most of all with <strong>cognitive fit</strong>.</p>
<p>Sometimes you want to put your <strong>Azure Static Web App</strong> in maintenance mode: you're reworking content, fixing a broken deployment, or you just don't want the public to hit it.</p>
<p>With <strong>Azure Static Web Apps (SWA)</strong> this can be trickier than expected, especially on the <strong>Free</strong> plan.</p>
<p>Logging is essential for monitoring and debugging applications, but it can become a performance bottleneck when not implemented efficiently. The <code>LoggerMessage</code> attribute, introduced in .NET 6, offers a powerful solution that combines high performance with developer-friendly APIs. In this article, we'll explore how this attribute reduces logging overhead, handles exceptions gracefully, and leverages source generators to create optimized code.</p>
<p>Line endings are one of those small but painful details in cross-platform
development. Windows tools (like Visual Studio) prefer <strong>CRLF</strong> (<code>\r\n</code>) line
endings, while Linux and macOS use <strong>LF</strong> (<code>\n</code>).</p>
<p><em>"Our internal server-farm is held hostage by ransomware, but the only thing changed is we installed the patch for your software"</em> — a classic trojan code scenario hiding in plain sight.</p>
<p>Sounds like a software vendor nightmare, right? The above is hypothetical, but <strong>trojan code</strong> injection is a very real threat in modern software development.</p>