feed.rss

<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
	<channel>
		<title>@devlead - Mattias Karlsson's Blog</title>
		<link>https://www.devlead.se/</link>
		<description />
		<copyright>© Mattias Karlsson 2026</copyright>
		<pubDate>Sat, 27 Jun 2026 20:59:24 GMT</pubDate>
		<lastBuildDate>Sat, 27 Jun 2026 20:59:24 GMT</lastBuildDate>
		<item>
			<title>Template plus source package: my .NET console stack in 2026</title>
			<link>https://www.devlead.se/posts/2026/2026-06-27-template-plus-source-package-my-dotnet-console-stack-in-2026</link>
			<description>How Devlead.Console and a slim template fix template drift while keeping the same opinionated console bootstrap</description>
			<author>devlead</author>
			<enclosure url="https://cdn.devlead.se/clipimg-vscode/2026/06/27/7ffc8a51-5450-4250-8ab6-18f19c5a3984.png?sv=2023-01-03&amp;st=2026-06-27T20%253A01%253A18Z&amp;se=2036-06-28T20%253A01%253A00Z&amp;sr=b&amp;sp=r&amp;sig=%252F70LfFDhc%252BqiQaMwceWIoqODYiQBnLfQevfdXT6G4BM%253D" length="0" type="image" />
			<guid>https://www.devlead.se/posts/2026/2026-06-27-template-plus-source-package-my-dotnet-console-stack-in-2026</guid>
			<pubDate>Sat, 27 Jun 2026 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;Back in 2021 I wrote about &lt;a href="https://www.devlead.se/posts/2021/2021-01-15-my-preferred-console-stack"&gt;my preferred .NET console stack&lt;/a&gt;, an opinionated alternative to &lt;code&gt;dotnet new console&lt;/code&gt; built around &lt;a href="https://spectresystems.github.io/spectre.console/"&gt;Spectre.Console&lt;/a&gt;, dependency injection, and structured logging. That recipe worked well, and I've since used it as the foundation for several tools, including &lt;a href="https://github.com/devlead/ARI"&gt;ARI&lt;/a&gt;, &lt;a href="https://github.com/devlead/Blobify"&gt;Blobify&lt;/a&gt;, &lt;a href="https://github.com/devlead/DPI"&gt;DPI&lt;/a&gt;, &lt;a href="https://github.com/devlead/bri"&gt;BRI&lt;/a&gt;, and &lt;a href="https://github.com/WCOMAB/AZDOI"&gt;AZDOI&lt;/a&gt;. The original approach shipped everything as a .NET template, which was great for getting started, but over time I ran into a familiar problem: templates are excellent for scaffolding, yet not so great for keeping shared bootstrap code in sync across many applications.&lt;/p&gt;
&lt;p&gt;This post is a follow-up on how I've evolved that stack. The template still scaffolds new projects, but the shared glue code now lives in &lt;a href="https://www.nuget.org/packages/Devlead.Console"&gt;Devlead.Console&lt;/a&gt;, a versioned source NuGet package. That combination gives you the easy onboarding of a template with the maintainability of a normal package dependency.&lt;/p&gt;
&lt;h2 id="why-templates-alone-fall-short"&gt;Why templates alone fall short&lt;/h2&gt;
&lt;p&gt;A .NET template is distributed as a NuGet package and installed with &lt;code&gt;dotnet new install&lt;/code&gt;. When you scaffold a project, you get a snapshot of whatever the template author thought was useful at that moment. That works fine the first time.&lt;/p&gt;
&lt;p&gt;The friction shows up when you maintain more than one console application, or when the bootstrap code itself needs to evolve. If logging setup changes, Spectre.Console gets a breaking API shift, or you want to add configuration support, every project that was scaffolded from the template now has its own copy of the old glue code. You either manually merge fixes across repositories, or re-scaffold and copy your business logic back in. Neither option scales particularly well.&lt;/p&gt;
&lt;p&gt;NuGet packages solve the opposite problem nicely. Pin a version, run &lt;code&gt;dotnet restore&lt;/code&gt;, and every consumer gets the same dependency. Source packages take that a step further for glue code: the &lt;code&gt;.cs&lt;/code&gt; files compile into your assembly rather than hiding behind a &lt;code&gt;lib/&lt;/code&gt; reference, which keeps the copy/paste ergonomics while removing drift.&lt;/p&gt;
&lt;h2 id="source-packages-best-of-both-worlds"&gt;Source packages: best of both worlds&lt;/h2&gt;
&lt;p&gt;I touched on source packages last year when introducing &lt;a href="https://www.devlead.se/posts/2025/2025-02-16-introducing-mockhttp-testing"&gt;Devlead.Testing.MockHttp&lt;/a&gt;. The same arguments apply here:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;A source package ships &lt;code&gt;.cs&lt;/code&gt; files as compile-time content under &lt;code&gt;contentFiles/cs/{tfm}/...&lt;/code&gt;, not as a traditional library reference.&lt;/li&gt;
&lt;li&gt;The code is compiled into your application assembly, so you can step through it, extend it, and reason about it like your own code.&lt;/li&gt;
&lt;li&gt;You extend the shared bootstrap using partial classes and partial methods in your project, without forking the package.&lt;/li&gt;
&lt;li&gt;Versioning, release notes, and dependency update tooling (i.e. Renovate) work the same as for any other NuGet package.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;The idea is to get the copy/paste experience of inlined glue code without the copy/paste experience of fixing that same code across every project.&lt;/p&gt;
&lt;div class="mermaid"&gt;flowchart LR
    subgraph scaffold [Devlead.Console.Template]
        AppCommands[Your commands and settings]
        PartialProgram[Partial Program.cs]
    end
    subgraph shared [Devlead.Console source package]
        Bootstrap[IoC logging config CLI wiring]
    end
    PartialProgram --&gt; Bootstrap
    AppCommands --&gt; PartialProgram
    NuGetRestore[NuGet version bump] --&gt; shared
&lt;/div&gt;
&lt;h2 id="devlead.console"&gt;Devlead.Console&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://github.com/devlead/Devlead.Console"&gt;Devlead.Console&lt;/a&gt; is the source package that contains the shared bootstrap. It keeps the same opinionated philosophy as the 2021 template:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Dependency injection via Microsoft.Extensions&lt;/li&gt;
&lt;li&gt;Command-line parsing via Spectre.Console.Cli&lt;/li&gt;
&lt;li&gt;Logging via Microsoft.Extensions.Logging.Console&lt;/li&gt;
&lt;li&gt;Configuration via Microsoft.Extensions.Configuration&lt;/li&gt;
&lt;li&gt;Source Link via the built-in .NET SDK support (no separate package reference needed)&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;What changed is how you interact with it. Instead of a top-level &lt;code&gt;Program.cs&lt;/code&gt; with all the wiring inlined, you implement a &lt;code&gt;partial class Program&lt;/code&gt; and hook into optional partial methods:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;public partial class Program
{
    static partial void ConfigureInMemory(IDictionary&amp;lt;string, string?&amp;gt; configData)
    {
        configData.Add(&amp;quot;TestService__Version&amp;quot;, &amp;quot;1.0.0.0&amp;quot;);
    }

    static partial void AddServices(IServiceCollection services)
    {
        services
            .AddOptions&amp;lt;TestServiceSettings&amp;gt;()
            .BindConfiguration(nameof(TestService));

        services.AddSingleton&amp;lt;TestService&amp;gt;();
    }

    static partial void ConfigureApp(AppServiceConfig appServiceConfig)
    {
        appServiceConfig
            .AddCommand&amp;lt;TestCommand&amp;gt;(&amp;quot;test&amp;quot;)
                .WithDescription(&amp;quot;Example test command.&amp;quot;)
                .WithExample([&amp;quot;test&amp;quot;]);

        appServiceConfig
            .AddBranch(
                &amp;quot;yolo&amp;quot;,
                c =&amp;gt; c.AddCommand&amp;lt;TestCommand&amp;gt;(&amp;quot;test&amp;quot;)
                        .WithDescription(&amp;quot;Example test command.&amp;quot;)
                        .WithExample([&amp;quot;yolo&amp;quot;, &amp;quot;test&amp;quot;])
            );

        appServiceConfig.SetApplicationName(&amp;quot;myapp&amp;quot;);
    }
}
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The partial methods cover the three places you typically need to customize:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;ConfigureInMemory&lt;/code&gt; for in-memory settings during development or testing&lt;/li&gt;
&lt;li&gt;&lt;code&gt;AddServices&lt;/code&gt; for dependency injection registrations&lt;/li&gt;
&lt;li&gt;&lt;code&gt;ConfigureApp&lt;/code&gt; for commands, nested branches, and the application name&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;The resulting CLI supports commands like &lt;code&gt;myapp test&lt;/code&gt; and &lt;code&gt;myapp yolo test&lt;/code&gt;. For Spectre.Console patterns around settings classes, validation attributes, and command structure, the &lt;a href="https://www.devlead.se/posts/2021/2021-01-15-my-preferred-console-stack"&gt;2021 post&lt;/a&gt; still applies; that part of the developer experience has not changed.&lt;/p&gt;
&lt;p&gt;If you need full control, set &lt;code&gt;UseDefaultProgram&lt;/code&gt; to &lt;code&gt;false&lt;/code&gt; in your project file and provide your own &lt;code&gt;Program&lt;/code&gt; implementation. See the &lt;a href="https://github.com/devlead/Devlead.Console/blob/develop/README.md"&gt;Devlead.Console README&lt;/a&gt; for details.&lt;/p&gt;
&lt;p&gt;A typical project file references the package like any other dependency:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-xml"&gt;&amp;lt;ItemGroup&amp;gt;
  &amp;lt;PackageReference Include=&amp;quot;Devlead.Console&amp;quot; Version=&amp;quot;2026.6.23.767&amp;quot; /&amp;gt;
&amp;lt;/ItemGroup&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The package multi-targets &lt;code&gt;net8.0&lt;/code&gt;, &lt;code&gt;net9.0&lt;/code&gt;, and &lt;code&gt;net10.0&lt;/code&gt;, so you can stay on a supported LTS or current SDK without maintaining separate bootstrap code per framework.&lt;/p&gt;
&lt;h2 id="devlead.console.template-today"&gt;Devlead.Console.Template today&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://www.nuget.org/packages/Devlead.Console.Template"&gt;Devlead.Console.Template&lt;/a&gt; has been refactored to use Devlead.Console. It still scaffolds a working console application, but now with minimal moving parts:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;dotnet new install Devlead.Console.Template
dotnet new devleadconsole -n MyConsole
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;You can also pick the target framework explicitly (&lt;code&gt;net8.0&lt;/code&gt;, &lt;code&gt;net9.0&lt;/code&gt;, or &lt;code&gt;net10.0&lt;/code&gt;, default is &lt;code&gt;net10.0&lt;/code&gt;):&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;dotnet new devleadconsole -n MyConsole --framework net8.0
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The template owns your application-specific code: the project file, a sample command and settings class, and the partial &lt;code&gt;Program&lt;/code&gt; stubs that call into the package hooks. The package owns the bootstrap: dependency injection setup, logging, configuration, Spectre.Console wiring, and the dependency versions for the shared stack.&lt;/p&gt;
&lt;p&gt;Compared to the &lt;a href="https://www.devlead.se/posts/2021/2021-01-15-my-preferred-console-stack"&gt;2021 folder layout&lt;/a&gt;, you still get a &lt;code&gt;Commands&lt;/code&gt; folder with your command, settings, and validation code. What you no longer get is a full copy of the bootstrap &lt;code&gt;Program.cs&lt;/code&gt; that silently drifts from project to project.&lt;/p&gt;
&lt;h2 id="devlead.sourcepack"&gt;Devlead.SourcePack&lt;/h2&gt;
&lt;p&gt;Packaging a source NuGet by hand means wrestling with MSBuild: &lt;code&gt;contentFiles&lt;/code&gt;, &lt;code&gt;BuildAction=Compile&lt;/code&gt;, per-target-framework paths, and making sure &lt;code&gt;dotnet pack&lt;/code&gt; produces something consumers can actually restore. To simplify that, I created &lt;a href="https://www.nuget.org/packages/Devlead.SourcePack"&gt;Devlead.SourcePack&lt;/a&gt;, an opinionated MSBuild package for authoring source NuGet packages using the standard SDK &lt;code&gt;dotnet pack&lt;/code&gt; workflow.&lt;/p&gt;
&lt;p&gt;Devlead.Console is built with Devlead.SourcePack, as is &lt;a href="https://www.nuget.org/packages/Devlead.Testing.MockHttp/"&gt;Devlead.Testing.MockHttp&lt;/a&gt;. If you want to author your own source packages, the &lt;a href="https://github.com/devlead/Devlead.SourcePack"&gt;Devlead.SourcePack README&lt;/a&gt; covers the properties and item types. This post stays focused on consuming the console stack rather than publishing new source packages.&lt;/p&gt;
&lt;h2 id="example-projects"&gt;Example projects&lt;/h2&gt;
&lt;p&gt;Devlead.Console is used in several real-world tools:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="https://github.com/devlead/ARI"&gt;ARI&lt;/a&gt; - Azure Resource Inventory, documents tenant resources as markdown&lt;/li&gt;
&lt;li&gt;&lt;a href="https://github.com/devlead/Blobify"&gt;Blobify&lt;/a&gt; - archives local files to Azure Blob Storage&lt;/li&gt;
&lt;li&gt;&lt;a href="https://github.com/devlead/bri"&gt;BRI&lt;/a&gt; - Bicep Registry Inventory, documents modules in an Azure container registry&lt;/li&gt;
&lt;li&gt;&lt;a href="https://github.com/devlead/DPI"&gt;DPI&lt;/a&gt; - Dependency Inventory, reports NuGet dependencies to Azure Log Analytics&lt;/li&gt;
&lt;li&gt;&lt;a href="https://github.com/WCOMAB/AZDOI"&gt;AZDOI&lt;/a&gt; - Azure DevOps Inventory, documents an Azure DevOps organization (a community project I've had the pleasure of mentoring)&lt;/li&gt;
&lt;li&gt;&lt;a href="https://github.com/devlead/UnpackDacPac"&gt;UnpackDacPac&lt;/a&gt; - unpacks SQL Server DACPAC files&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Each of these started from the same opinionated bootstrap and then added domain-specific commands and services on top.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting started&lt;/h2&gt;
&lt;p&gt;Install the template and scaffold a new project:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;dotnet new install Devlead.Console.Template
dotnet new devleadconsole -n MyTool
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The template includes a &lt;code&gt;PackageReference&lt;/code&gt; to Devlead.Console. To update to a newer version:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;dotnet add package Devlead.Console
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;From there, replace the sample command with your own, register services in &lt;code&gt;AddServices&lt;/code&gt;, and wire up commands in &lt;code&gt;ConfigureApp&lt;/code&gt;. The &lt;a href="https://github.com/devlead/Devlead.Console/blob/develop/README.md"&gt;Devlead.Console README&lt;/a&gt; has the full API reference.&lt;/p&gt;
&lt;h2 id="conclusion"&gt;Conclusion&lt;/h2&gt;
&lt;p&gt;My console stack still boils down to the same ingredients: Spectre.Console for CLI parsing, Microsoft.Extensions for DI, logging, and configuration. What changed is where the shared wiring lives. The template scaffolds; the source package maintains. That split keeps the happy path from 2021 while making it practical to evolve the bootstrap across many tools without drift.&lt;/p&gt;
&lt;p&gt;Feel free to let me know if you've got your own recipe for console applications, or if you try this approach and have feedback.&lt;/p&gt;
&lt;h2 id="references"&gt;References&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="https://github.com/devlead/Devlead.Console"&gt;Devlead.Console&lt;/a&gt; (&lt;a href="https://www.nuget.org/packages/Devlead.Console"&gt;NuGet&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;&lt;a href="https://github.com/devlead/Devlead.Console.Template"&gt;Devlead.Console.Template&lt;/a&gt; (&lt;a href="https://www.nuget.org/packages/Devlead.Console.Template"&gt;NuGet&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;&lt;a href="https://github.com/devlead/Devlead.SourcePack"&gt;Devlead.SourcePack&lt;/a&gt; (&lt;a href="https://www.nuget.org/packages/Devlead.SourcePack"&gt;NuGet&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;&lt;a href="https://www.devlead.se/posts/2021/2021-01-15-my-preferred-console-stack"&gt;My preferred .NET console stack (2021)&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://www.devlead.se/posts/2025/2025-02-16-introducing-mockhttp-testing"&gt;Introducing Devlead.Testing.MockHttp (2025)&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://spectresystems.github.io/spectre.console/"&gt;Spectre.Console&lt;/a&gt; (&lt;a href="https://www.nuget.org/packages/Spectre.Console"&gt;NuGet&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;&lt;a href="https://www.nuget.org/packages/Spectre.Console.Cli"&gt;Spectre.Console.Cli&lt;/a&gt; (&lt;a href="https://www.nuget.org/packages/Spectre.Console.Cli"&gt;NuGet&lt;/a&gt;)&lt;/li&gt;
&lt;/ul&gt;
</content:encoded>
			<comments xmlns="http://purl.org/rss/1.0/modules/slash/">0</comments>
		</item>
		<item>
			<title>A quarter of a billion NuGet downloads</title>
			<link>https://www.devlead.se/posts/2026/2026-03-22-quarter-billion-nuget-downloads</link>
			<description>A personal milestone and a short reflection on NuGet's history and what it has enabled for open source and the community</description>
			<author>devlead</author>
			<enclosure url="https://cdn.devlead.se/clipimg-vscode/2026/03/22/019d14ed-ff79-7c53-b9ed-40e27779409a.png?sv=2025-07-05&amp;spr=https&amp;st=2026-03-22T05%253A31%253A00Z&amp;se=2036-03-23T09%253A31%253A00Z&amp;sr=b&amp;sp=r&amp;sig=cL%252FseHDMzerFGyf5a0w0H2JNWWfTytZ5tOqcVCBrueY%253D" length="0" type="image" />
			<guid>https://www.devlead.se/posts/2026/2026-03-22-quarter-billion-nuget-downloads</guid>
			<pubDate>Sun, 22 Mar 2026 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;The total downloads of my packages on &lt;a href="https://www.nuget.org/profiles/devlead"&gt;NuGet.org&lt;/a&gt; have crossed a quarter of a billion. It is a vanity number, but it got me thinking less about the count and more about the platform that made it possible. So here is a short look back at NuGet, the positive bits, and what it has enabled for open source and the community.&lt;/p&gt;
&lt;h2 id="nuget-in-context"&gt;NuGet in context&lt;/h2&gt;
&lt;p&gt;An essential tool for any modern development platform is a way for developers to create, share, and consume useful libraries. For .NET, that mechanism is &lt;a href="https://www.nuget.org/policies/About"&gt;NuGet&lt;/a&gt;. It started out as NuPack, was &lt;a href="https://haacked.com/archive/2010/10/29/nupack-is-now-nuget.aspx/"&gt;renamed to NuGet&lt;/a&gt; in 2010, and became one of Microsoft's early forays into open source package management under the OuterCurve Foundation. Later, and still today, NuGet is part of the &lt;a href="https://dotnetfoundation.org/"&gt;.NET Foundation&lt;/a&gt;. The &lt;a href="https://blog.davidebbo.com/2011/01/introducing-nuget-gallery.html"&gt;NuGet Gallery&lt;/a&gt; followed in 2011, and the rest is history.&lt;/p&gt;
&lt;p&gt;In May 2016, &lt;a href="https://devblogs.microsoft.com/dotnet/the-1st-billion-1/"&gt;NuGet.org reached its first billion downloads&lt;/a&gt;. Today the gallery has passed 895 billion package downloads, over 11 million package versions, and over half a million unique packages. The ecosystem has grown enormously around that: .NET Framework, .NET Core and the unified .NET platform, better tooling, and a gallery that keeps improving. What has stayed constant is that the &lt;a href="https://www.nuget.org/policies/About"&gt;NuGet Gallery is open source&lt;/a&gt;, licensed under the Apache 2 License on GitHub. The NuGet team and a long list of community contributors have built and maintained the site that powers NuGet.org. That openness is something worth celebrating.&lt;/p&gt;
&lt;h2 id="what-nuget-has-enabled"&gt;What NuGet has enabled&lt;/h2&gt;
&lt;p&gt;For open source, NuGet has become the place where .NET libraries and tools get discovered and reused. Maintainers can publish once and reach millions of developers. Projects like &lt;a href="https://cakebuild.net/"&gt;Cake&lt;/a&gt; and countless libraries, tools, and templates are easily available because there is a single, trusted place to host and consume packages. That has made it far easier for teams and individuals to adopt .NET open source.&lt;/p&gt;
&lt;p&gt;For the community, NuGet has evolved beyond the basics. Package signing, two-factor authentication, &lt;a href="https://devblogs.microsoft.com/dotnet/nugetaudit-2-0-elevating-security-and-trust-in-package-management/"&gt;NuGetAudit&lt;/a&gt;, and &lt;a href="https://devblogs.microsoft.com/dotnet/enhanced-security-is-here-with-the-new-trust-publishing-on-nuget-org/"&gt;Trusted Publishing&lt;/a&gt; have raised security and trust. &lt;a href="https://devblogs.microsoft.com/dotnet/announcing-sponsorship-on-nugetdotorg-for-maintainer-appreciation/"&gt;Sponsorship on NuGet.org&lt;/a&gt; gives users a way to support maintainers. The gallery itself has improved with better search, &lt;a href="https://devblogs.microsoft.com/dotnet/introducing-central-package-management/"&gt;Central Package Management&lt;/a&gt; support, dark mode, and clearer package details. None of that happens without a platform that the team and community keep investing in. Development does not always move as fast as users would like, but that is the trade-off when you are also operating and maintaining a service that so many developers depend on every day.&lt;/p&gt;
&lt;p&gt;For me, NuGet has been the channel for publishing and maintaining Cake-related packages and .NET tools such as &lt;a href="https://www.nuget.org/packages/Cake.Tool"&gt;Cake.Tool&lt;/a&gt;, &lt;a href="https://www.nuget.org/packages/Cake.Git"&gt;Cake.Git&lt;/a&gt; and latest being &lt;a href="https://www.nuget.org/packages/Cake.Sdk"&gt;Cake.Sdk&lt;/a&gt;, along with several other tools and libraries like &lt;a href="https://www.nuget.org/packages/LitJson"&gt;LitJSON&lt;/a&gt;, &lt;a href="https://www.nuget.org/packages/DPI"&gt;DPI&lt;/a&gt;, &lt;a href="https://www.nuget.org/packages/ARI"&gt;ARI&lt;/a&gt;, &lt;a href="https://www.nuget.org/packages/BRI"&gt;BRI&lt;/a&gt;, &lt;a href="https://www.nuget.org/packages/Blobify"&gt;Blobify&lt;/a&gt;, and &lt;a href="https://www.nuget.org/packages/UnpackDacPac"&gt;UnpackDacPac&lt;/a&gt;, etc. It has also given me the chance to give back. The gallery is open for contributions, and I was able to add &lt;a href="https://github.com/NuGet/NuGetGallery/pull/10277"&gt;Central Package Management and multiple package manager commands to the NuGet.org command palette&lt;/a&gt;. That kind of improvement is possible because the gallery is open source and the team welcomes community pull requests.&lt;/p&gt;
&lt;h2 id="thanks"&gt;Thanks&lt;/h2&gt;
&lt;p&gt;Having reached a quarter of a billion downloads is not something one does alone. Thank you to everyone who uses these packages, to my projects co-maintainers, and to the NuGet team and everyone who contributes to the gallery and the ecosystem. NuGet has come a long way since 2010, and I am looking forward to seeing how it continues to improve and support maintainers and the .NET community.&lt;/p&gt;
</content:encoded>
			<comments xmlns="http://purl.org/rss/1.0/modules/slash/">0</comments>
		</item>
		<item>
			<title>Mend Renovate Now Supports C# File-Based Apps and Cake.Sdk</title>
			<link>https://www.devlead.se/posts/2026/2026-02-26-renovate-csharp-file-based-apps</link>
			<description>Renovate can now update dependencies in C# single-file scripts and Cake.Sdk build scripts with #:sdk, #:package, and InstallTool.</description>
			<author>devlead</author>
			<enclosure url="https://cdn.devlead.se/clipimg-vscode/2026/02/26/a39f98b5-b854-48a8-a44b-2affb1b8d043.png?sp=r&amp;st=2026-02-26T22:10:14Z&amp;se=2036-02-27T06:25:14Z&amp;spr=https&amp;sv=2024-11-04&amp;sr=b&amp;sig=FIy9HlptIfMEwPF9kW3iJoNqz6iN%252BMMqX%252BezOGZ9DNM%253D" length="0" type="image" />
			<guid>https://www.devlead.se/posts/2026/2026-02-26-renovate-csharp-file-based-apps</guid>
			<pubDate>Thu, 26 Feb 2026 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;&lt;a href="https://github.com/renovatebot/renovate"&gt;Mend Renovate&lt;/a&gt; automates dependency updates by opening pull requests when newer versions of your dependencies are available. Until recently, if you used .NET single-file scripts or &lt;a href="https://cakebuild.net/docs/running-builds/runners/cake-sdk"&gt;Cake.Sdk&lt;/a&gt; build scripts written in C# (e.g. &lt;code&gt;cake.cs&lt;/code&gt; or &lt;code&gt;build.cs&lt;/code&gt;), Renovate did not look inside those files. Two merged changes fix that: the NuGet manager now understands &lt;code&gt;#:sdk&lt;/code&gt; and &lt;code&gt;#:package&lt;/code&gt; directives in C# files, and the Cake manager can extract and update packages from &lt;a href="https://cakebuild.net/docs/writing-builds/sdk/tools"&gt;&lt;code&gt;InstallTool&lt;/code&gt;&lt;/a&gt; and &lt;code&gt;InstallTools&lt;/code&gt; calls. In this post I'll summarize what was added and how to enable it in your repo.&lt;/p&gt;
&lt;h2 id="what-changed"&gt;What Changed&lt;/h2&gt;
&lt;p&gt;.NET 10 introduced &lt;a href="https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-app/"&gt;file-based execution&lt;/a&gt; for single-file C# apps. In that model, dependencies are declared with &lt;code&gt;#:sdk&lt;/code&gt; and &lt;code&gt;#:package&lt;/code&gt; at the top of the file instead of in a &lt;code&gt;.csproj&lt;/code&gt;. Cake.Sdk uses the same mechanism for build scripts, and tools are installed via &lt;code&gt;InstallTool()&lt;/code&gt; or &lt;code&gt;InstallTools()&lt;/code&gt; rather than the old &lt;code&gt;#tool&lt;/code&gt; directive. Renovate's default file patterns only include project and config files (e.g. &lt;code&gt;.csproj&lt;/code&gt;, &lt;code&gt;global.json&lt;/code&gt;, &lt;code&gt;dotnet-tools.json&lt;/code&gt;), so it did not previously scan plain &lt;code&gt;.cs&lt;/code&gt; files. That meant dependencies in &lt;code&gt;cake.cs&lt;/code&gt; or other single-file C# scripts were never considered for updates.&lt;/p&gt;
&lt;p&gt;Two pull requests extend Renovate to support these formats:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;&lt;a href="https://github.com/renovatebot/renovate/pull/40040"&gt;feat(manager/nuget): Support single file package directives&lt;/a&gt;&lt;/strong&gt; (merged in &lt;a href="https://github.com/renovatebot/renovate/releases/tag/43.26.0"&gt;v43.26.0&lt;/a&gt;)&lt;br /&gt;
The NuGet manager can now extract and update dependencies from C# files that use &lt;code&gt;#:sdk&lt;/code&gt; and &lt;code&gt;#:package&lt;/code&gt;. Because the target files are regular source files, they are not part of the default &lt;code&gt;managerFilePatterns&lt;/code&gt;. You must add the patterns you want (e.g. &lt;code&gt;/\\.cs$/&lt;/code&gt; or something narrower) in your Renovate config.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;&lt;a href="https://github.com/renovatebot/renovate/pull/40070"&gt;feat(manager/cake): Support extracting nuget packages from InstallTools helper methods&lt;/a&gt;&lt;/strong&gt; (merged in &lt;a href="https://github.com/renovatebot/renovate/releases/tag/43.41.0"&gt;v43.41.0&lt;/a&gt;)&lt;br /&gt;
The Cake manager gains support for single-file Cake.Sdk build scripts. It can extract NuGet package references from &lt;code&gt;InstallTool()&lt;/code&gt; and &lt;code&gt;InstallTools()&lt;/code&gt; method parameters (e.g. &lt;code&gt;InstallTool(&amp;quot;dotnet:https://api.nuget.org/v3/index.json?package=DPI&amp;amp;version=2025.12.17.349&amp;quot;);&lt;/code&gt;). By default the Cake manager still only matches &lt;code&gt;*.cake&lt;/code&gt; files, so to have Renovate process C# Cake scripts you need to extend the Cake manager's file patterns in config.&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;So in practice: use the &lt;strong&gt;NuGet&lt;/strong&gt; manager for &lt;code&gt;#:sdk&lt;/code&gt; and &lt;code&gt;#:package&lt;/code&gt; in any C# file, and use the &lt;strong&gt;Cake&lt;/strong&gt; manager for Cake-specific constructs (including &lt;code&gt;InstallTool(s)&lt;/code&gt;) in C# files. For a typical &lt;code&gt;cake.cs&lt;/code&gt; you will often enable both and let each manager handle the directives it understands.&lt;/p&gt;
&lt;h2 id="what-renovate-can-update"&gt;What Renovate Can Update&lt;/h2&gt;
&lt;p&gt;In a C# single-file script or Cake.Sdk build file, Renovate can now update:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;&lt;code&gt;#:sdk&lt;/code&gt;&lt;/strong&gt; – e.g. &lt;code&gt;#:sdk Cake.Sdk&amp;#64;6.0.0&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;&lt;code&gt;#:package&lt;/code&gt;&lt;/strong&gt; – e.g. &lt;code&gt;#:package Cake.Core&amp;#64;6.0.0&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;&lt;a href="https://cakebuild.net/docs/writing-builds/sdk/tools"&gt;InstallTool() / InstallTools()&lt;/a&gt;&lt;/strong&gt; – e.g. &lt;code&gt;InstallTool(&amp;quot;dotnet:https://api.nuget.org/v3/index.json?package=DPI&amp;amp;version=2025.12.17.349&amp;quot;);&lt;/code&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;The &lt;code&gt;#:sdk&lt;/code&gt; and &lt;code&gt;#:package&lt;/code&gt; directives are handled by the &lt;a href="https://docs.renovatebot.com/modules/manager/nuget/"&gt;NuGet manager&lt;/a&gt;. The &lt;a href="https://docs.renovatebot.com/modules/manager/cake/"&gt;Cake manager&lt;/a&gt; handles the Cake-specific tool installation methods. Both managers need to be told to look at &lt;code&gt;.cs&lt;/code&gt; files (or the specific paths you use) via configuration.&lt;/p&gt;
&lt;h2 id="enabling-it-in-your-repository"&gt;Enabling It in Your Repository&lt;/h2&gt;
&lt;p&gt;Renovate reads config from your repo (e.g. &lt;code&gt;renovate.json&lt;/code&gt; or &lt;code&gt;renovate.json5&lt;/code&gt;) and merges it with &lt;a href="https://docs.renovatebot.com/config-overview/"&gt;default and inherited config&lt;/a&gt;. To have Renovate consider your C# single-file scripts and Cake.Sdk build files, add the corresponding &lt;code&gt;managerFilePatterns&lt;/code&gt; (or the &lt;code&gt;fileMatch&lt;/code&gt;-style option your preset uses) so that the NuGet and Cake managers include those files.&lt;/p&gt;
&lt;p&gt;Example addition to your Renovate config (e.g. in &lt;code&gt;renovate.json&lt;/code&gt;):&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-json"&gt;{
  &amp;quot;$schema&amp;quot;: &amp;quot;https://docs.renovatebot.com/renovate-schema.json&amp;quot;,
  &amp;quot;nuget&amp;quot;: {
    &amp;quot;managerFilePatterns&amp;quot;: [&amp;quot;/\\.cs$/&amp;quot;]
  },
  &amp;quot;cake&amp;quot;: {
    &amp;quot;managerFilePatterns&amp;quot;: [&amp;quot;/\\.cs$/&amp;quot;]
  }
}
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;If you only want to include specific script names (e.g. only &lt;code&gt;cake.cs&lt;/code&gt; and &lt;code&gt;build.cs&lt;/code&gt;), you can narrow the pattern:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-json"&gt;{
  &amp;quot;nuget&amp;quot;: {
    &amp;quot;managerFilePatterns&amp;quot;: [&amp;quot;/(^|/)(cake|build)\\.cs$/&amp;quot;]
  },
  &amp;quot;cake&amp;quot;: {
    &amp;quot;managerFilePatterns&amp;quot;: [&amp;quot;/(^|/)(cake|build)\\.cs$/&amp;quot;]
  }
}
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;After this, Renovate will detect dependencies in those C# files and open PRs when updates are available. You can combine this with your existing presets (e.g. &lt;code&gt;config:recommended&lt;/code&gt;) and other options like &lt;code&gt;packageRules&lt;/code&gt; or scheduling as needed.&lt;/p&gt;
&lt;h2 id="example-repositories-and-prs"&gt;Example Repositories and PRs&lt;/h2&gt;
&lt;p&gt;Real-world examples of Renovate running against Cake.Sdk-style repos:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;&lt;a href="https://github.com/devlead/Devlead.Console"&gt;devlead/Devlead.Console&lt;/a&gt;&lt;/strong&gt; – &lt;a href="https://github.com/devlead/Devlead.Console/pull/239"&gt;PR #239&lt;/a&gt; shows Renovate updating dependencies in a C# build script.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;&lt;a href="https://github.com/azurevoodoo/renovate-cake-sdk-test"&gt;azurevoodoo/renovate-cake-sdk-test&lt;/a&gt;&lt;/strong&gt; – A small test repo used to validate the feature; e.g. &lt;a href="https://github.com/azurevoodoo/renovate-cake-sdk-test/pull/4"&gt;PR #4&lt;/a&gt;, &lt;a href="https://github.com/azurevoodoo/renovate-cake-sdk-test/pull/8"&gt;PR #8&lt;/a&gt;, &lt;a href="https://github.com/azurevoodoo/renovate-cake-sdk-test/pull/9"&gt;PR #9&lt;/a&gt;.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Running Renovate locally against that test repo with a config that includes &lt;code&gt;(^|/)(cake|build)\\.cs$&lt;/code&gt; for the Cake manager produces PRs for outdated packages in those files without issues.&lt;/p&gt;
&lt;h2 id="summary"&gt;Summary&lt;/h2&gt;
&lt;p&gt;If you use C# single-file apps or Cake.Sdk build scripts with &lt;code&gt;#:sdk&lt;/code&gt;, &lt;code&gt;#:package&lt;/code&gt;, and &lt;code&gt;InstallTool(s)&lt;/code&gt;, you can now keep those dependencies up to date with Mend Renovate. Add the appropriate &lt;code&gt;managerFilePatterns&lt;/code&gt; for the NuGet and Cake managers so they scan your &lt;code&gt;.cs&lt;/code&gt; files (or the specific paths you use), and Renovate will open pull requests for available updates. For more on the managers and config, see the &lt;a href="https://docs.renovatebot.com/modules/manager/nuget/"&gt;NuGet manager docs&lt;/a&gt;, the &lt;a href="https://docs.renovatebot.com/modules/manager/cake/"&gt;Cake manager docs&lt;/a&gt;, and the &lt;a href="https://docs.renovatebot.com/config-overview/"&gt;Renovate configuration overview&lt;/a&gt;.&lt;/p&gt;
</content:encoded>
			<comments xmlns="http://purl.org/rss/1.0/modules/slash/">0</comments>
		</item>
		<item>
			<title>Migrating to Cake.Sdk</title>
			<link>https://www.devlead.se/posts/2025/2025-07-28-migrating-to-cake-sdk</link>
			<description>Taking your build.cake to cake.cs</description>
			<author>devlead</author>
			<enclosure url="https://cdn.devlead.se/clipimg-vscode/2025/07/28/aba66765-b6fb-4c2a-1553-71ec0c766405.png?sv=2025-01-05&amp;st=2025-07-27T20%253A09%253A59Z&amp;se=2035-07-28T20%253A09%253A59Z&amp;sr=b&amp;sp=r&amp;sig=FsI7ji92JZB3VCtCDhCl5ujmhxlCLoi0xsw1ukh0nFw%253D" length="0" type="image" />
			<guid>https://www.devlead.se/posts/2025/2025-07-28-migrating-to-cake-sdk</guid>
			<pubDate>Mon, 28 Jul 2025 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;The Cake team recently announced &lt;a href="https://cakebuild.net/blog/2025/07/dotnet-cake-cs"&gt;Cake.Sdk&lt;/a&gt;, a new way to get the Cake tool scripting experience in regular .NET console applications. This brings the stellar experience of the new &amp;quot;dotnet run app.cs&amp;quot; feature (requires .NET 10), while also working seamlessly with .NET 8 and 9 for regular csproj projects.&lt;/p&gt;
&lt;p&gt;In this post, I'll walk you through migrating from a traditional Cake .NET Tool build script to the new Cake.Sdk single file approach.&lt;/p&gt;
&lt;h2 id="whats-changing"&gt;What's Changing&lt;/h2&gt;
&lt;p&gt;The migration involves converting from a &lt;code&gt;build.cake&lt;/code&gt; file with &lt;code&gt;#addin&lt;/code&gt; and &lt;code&gt;#tool&lt;/code&gt; directives to a &lt;code&gt;cake.cs&lt;/code&gt; file with &lt;code&gt;#:sdk&lt;/code&gt; and &lt;code&gt;#:package&lt;/code&gt; directives. The &lt;code&gt;#tool&lt;/code&gt; directive is replaced with the &lt;code&gt;InstallTool()&lt;/code&gt; method call. The new approach leverages .NET 10's file-based execution while maintaining all the familiar Cake functionality.&lt;/p&gt;
&lt;h2 id="migration-steps"&gt;Migration Steps&lt;/h2&gt;
&lt;h3 id="update-global.json"&gt;1. Update global.json&lt;/h3&gt;
&lt;p&gt;First, add the Cake.Sdk to your &lt;code&gt;global.json&lt;/code&gt; to pin the version:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-json"&gt;{
  &amp;quot;sdk&amp;quot;: {
    &amp;quot;version&amp;quot;: &amp;quot;10.0.100-preview.6.25358.103&amp;quot;,
    &amp;quot;allowPrerelease&amp;quot;: false,
    &amp;quot;rollForward&amp;quot;: &amp;quot;latestMajor&amp;quot;
  },
  &amp;quot;msbuild-sdks&amp;quot;: {
    &amp;quot;Cake.Sdk&amp;quot;: &amp;quot;5.0.25198.49-beta&amp;quot;
  }
}
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id="rename-and-update-build-script"&gt;2. Rename and Update Build Script&lt;/h3&gt;
&lt;p&gt;Rename your &lt;code&gt;build.cake&lt;/code&gt; to &lt;code&gt;cake.cs&lt;/code&gt; and update the directives:&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Example before (build.cake):&lt;/strong&gt;&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;#addin nuget:?package=Cake.FileHelpers&amp;amp;version=7.0.0
#addin nuget:?package=Newtonsoft.Json&amp;amp;version=13.0.3
#tool dotnet:?package=GitVersion.Tool&amp;amp;version=5.12.0

// ... existing code ...
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;strong&gt;Example after (cake.cs):&lt;/strong&gt;&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;#:sdk Cake.Sdk
#:package Cake.FileHelpers
#:package Newtonsoft.Json
InstallTool(&amp;quot;dotnet:https://api.nuget.org/v3/index.json?package=GitVersion.Tool&amp;amp;version=5.12.0&amp;quot;);

// ... existing code ...
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id="update-package-management"&gt;3. Update Package Management&lt;/h3&gt;
&lt;p&gt;For Central Package Management (CPM), add the packages to your &lt;code&gt;Directory.Packages.props&lt;/code&gt;:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-xml"&gt;&amp;lt;ItemGroup&amp;gt;
  &amp;lt;PackageVersion Include=&amp;quot;Cake.FileHelpers&amp;quot; Version=&amp;quot;7.0.0&amp;quot; /&amp;gt;
  &amp;lt;PackageVersion Include=&amp;quot;Newtonsoft.Json&amp;quot; Version=&amp;quot;13.0.3&amp;quot; /&amp;gt;
  &amp;lt;!-- ... existing packages ... --&amp;gt;
&amp;lt;/ItemGroup&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Alternatively, you can specify versions directly in the package directives:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;#:package Cake.FileHelpers&amp;#64;7.0.0
#:package Newtonsoft.Json&amp;#64;13.0.3
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id="update-build-command"&gt;4. Update Build Command&lt;/h3&gt;
&lt;p&gt;The build command changes from:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;dotnet cake build.cake
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;To:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;dotnet cake.cs
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id="key-differences"&gt;Key Differences&lt;/h2&gt;
&lt;h3 id="package-references"&gt;Package References&lt;/h3&gt;
&lt;p&gt;&lt;strong&gt;Old way:&lt;/strong&gt;&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;#addin nuget:?package=Cake.FileHelpers&amp;amp;version=7.0.0
#addin nuget:?package=Newtonsoft.Json&amp;amp;version=13.0.3
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;strong&gt;New way:&lt;/strong&gt;&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;#:package Cake.FileHelpers
#:package Newtonsoft.Json
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id="tool-installation"&gt;Tool Installation&lt;/h3&gt;
&lt;p&gt;&lt;strong&gt;Old way:&lt;/strong&gt;&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;#tool dotnet:?package=GitVersion.Tool&amp;amp;version=5.12.0
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;strong&gt;New way:&lt;/strong&gt;&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;InstallTool(&amp;quot;dotnet:https://api.nuget.org/v3/index.json?package=GitVersion.Tool&amp;amp;version=5.12.0&amp;quot;);
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id="requirements"&gt;Requirements&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;File-based approach&lt;/strong&gt;: .NET 10 Preview 6 or later&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Project-based approach&lt;/strong&gt;: .NET 8.0 or later&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="benefits"&gt;Benefits&lt;/h2&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;Simplified Setup&lt;/strong&gt;: No need for wrapper scripts or tool installation&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Better IDE Support&lt;/strong&gt;: Full IntelliSense and debugging capabilities&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Centralized Package Management&lt;/strong&gt;: Works seamlessly with CPM&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Standard NuGet Auth Support&lt;/strong&gt;: Uses your existing NuGet configuration and credentials&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;.NET SDK Tooling&lt;/strong&gt;: Leverages standard .NET tooling and build processes&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Directory.Build.props/targets Support&lt;/strong&gt;: Integrates with MSBuild's directory-level customization for build settings&lt;/li&gt;
&lt;/ol&gt;
&lt;h2 id="converting-to-project-based"&gt;Converting to Project-Based&lt;/h2&gt;
&lt;p&gt;If you prefer a traditional project-based approach, you can convert your &lt;code&gt;cake.cs&lt;/code&gt; file to a full .NET project using:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;dotnet project convert cake.cs
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;This command creates a new directory named for your file, scaffolds a &lt;code&gt;.csproj&lt;/code&gt; file, moves your code into the new directory as &lt;code&gt;cake.cs&lt;/code&gt;, and translates any &lt;code&gt;#:&lt;/code&gt; directives into MSBuild properties and references.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Before (cake.cs):&lt;/strong&gt;&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;#:sdk Cake.Sdk
#:package Cake.FileHelpers
#:package Newtonsoft.Json
#:property ProjectType=Test

// ... existing code ...
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;strong&gt;After (cake/cake.csproj):&lt;/strong&gt;&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-xml"&gt;&amp;lt;Project Sdk=&amp;quot;Cake.Sdk&amp;quot;&amp;gt;
  &amp;lt;PropertyGroup&amp;gt;
    &amp;lt;OutputType&amp;gt;Exe&amp;lt;/OutputType&amp;gt;
    &amp;lt;TargetFramework&amp;gt;net10.0&amp;lt;/TargetFramework&amp;gt;
    &amp;lt;ImplicitUsings&amp;gt;enable&amp;lt;/ImplicitUsings&amp;gt;
    &amp;lt;Nullable&amp;gt;enable&amp;lt;/Nullable&amp;gt;
    &amp;lt;PublishAot&amp;gt;true&amp;lt;/PublishAot&amp;gt;
  &amp;lt;/PropertyGroup&amp;gt;
  &amp;lt;PropertyGroup&amp;gt;
    &amp;lt;ProjectType&amp;gt;Test&amp;lt;/ProjectType&amp;gt;
  &amp;lt;/PropertyGroup&amp;gt;
  &amp;lt;ItemGroup&amp;gt;
    &amp;lt;PackageReference Include=&amp;quot;Cake.FileHelpers&amp;quot; /&amp;gt;
    &amp;lt;PackageReference Include=&amp;quot;Newtonsoft.Json&amp;quot; /&amp;gt;
  &amp;lt;/ItemGroup&amp;gt;
&amp;lt;/Project&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The project-based approach works with .NET 8, 9, and 10, while the file-based approach requires .NET 10.&lt;/p&gt;
&lt;h2 id="real-world-example"&gt;Real-World Example&lt;/h2&gt;
&lt;p&gt;The &lt;a href="https://github.com/App-vNext/Polly"&gt;Polly&lt;/a&gt; project recently migrated from Cake .NET Tool to Cake.Sdk in their &lt;a href="https://github.com/App-vNext/Polly/pull/2676"&gt;dotnet-vnext branch&lt;/a&gt;. The migration involved:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Renaming &lt;code&gt;build.cake&lt;/code&gt; to &lt;code&gt;cake.cs&lt;/code&gt; and adding SDK directives&lt;/li&gt;
&lt;li&gt;Updating &lt;code&gt;build.ps1&lt;/code&gt; to use &lt;code&gt;dotnet cake.cs&lt;/code&gt; instead of &lt;code&gt;dotnet cake&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;Adding &lt;code&gt;Cake.Sdk&lt;/code&gt; to &lt;code&gt;global.json&lt;/code&gt; &lt;code&gt;msbuild-sdks&lt;/code&gt; section&lt;/li&gt;
&lt;li&gt;Moving &lt;code&gt;Cake.FileHelpers&lt;/code&gt; and &lt;code&gt;Newtonsoft.Json&lt;/code&gt; from &lt;code&gt;#addin&lt;/code&gt; to &lt;code&gt;#package&lt;/code&gt; directives&lt;/li&gt;
&lt;li&gt;Adding &lt;code&gt;ProjectType=Test&lt;/code&gt; property for analyzer support&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;This real-world example demonstrates how straightforward the migration process is, even for large, complex projects like Polly.&lt;/p&gt;
&lt;h2 id="conclusion"&gt;Conclusion&lt;/h2&gt;
&lt;p&gt;The migration to Cake.Sdk is straightforward and brings significant improvements to the development experience. The new approach maintains all existing functionality while providing better tooling support, simplified project structure, and enhanced IDE integration.&lt;/p&gt;
&lt;p&gt;For more information, check out the &lt;a href="https://cakebuild.net/blog/2025/07/dotnet-cake-cs"&gt;official announcement&lt;/a&gt; and the &lt;a href="https://github.com/cake-build/cakesdk-example"&gt;example repository&lt;/a&gt;.&lt;/p&gt;
</content:encoded>
			<comments xmlns="http://purl.org/rss/1.0/modules/slash/">0</comments>
		</item>
		<item>
			<title>Introducing AZDOI</title>
			<link>https://www.devlead.se/posts/2025/2025-03-22-introducing-azdoi</link>
			<description>A DevOps tool to document a Azure DevOps organization</description>
			<author>devlead</author>
			<enclosure url="https://cdn.devlead.se/clipimg-vscode/2025/03/21/70d7054b-ef89-cdf6-88ba-45a98ccc5d6f.png?sv=2025-01-05&amp;st=2025-03-20T18%253A45%253A56Z&amp;se=2035-03-21T18%253A45%253A56Z&amp;sr=b&amp;sp=r&amp;sig=7cf9wdEo49wQF3T9ZJjMkEmLCOeukU6xHW9bQID019Q%253D" length="0" type="image" />
			<guid>https://www.devlead.se/posts/2025/2025-03-22-introducing-azdoi</guid>
			<pubDate>Sat, 22 Mar 2025 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;For the last couple of months, I've had the pleasure of mentoring two talented .NET students, &lt;a href="https://se.linkedin.com/in/andreassiggelin"&gt;Andreas Siggelin&lt;/a&gt; and &lt;a href="https://se.linkedin.com/in/elie-bou-absi-5b722123a"&gt;Elie Bou Absi&lt;/a&gt;. They've been working on various internal and customer projects, gaining practical experience in real-world software development. One project we've been collaborating on is AZDOI, a tool designed to document an Azure DevOps organization. After seeing its value in our work, we've decided to open source AZDOI, and in this blog post, I'll walk you through what it is and how you can use it.&lt;/p&gt;
&lt;h1 id="what-azdoi-does"&gt;What AZDOI Does&lt;/h1&gt;
&lt;p&gt;AZDOI (Azure DevOps Inventory) is a .NET tool designed to create documentation for Azure DevOps organizations. The tool connects to the Azure DevOps REST API and iterates over all projects in an organization it has access to, using either personal access token or Azure Entra ID authentication i.e. using a service principle.&lt;/p&gt;
&lt;p&gt;For each project, AZDOI systematically inventories all repositories, fetching useful data including default branch, size, and URIs. It goes deeper by also collecting each repository's branches, tags, and README content.&lt;/p&gt;
&lt;div class="mermaid"&gt;graph LR
    Projects[Iterate Projects]
    Repos[Iterate Repositories]
    Branches[Iterate Branches]
    Tags[Iterate Tags]
    Tag[Fetch tag annotation]
    Readme[Fetch README.md]
    Markdown[Generate Markdown]

    Projects --&gt; Repos
    Repos --&gt; Branches --&gt; Markdown
    Repos --&gt; Tags --&gt; Tag --&gt; Markdown
    Repos --&gt; Readme --&gt; Markdown
&lt;/div&gt;
&lt;p&gt;The output is a well-organized set of Markdown files structured at the organization, project, and repository levels. These generated Markdown files can then serve as source input for a static site generator to create comprehensive, easily navigable, searchable documentation of your entire Azure DevOps organization.&lt;/p&gt;
&lt;p&gt;An example of the end result published to GitHub Pages can be found at &lt;a href="https://wcomab.github.io/AZDOI/AZDOI/"&gt;https://wcomab.github.io/AZDOI/AZDOI/&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;While AZDOI currently focuses on documenting Azure Repos, future versions may expand to cover other aspects of Azure DevOps like work items, pipelines, and release definitions to provide a more complete organizational view.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting Started&lt;/h2&gt;
&lt;p&gt;AZDOI is a .NET tool distributed via &lt;a href="https://www.nuget.org/packages/AZDOI/"&gt;NuGet.org&lt;/a&gt;. You can install it either as a globally available tool or as a local tool using a tool manifest.&lt;/p&gt;
&lt;h3 id="global-installation"&gt;Global Installation&lt;/h3&gt;
&lt;p&gt;To install AZDOI as a global tool, run the following command:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;dotnet tool install --global AZDOI
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Once installed globally, you can invoke AZDOI simply by using the command:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;azdoi
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id="local-installation"&gt;Local Installation&lt;/h3&gt;
&lt;p&gt;If you prefer to install AZDOI locally (per repository), you can set up a tool manifest and install it with the following commands:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;# Create tool manifest (only needed first time when setting up local/repo-versioned tools)
dotnet new tool-manifest

# Install tool into manifest
dotnet tool install --local AZDOI
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;After installing, make sure to commit the manifest file located at &lt;code&gt;.config/dotnet-tools.json&lt;/code&gt; into your repository. This allows anyone cloning the repo or using a DevOps pipeline to restore all versioned tools by executing:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;dotnet tool restore
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;As a local tool, you can invoke AZDOI using:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;dotnet azdoi
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id="usage"&gt;Usage&lt;/h2&gt;
&lt;p&gt;The basic usage of AZDOI is as follows:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;azdoi inventory repositories &amp;lt;devopsorg&amp;gt; &amp;lt;outputpath&amp;gt; [OPTIONS]
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;For example:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;azdoi inventory repositories AZDOI /path/to/output
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id="options"&gt;Options&lt;/h3&gt;
&lt;p&gt;Here are some of the available options you can use with AZDOI inventory repositories command:&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Parameter&lt;/th&gt;
&lt;th&gt;Description&lt;/th&gt;
&lt;th&gt;Default Value&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--help&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Used to get help with parameters&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--pat&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Personal Access Token for authentication&lt;/td&gt;
&lt;td&gt;Environment variable: AZDOI_PAT&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--entra-id-auth&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Use Entra ID for Azure DevOps Authentication&lt;/td&gt;
&lt;td&gt;False&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--azure-tenant-id&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Entra Azure Tenant ID for authentication&lt;/td&gt;
&lt;td&gt;Environment variable: AZURE_TENANT_ID&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--include-project&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Include specific projects&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--exclude-project&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Exclude specific projects&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--include-repository&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Include specific repositories&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--exclude-repository&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Exclude specific repositories&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--include-repository-readme&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Include specific repository README&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--exclude-repository-readme&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Exclude specific repository README&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;--run-in-parallel&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Enable parallel processing of projects&lt;/td&gt;
&lt;td&gt;False&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;When the &lt;code&gt;--entra-id-auth&lt;/code&gt; option is specified, AZDOI will attempt to authenticate using the &lt;a href="https://learn.microsoft.com/en-us/dotnet/api/azure.identity.defaultazurecredential?view=azure-dotnet"&gt;DefaultAzureCredential&lt;/a&gt;, which tries to authorize in the following order based on your environment:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;a href="https://learn.microsoft.com/en-us/dotnet/api/azure.identity.environmentcredential?view=azure-dotnet"&gt;EnvironmentCredential&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://learn.microsoft.com/en-us/dotnet/api/azure.identity.workloadidentitycredential?view=azure-dotnet"&gt;WorkloadIdentityCredential&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://learn.microsoft.com/en-us/dotnet/api/azure.identity.managedidentitycredential?view=azure-dotnet"&gt;ManagedIdentityCredential&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://learn.microsoft.com/en-us/dotnet/api/azure.identity.sharedtokencachecredential?view=azure-dotnet"&gt;SharedTokenCacheCredential&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://learn.microsoft.com/en-us/dotnet/api/azure.identity.visualstudiocredential?view=azure-dotnet"&gt;VisualStudioCredential&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://learn.microsoft.com/en-us/dotnet/api/azure.identity.visualstudiocodecredential?view=azure-dotnet"&gt;VisualStudioCodeCredential&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://learn.microsoft.com/en-us/dotnet/api/azure.identity.azureclicredential?view=azure-dotnet"&gt;AzureCliCredential&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://learn.microsoft.com/en-us/dotnet/api/azure.identity.azurepowershellcredential?view=azure-dotnet"&gt;AzurePowerShellCredential&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://learn.microsoft.com/en-us/dotnet/api/azure.identity.azuredeveloperclicredential?view=azure-dotnet"&gt;AzureDeveloperCliCredential&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://learn.microsoft.com/en-us/dotnet/api/azure.identity.interactivebrowsercredential?view=azure-dotnet"&gt;InteractiveBrowserCredential&lt;/a&gt;&lt;/li&gt;
&lt;/ol&gt;
&lt;h2 id="devops-pipeline"&gt;DevOps Pipeline&lt;/h2&gt;
&lt;p&gt;Below is a fairly minimal Azure Pipeline that runs daily to generate an inventory of Azure DevOps repositories. This pipeline uses Azure CLI authentication and uploads the results as a pipeline artifact.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-yaml"&gt;# azure-pipelines.yml
trigger:
  - main

schedules:
- cron: &amp;quot;0 22 * * *&amp;quot;
  displayName: &amp;quot;Daily build at 22:00&amp;quot;
  branches:
    include:
      - main
  always: true

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: AzureCLI&amp;#64;2
  displayName: 'Generate Azure DevOps Inventory'
  inputs:
    azureSubscription: 'azure-devops-inventory-tool'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      URL=&amp;quot;$(System.CollectionUri)&amp;quot;
      ORG_NAME=${URL#https://dev.azure.com/}
      ORG_NAME=${ORG_NAME%/}
      echo &amp;quot;Organization name is: $ORG_NAME&amp;quot;

      dotnet tool restore \
        &amp;amp;&amp;amp; dotnet AZDOI inventory repositories $ORG_NAME &amp;quot;$(Build.ArtifactStagingDirectory)&amp;quot; --entra-id-auth --run-in-parallel \
        &amp;amp;&amp;amp; echo '##vso[artifact.upload artifactname=AzureDevOpsDocs]$(Build.ArtifactStagingDirectory)'
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id="pipeline-configuration-explanation"&gt;Pipeline Configuration Explanation&lt;/h3&gt;
&lt;p&gt;The Azure Pipeline configuration above does the following:&lt;/p&gt;
&lt;h4 id="trigger"&gt;Trigger&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;The pipeline runs automatically when changes are pushed to the &lt;code&gt;main&lt;/code&gt; branch.&lt;/li&gt;
&lt;li&gt;It is scheduled to run daily at 22:00 (10 PM) UTC through a cron schedule.&lt;/li&gt;
&lt;li&gt;The schedule is set to always run, even if there are no code changes.&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id="environment"&gt;Environment&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;It uses the latest version of Ubuntu as the build agent.&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id="steps"&gt;Steps&lt;/h4&gt;
&lt;p&gt;The pipeline has a single step using the Azure CLI task that:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Extracts the Azure DevOps organization name from the collection URI.&lt;/li&gt;
&lt;li&gt;Runs the AZDOI tool to generate an inventory of repositories by:
&lt;ul&gt;
&lt;li&gt;Restoring .NET tools.&lt;/li&gt;
&lt;li&gt;Running the &lt;code&gt;inventory repositories&lt;/code&gt; command for the organization.&lt;/li&gt;
&lt;li&gt;Using Entra ID (formerly Azure AD) authentication.&lt;/li&gt;
&lt;li&gt;Running operations in parallel for better performance.&lt;/li&gt;
&lt;li&gt;Saving output to the build artifacts directory.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;Uploads the generated documentation as a build artifact named 'AzureDevOpsDocs'.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;The pipeline requires an Azure service connection named 'azure-devops-inventory-tool' with appropriate permissions to access Azure DevOps resources.&lt;/p&gt;
&lt;h2 id="conclusion"&gt;Conclusion&lt;/h2&gt;
&lt;p&gt;In this post, we introduced AZDOI, a .NET tool designed to document Azure DevOps organizations by generating a set of Markdown files. You can find the code for AZDOI at &lt;a href="https://github.com/WCOMAB/AZDOI/"&gt;GitHub&lt;/a&gt;, and the tool is available for installation via &lt;a href="https://www.nuget.org/packages/AZDOI/"&gt;NuGet&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;An example of the generated documentation can be viewed at &lt;a href="https://wcomab.github.io/AZDOI/AZDOI/"&gt;AZDOI Example Documentation&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Take it for a spin, and feel free to let us know what you think!&lt;/p&gt;
</content:encoded>
			<comments xmlns="http://purl.org/rss/1.0/modules/slash/">0</comments>
		</item>
		<item>
			<title>Static Web App WASM Search</title>
			<link>https://www.devlead.se/posts/2025/2025-03-12-static-web-app-wasm-search</link>
			<description>Discover how to add blazing-fast, bandwidth-friendly search to your static website using Pagefind - no backend required!</description>
			<author>devlead</author>
			<enclosure url="https://cdn.devlead.se/clipimg-vscode/2025/03/12/1a8c12b5-f5c2-9a13-1296-879a0995898a.png?sv=2025-01-05&amp;st=2025-03-11T06%253A09%253A49Z&amp;se=2035-03-12T06%253A09%253A49Z&amp;sr=b&amp;sp=r&amp;sig=tyhiRLHe1gghBnxLo45yhnSUsSiaUbuMQbHAM1pUNG8%253D" length="0" type="image" />
			<guid>https://www.devlead.se/posts/2025/2025-03-12-static-web-app-wasm-search</guid>
			<pubDate>Wed, 12 Mar 2025 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;Static web apps excel at delivering pre-rendered content quickly, efficiently, and cost-effectively.
However, implementing search functionality with these same benefits has traditionally required compromising the static nature by using a backend or third-party service for a good experience. In this post, I'll demonstrate how to add powerful client-side search to a static website using WebAssembly. For my blog, I'm using the &lt;a href="https://www.statiq.dev/"&gt;Statiq&lt;/a&gt; as my static site generator together with GitHub Pages as my hosting provider, but the approach described should work across most static site generators and hosting platforms.&lt;/p&gt;
&lt;h2 id="static-web-app-model"&gt;Static web app model&lt;/h2&gt;
&lt;p&gt;At its core, static web apps follow a simple yet powerful pattern. Content (the model) typically exists as markdown documents with metadata, while templates (the view) define how that content should be presented. The static site generator acts as the orchestrator, processing this separation of concerns by applying the templates to the content. The result is pre-generated static HTML files for every possible route on the site, ready to be served efficiently to visitors without any runtime processing.&lt;/p&gt;
&lt;div class="mermaid"&gt;graph LR
    subgraph Input
        direction LR
        I_M[Markdown]
        I_IMG[Images]
        I_CSS[CSS]
        I_JS[JavaScript]
        I_HTML[Dynamic&amp;lt;br/&gt;HTML Templates]
    end
    
    subgraph Generator
        direction LR
        S[Static Site Generator]
    end
    
    subgraph Output
        direction LR
        O_IMG[Images]
        O_CSS[CSS]
        O_JS[JavaScript]
        O_HTML[HTML]
    end

    subgraph Hosting
        direction LR
        H[Static Hosting Provider]
    end
    
    Input --&gt; Generator
    Generator --&gt; Output
    Output --&gt; Hosting
&lt;/div&gt;
&lt;h2 id="adding-static-search"&gt;Adding static search&lt;/h2&gt;
&lt;p&gt;In this post, we'll implement search functionality by introducing an indexing step that runs after the static site generator has completed its work but before deployment to the hosting provider. This additional step analyzes the generated content and creates a search index that gets included with the site's static assets.&lt;/p&gt;
&lt;div class="mermaid"&gt;graph LR
    subgraph Input
        direction LR
        I_M[Markdown]
        I_IMG[Images]
        I_CSS[CSS]
        I_JS[JavaScript]
        I_HTML[Dynamic&amp;lt;br/&gt;HTML Templates]
    end
    
    subgraph Generator
        direction LR
        S[Static Site Generator]
    end

    subgraph Indexer
        direction LR
        I[Search Indexer]
    end
    
    subgraph Output
        direction LR
        O_IMG[Images]
        O_CSS[CSS]
        O_JS[JavaScript]
        O_HTML[HTML]
        O_INDEX[Search index]
    end

    subgraph Hosting
        direction LR
        H[Static Hosting Provider]
    end
    
    Input --&gt; Generator
    Generator --&gt; Indexer
    Indexer --&gt; Output
    Output --&gt; Hosting
&lt;/div&gt;
&lt;h2 id="pagefind"&gt;Pagefind&lt;/h2&gt;
&lt;p&gt;For this implementation, we'll use Pagefind - a powerful static search solution written in Rust. Pagefind works by analyzing your static HTML content, generating a WebAssembly-powered search index, and providing a JavaScript API for seamless integration.&lt;/p&gt;
&lt;h3 id="installing"&gt;Installing&lt;/h3&gt;
&lt;p&gt;Easiest way to obtain Pagefind is via &lt;a href="https://www.npmjs.com/package/pagefind"&gt;NPM&lt;/a&gt; (&lt;em&gt;binaries also available via its GitHub &lt;a href="https://github.com/CloudCannon/pagefind/releases"&gt;releases&lt;/a&gt; and wrapper package through &lt;a href="https://pypi.org/project/pagefind/"&gt;pypi&lt;/a&gt;&lt;/em&gt;).&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;npm install -g pagefind
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id="creating-index"&gt;Creating index&lt;/h3&gt;
&lt;p&gt;Pagefind has several parameters and configuration options available, but to get started you can simply point it to your static site's generated content. The basic command is:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;pagefind --site &amp;quot;path to generated site&amp;quot;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;This will create a &lt;code&gt;pagefind&lt;/code&gt; folder in your site output directory containing:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Compressed WebAssembly search indexes&lt;/li&gt;
&lt;li&gt;JavaScript API files&lt;/li&gt;
&lt;li&gt;CSS styles for the default UI components&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id="adding-to-your-site"&gt;Adding to your site&lt;/h3&gt;
&lt;p&gt;To add the search functionality to your site, you'll need to:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Reference the Pagefind CSS stylesheet&lt;/li&gt;
&lt;li&gt;Include the Pagefind JavaScript file&lt;/li&gt;
&lt;li&gt;Add a placeholder &lt;code&gt;&amp;lt;div&amp;gt;&lt;/code&gt; element where the search UI will be rendered&lt;/li&gt;
&lt;li&gt;Initialize the Pagefind UI when the page loads&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;Here's an example of the minimal HTML code needed:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-html"&gt;&amp;lt;link href=&amp;quot;/pagefind/pagefind-ui.css&amp;quot; rel=&amp;quot;stylesheet&amp;quot;&amp;gt;
&amp;lt;script src=&amp;quot;/pagefind/pagefind-ui.js&amp;quot;&amp;gt;&amp;lt;/script&amp;gt;
&amp;lt;div id=&amp;quot;search&amp;quot;&amp;gt;&amp;lt;/div&amp;gt;
&amp;lt;script&amp;gt;
    window.addEventListener('DOMContentLoaded', (event) =&amp;gt; {
        new PagefindUI({ element: &amp;quot;#search&amp;quot;, showSubResults: true });
    });
&amp;lt;/script&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id="integrating-with-statiq"&gt;Integrating with Statiq&lt;/h2&gt;
&lt;p&gt;Statiq has support for executing &lt;a href="https://www.statiq.dev/guide/web/external-processes"&gt;External Processes&lt;/a&gt;, these can be executed during&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Initialization: The process should be started only once before other processes on the first engine execution.&lt;/li&gt;
&lt;li&gt;BeforeExecution: The process should be started before each pipeline execution.&lt;/li&gt;
&lt;li&gt;AfterExecution: The process should be started after all pipelines have executed.&lt;/li&gt;
&lt;li&gt;BeforeDeployment: The process should be started after normal pipelines are executed and before deployment&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;Looking at my &lt;a href="https://github.com/devlead/devlead.se/blob/c58f61579cac0ad5700ba44440d75c69534fcca7/src/DevLead/Program.cs#L12C1-L21C6"&gt;Program.cs&lt;/a&gt; the integration was just a matter of adding two process steps:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Install Pagefind during initialization&lt;/li&gt;
&lt;li&gt;Execute Pagefind before deployment&lt;/li&gt;
&lt;/ol&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;    .AddProcess(
        ProcessTiming.Initialization,
        launcher =&amp;gt; new ProcessLauncher(&amp;quot;npm&amp;quot;, &amp;quot;install&amp;quot;, &amp;quot;-g&amp;quot;, &amp;quot;pagefind&amp;quot;) { 
            ContinueOnError = true
        }
    )
    .AddProcess(
        ProcessTiming.BeforeDeployment,
         launcher =&amp;gt; new ProcessLauncher(&amp;quot;pagefind&amp;quot;, &amp;quot;--site&amp;quot;, $&amp;quot;\&amp;quot;{launcher.FileSystem.OutputPath.FullPath}\&amp;quot;&amp;quot;)
    )
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Then I added the CSS to my theme's &lt;a href="https://github.com/devlead/devlead.se/blob/c58f61579cac0ad5700ba44440d75c69534fcca7/src/DevLead/input/_head.cshtml#L12"&gt;header template&lt;/a&gt;&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-html"&gt;&amp;lt;link href=&amp;quot;/pagefind/pagefind-ui.css&amp;quot; rel=&amp;quot;stylesheet&amp;quot;&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Followed by placholder div to my theme's &lt;a href="https://github.com/devlead/devlead.se/blob/c58f61579cac0ad5700ba44440d75c69534fcca7/src/DevLead/input/_footer.cshtml#L12"&gt;footer template&lt;/a&gt; where I wanted the search UI to appear.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-html"&gt; &amp;lt;div id=&amp;quot;search&amp;quot;&amp;gt;&amp;lt;/div&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Finally added the pagefind script and init code to my theme's &lt;a href="https://github.com/devlead/devlead.se/blob/c58f61579cac0ad5700ba44440d75c69534fcca7/src/DevLead/input/_scripts.cshtml#L2-L7"&gt;scripts template&lt;/a&gt;&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-html"&gt;&amp;lt;script src=&amp;quot;/pagefind/pagefind-ui.js&amp;quot;&amp;gt;&amp;lt;/script&amp;gt;
&amp;lt;script&amp;gt;
    window.addEventListener('DOMContentLoaded', (event) =&amp;gt; {
        new PagefindUI({ element: &amp;quot;#search&amp;quot;, showSubResults: true });
    });
&amp;lt;/script&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;And voilá, my site is indexed and searchable, even locally in preview mode🏆&lt;/p&gt;
&lt;p&gt;&lt;img src="https://cdn.devlead.se/clipimg-vscode/2025/03/12/1f36ee83-1f85-ab43-221c-68249a605612.png?sv=2025-01-05&amp;amp;st=2025-03-11T10%3A21%3A50Z&amp;amp;se=2035-03-12T10%3A21%3A50Z&amp;amp;sr=b&amp;amp;sp=r&amp;amp;sig=OipymFsUbYq2wNpcIGeYBFPe1WJgqgds233ZMRLeErY%3D" alt="Screenshot of search UI" /&gt;&lt;/p&gt;
&lt;h2 id="whats-indexed"&gt;What's indexed?!&lt;/h2&gt;
&lt;p&gt;By default, Pagefind will index all content it finds in your static site, which can sometimes lead to duplicate results if you have content repeated across multiple pages (like tag pages or summaries). However, Pagefind provides several HTML attributes that give you fine-grained control over what gets indexed:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;p&gt;&lt;code&gt;data-pagefind-body&lt;/code&gt;: When added to an element, only content within elements with this attribute will be indexed. If used anywhere on your site, pages without this attribute are excluded entirely.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;code&gt;data-pagefind-ignore&lt;/code&gt;: Add this to any element you want to exclude from indexing. This works even if the element is inside a &lt;code&gt;data-pagefind-body&lt;/code&gt; section.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;code&gt;data-pagefind-index-attrs&lt;/code&gt;: Allows you to specify HTML attributes to index, like image alt text or link titles.&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;These attributes gave me precise control over my search index. For example, to avoid duplicate results from tag pages and summaries, I added &lt;code&gt;data-pagefind-body&lt;/code&gt; only to the main content of my blog posts in my &lt;a href="https://github.com/devlead/devlead.se/blob/c58f61579cac0ad5700ba44440d75c69534fcca7/src/DevLead/input/_layout.cshtml#L90"&gt;layout template&lt;/a&gt;&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-c#"&gt; &amp;lt;div id=&amp;quot;content&amp;quot; class=&amp;quot;col-md-12&amp;quot; &amp;#64;(Document.GetBool(&amp;quot;IsPost&amp;quot;) ? &amp;quot;data-pagefind-body&amp;quot; : &amp;quot;&amp;quot;) &amp;gt;  
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id="potential-gotchas"&gt;Potential gotchas&lt;/h2&gt;
&lt;h3 id="cdn"&gt;CDN&lt;/h3&gt;
&lt;p&gt;Images in search results are HTML encoded, which worked with local images but caused issues with my CDN. Fortunately, the Pagefind JS API provides a &lt;code&gt;processResult&lt;/code&gt; callback so you can post-process the search result data model before it's returned to the search result UI. I modified my &lt;a href="https://github.com/devlead/devlead.se/blob/0b464f8f8abfbcdb0f478955bcefbed1f046d9c1/src/DevLead/input/_scripts.cshtml#L8-L11"&gt;scripts template&lt;/a&gt; in the Pagefind initialization to unencode the characters causing issues with my CDN.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-html"&gt;&amp;lt;script&amp;gt;
    window.addEventListener('DOMContentLoaded', (event) =&amp;gt; {
        new PagefindUI({ 
            element: &amp;quot;#search&amp;quot;,
            showSubResults: true,
             processResult: function (result) { 
                result.meta.image = result.meta.image.replaceAll(&amp;quot;&amp;amp;amp;&amp;quot;, &amp;quot;&amp;amp;&amp;quot;);
                return result;
            }
        });
        
    });
&amp;lt;/script&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id="compression"&gt;Compression&lt;/h3&gt;
&lt;p&gt;Pagefind compresses its index files during indexing so they can be served as-is without the need to be compressed by the HTTP server. This generally works seamlessly with hosting providers like GitHub Pages and Azure Static Web Apps. However, in some situations, depending on your configuration, you might need to either:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Opt-out of compression for these already compressed files, or&lt;/li&gt;
&lt;li&gt;Add headers to indicate that they're compressed / should be served&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;For example, with Azure App Service, your &lt;code&gt;web.config&lt;/code&gt; needs to add the MIME types and headers to indicate compression. Here's how that configuration might look:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-xml"&gt;&amp;lt;configuration&amp;gt;
  &amp;lt;system.webServer&amp;gt;
    &amp;lt;staticContent&amp;gt;
      &amp;lt;mimeMap fileExtension=&amp;quot;.pf_fragment&amp;quot; mimeType=&amp;quot;application/pf_fragment&amp;quot; /&amp;gt;
      &amp;lt;mimeMap fileExtension=&amp;quot;.pf_index&amp;quot; mimeType=&amp;quot;application/pf_index&amp;quot; /&amp;gt;
      &amp;lt;mimeMap fileExtension=&amp;quot;.pf_meta&amp;quot; mimeType=&amp;quot;application/pf_meta&amp;quot; /&amp;gt;
      &amp;lt;mimeMap fileExtension=&amp;quot;.pagefind&amp;quot; mimeType=&amp;quot;application/pagefind&amp;quot; /&amp;gt;
    &amp;lt;/staticContent&amp;gt;
    &amp;lt;rewrite&amp;gt;
      &amp;lt;outboundRules&amp;gt;
        &amp;lt;rule name=&amp;quot;Add gzip Content-Encoding for specific extensions&amp;quot;&amp;gt;
          &amp;lt;match serverVariable=&amp;quot;RESPONSE_Content-Encoding&amp;quot; pattern=&amp;quot;.*&amp;quot; /&amp;gt;
          &amp;lt;conditions logicalGrouping=&amp;quot;MatchAny&amp;quot;&amp;gt;
            &amp;lt;add input=&amp;quot;{REQUEST_FILENAME}&amp;quot; pattern=&amp;quot;\.pf_fragment$&amp;quot; /&amp;gt;
            &amp;lt;add input=&amp;quot;{REQUEST_FILENAME}&amp;quot; pattern=&amp;quot;\.pf_index$&amp;quot; /&amp;gt;
            &amp;lt;add input=&amp;quot;{REQUEST_FILENAME}&amp;quot; pattern=&amp;quot;\.pf_meta$&amp;quot; /&amp;gt;
            &amp;lt;add input=&amp;quot;{REQUEST_FILENAME}&amp;quot; pattern=&amp;quot;\.pagefind$&amp;quot; /&amp;gt;
          &amp;lt;/conditions&amp;gt;
          &amp;lt;action type=&amp;quot;Rewrite&amp;quot; value=&amp;quot;gzip&amp;quot; /&amp;gt;
        &amp;lt;/rule&amp;gt;
      &amp;lt;/outboundRules&amp;gt;
    &amp;lt;/rewrite&amp;gt;
  &amp;lt;/system.webServer&amp;gt;
&amp;lt;/configuration&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id="conclusion"&gt;Conclusion&lt;/h2&gt;
&lt;p&gt;Adding search functionality to a static website no longer requires compromising its static nature. &lt;a href="https://pagefind.app/"&gt;Pagefind&lt;/a&gt; provides a straightforward solution that maintains the benefits of static sites through its WebAssembly-powered approach. With excellent &lt;a href="https://pagefind.app/"&gt;documentation&lt;/a&gt; and an active open-source &lt;a href="https://github.com/cloudcannon/pagefind"&gt;project&lt;/a&gt;, implementing powerful client-side search has never been more accessible.&lt;/p&gt;
&lt;p&gt;By following the steps outlined in this post, you can add robust search functionality to your static site while maintaining its performance, efficiency, and cost-effectiveness.&lt;/p&gt;
&lt;p&gt;So Pagefind is worth taking for a spin, and feel free to let me know what you think!&lt;/p&gt;
</content:encoded>
			<comments xmlns="http://purl.org/rss/1.0/modules/slash/">0</comments>
		</item>
		<item>
			<title>SLNX Finally here📄</title>
			<link>https://www.devlead.se/posts/2025/2025-02-24-slnx-finally-here</link>
			<description>The new .NET solution format has evolved from being messy and bloated to being focused and clean</description>
			<author>devlead</author>
			<enclosure url="https://cdn.devlead.se/clipimg-vscode/2025/02/24/b83c06ea-69c7-be32-31cd-da3c5e6a5173.png?sv=2025-01-05&amp;st=2025-02-23T06%253A49%253A41Z&amp;se=2035-02-24T06%253A49%253A41Z&amp;sr=b&amp;sp=r&amp;sig=B0uwPpXawEe%252BfbdTgsiNHrULc3f6zv%252BUgHR%252Fdk3tlQA%253D" length="0" type="image" />
			<guid>https://www.devlead.se/posts/2025/2025-02-24-slnx-finally-here</guid>
			<pubDate>Mon, 24 Feb 2025 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;The Visual Studio solution files have long been an explicit and messy format, with lots of configuration that could be inferred from conventions. However, with the release of the latest .NET 9 SDK (9.0.200) earlier this month, things have changed. The new XML-based solution format, SLNX, is now out of preview, bringing clean, convention-based defaults while still allowing for explicit configuration when needed.&lt;/p&gt;
&lt;h2 id="what-has-changed"&gt;What has changed?&lt;/h2&gt;
&lt;p&gt;Let's look at a simple &amp;quot;Hello World&amp;quot; example to illustrate the difference between the old and new formats.&lt;/p&gt;
&lt;h3 id="traditional.sln-file-helloworld.sln"&gt;Traditional .sln file - HelloWorld.sln&lt;/h3&gt;
&lt;pre&gt;&lt;code class="language-ini"&gt;Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 17
VisualStudioVersion = 17.0.31903.59
MinimumVisualStudioVersion = 10.0.40219.1
Project(&amp;quot;{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}&amp;quot;) = &amp;quot;HelloWorld&amp;quot;, &amp;quot;HelloWorld\HelloWorld.csproj&amp;quot;, &amp;quot;{979C8E48-A2EA-4647-A3A1-8647AB5F20C6}&amp;quot;
EndProject
Project(&amp;quot;{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}&amp;quot;) = &amp;quot;HelloWorld.Tests&amp;quot;, &amp;quot;HelloWorld.Tests\HelloWorld.Tests.csproj&amp;quot;, &amp;quot;{3B7AB8F1-88C0-4303-856B-A1E1EDE0A736}&amp;quot;
EndProject
Global
        GlobalSection(SolutionConfigurationPlatforms) = preSolution
                Debug|Any CPU = Debug|Any CPU
                Debug|x64 = Debug|x64
                Debug|x86 = Debug|x86
                Release|Any CPU = Release|Any CPU
                Release|x64 = Release|x64
                Release|x86 = Release|x86
        EndGlobalSection
        GlobalSection(ProjectConfigurationPlatforms) = postSolution
                {979C8E48-A2EA-4647-A3A1-8647AB5F20C6}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
                {979C8E48-A2EA-4647-A3A1-8647AB5F20C6}.Debug|Any CPU.Build.0 = Debug|Any CPU
                {979C8E48-A2EA-4647-A3A1-8647AB5F20C6}.Debug|x64.ActiveCfg = Debug|Any CPU
                {979C8E48-A2EA-4647-A3A1-8647AB5F20C6}.Debug|x64.Build.0 = Debug|Any CPU
                {979C8E48-A2EA-4647-A3A1-8647AB5F20C6}.Debug|x86.ActiveCfg = Debug|Any CPU
                {979C8E48-A2EA-4647-A3A1-8647AB5F20C6}.Debug|x86.Build.0 = Debug|Any CPU
                {979C8E48-A2EA-4647-A3A1-8647AB5F20C6}.Release|Any CPU.ActiveCfg = Release|Any CPU
                {979C8E48-A2EA-4647-A3A1-8647AB5F20C6}.Release|Any CPU.Build.0 = Release|Any CPU
                {979C8E48-A2EA-4647-A3A1-8647AB5F20C6}.Release|x64.ActiveCfg = Release|Any CPU
                {979C8E48-A2EA-4647-A3A1-8647AB5F20C6}.Release|x64.Build.0 = Release|Any CPU
                {979C8E48-A2EA-4647-A3A1-8647AB5F20C6}.Release|x86.ActiveCfg = Release|Any CPU
                {979C8E48-A2EA-4647-A3A1-8647AB5F20C6}.Release|x86.Build.0 = Release|Any CPU
                {3B7AB8F1-88C0-4303-856B-A1E1EDE0A736}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
                {3B7AB8F1-88C0-4303-856B-A1E1EDE0A736}.Debug|Any CPU.Build.0 = Debug|Any CPU
                {3B7AB8F1-88C0-4303-856B-A1E1EDE0A736}.Debug|x64.ActiveCfg = Debug|Any CPU
                {3B7AB8F1-88C0-4303-856B-A1E1EDE0A736}.Debug|x64.Build.0 = Debug|Any CPU
                {3B7AB8F1-88C0-4303-856B-A1E1EDE0A736}.Debug|x86.ActiveCfg = Debug|Any CPU
                {3B7AB8F1-88C0-4303-856B-A1E1EDE0A736}.Debug|x86.Build.0 = Debug|Any CPU
                {3B7AB8F1-88C0-4303-856B-A1E1EDE0A736}.Release|Any CPU.ActiveCfg = Release|Any CPU
                {3B7AB8F1-88C0-4303-856B-A1E1EDE0A736}.Release|Any CPU.Build.0 = Release|Any CPU
                {3B7AB8F1-88C0-4303-856B-A1E1EDE0A736}.Release|x64.ActiveCfg = Release|Any CPU
                {3B7AB8F1-88C0-4303-856B-A1E1EDE0A736}.Release|x64.Build.0 = Release|Any CPU
                {3B7AB8F1-88C0-4303-856B-A1E1EDE0A736}.Release|x86.ActiveCfg = Release|Any CPU
                {3B7AB8F1-88C0-4303-856B-A1E1EDE0A736}.Release|x86.Build.0 = Release|Any CPU
        EndGlobalSection
        GlobalSection(SolutionProperties) = preSolution
                HideSolutionNode = FALSE
        EndGlobalSection
EndGlobal
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id="new-slnx-file-helloworld.slnx"&gt;New SLNX file - HelloWorld.slnx&lt;/h3&gt;
&lt;pre&gt;&lt;code class="language-xml"&gt;&amp;lt;Solution&amp;gt;
    &amp;lt;Project Path=&amp;quot;HelloWorld/HelloWorld.csproj&amp;quot; /&amp;gt;
    &amp;lt;Project Path=&amp;quot;HelloWorld.Tests/HelloWorld.Tests.csproj&amp;quot; /&amp;gt;
&amp;lt;/Solution&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The code speaks for itself. The SLNX file is much cleaner and easier to read, with sensible defaults mean you only add exceptions when needed.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting started&lt;/h2&gt;
&lt;h3 id="prerequisites"&gt;Prerequisites&lt;/h3&gt;
&lt;p&gt;To get started with the new SLNX format, you need to update your .NET SDK to version &lt;code&gt;9.0.200&lt;/code&gt; or later. You can verify your current version by running the following command:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;dotnet --version
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;If you need to update, you can download the latest version from &lt;a href="https://get.dot.net/"&gt;https://get.dot.net/&lt;/a&gt; or update using the Visual Studio installer.&lt;/p&gt;
&lt;p&gt;For Visual Studio you might still need to enable the new format under &lt;code&gt;Tools&lt;/code&gt; -&amp;gt; &lt;code&gt;Options&lt;/code&gt; -&amp;gt; &lt;code&gt;Environment&lt;/code&gt; -&amp;gt; &lt;code&gt;Preview Features&lt;/code&gt; -&amp;gt; &lt;code&gt;Use Solution File Persistence Model&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;&lt;img src="https://cdn.devlead.se/clipimg-vscode/2025/02/24/a21f4139-6e77-b134-9d45-efefaced787e.png?sv=2025-01-05&amp;amp;st=2025-02-23T07%3A22%3A06Z&amp;amp;se=2035-02-24T07%3A22%3A06Z&amp;amp;sr=b&amp;amp;sp=r&amp;amp;sig=IPOH7kSyA1xh2njkGtiwEA6OPmalNNGKd2pJz348ZKw%3D" alt="Visual Studio Tools Options - Enable SLNX" /&gt;&lt;/p&gt;
&lt;h3 id="create-a-new-slnx-file"&gt;Create a new SLNX file&lt;/h3&gt;
&lt;p&gt;To create a new &lt;code&gt;SLNX&lt;/code&gt; file, you can use the following command:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;dotnet new sln --format slnx
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;This will create a new solution file with the SLNX format.&lt;/p&gt;
&lt;h3 id="convert-an-existing.sln-file-to-slnx"&gt;Convert an existing &lt;code&gt;.sln&lt;/code&gt; file to SLNX&lt;/h3&gt;
&lt;p&gt;To convert an existing &lt;code&gt;.sln&lt;/code&gt; file to SLNX, you can use the following command:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;dotnet sln migrate &amp;lt;SLN_FILE&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;i.e.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;dotnet sln migrate HelloWorld.sln
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;This will create a new solution file with the SLNX format based on the existing &lt;code&gt;.sln&lt;/code&gt; file.&lt;/p&gt;
&lt;h2 id="working-with-slnx-programmatically"&gt;Working with SLNX programmatically&lt;/h2&gt;
&lt;p&gt;Microsoft provides the &lt;a href="https://www.nuget.org/packages/Microsoft.VisualStudio.SolutionPersistence"&gt;Microsoft.VisualStudio.SolutionPersistence&lt;/a&gt; NuGet package, which provides a clean API for working with both traditional &lt;code&gt;.sln&lt;/code&gt; and new &lt;code&gt;.slnx&lt;/code&gt; files programmatically.&lt;/p&gt;
&lt;p&gt;The entry point to serializers can be found on the &lt;code&gt;SolutionSerializers&lt;/code&gt; static class. This has the helper &lt;code&gt;GetSerializerByMoniker&lt;/code&gt; that can pick the serializer for a file extension, or a specific serializers can be used.&lt;/p&gt;
&lt;p&gt;Here's a simple example of how to read and write SLNX files:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;using Microsoft.VisualStudio.SolutionPersistence.Serializer;

// Open and deserialize the SLNX file
var solution = await SolutionSerializers.SlnXml.OpenAsync(&amp;quot;HelloWorld.slnx&amp;quot;, cancellationToken);

// Iterate through all projects in the solution
foreach (var project in solution.SolutionProjects)
{
        // Print the file path of each project
        Console.WriteLine(project.FilePath);
}
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;More examples can be found in the project GitHub wiki at &lt;a href="https://github.com/microsoft/vs-solutionpersistence/wiki/Samples"&gt;github.com/microsoft/vs-solutionpersistence/wiki/Samples&lt;/a&gt;.&lt;/p&gt;
&lt;h2 id="conclusion"&gt;Conclusion&lt;/h2&gt;
&lt;p&gt;The new SLNX format is a great step forward, bringing clean, convention-based defaults while still allowing explicit configuration when needed. I belive this longterm will improve tooling and maintainability of solution files. It will also improve the developer experience by simplifying authoring and maintenance, reducing merge conflicts, and making it easier to sort them when they occur.&lt;/p&gt;
&lt;p&gt;So if you haven't already, give it a try and let me know what you think!&lt;/p&gt;
</content:encoded>
			<comments xmlns="http://purl.org/rss/1.0/modules/slash/">0</comments>
		</item>
		<item>
			<title>Long paths in Git on Windows</title>
			<link>https://www.devlead.se/posts/2025/2025-02-19-git-windows-long-paths</link>
			<description>How to deal with long paths in Git on Windows</description>
			<author>devlead</author>
			<enclosure url="https://cdn.devlead.se/clipimg-vscode/2025/02/19/d6040277-0b3f-4d2d-96be-356c4b5e8625.png?sv=2023-01-03&amp;st=2025-02-19T19%253A10%253A42Z&amp;se=2035-01-19T19%253A10%253A00Z&amp;sr=b&amp;sp=r&amp;sig=f7JFWYHcFzUGKxOb4ihKJe9rt2bP%252BbIm%252Bk5LfJaTH6E%253D" length="0" type="image" />
			<guid>https://www.devlead.se/posts/2025/2025-02-19-git-windows-long-paths</guid>
			<pubDate>Wed, 19 Feb 2025 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;On Windows, it's not unlikely that you'll encounter issues where you either have a repo that won't clone or files that won't commit. One common scenario that causes this is when doing snapshot testing, particularly with parameterized tests. These tests often generate snapshot files with names that include the test parameters, resulting in very long filenames.
One workaround is to move folders into the root of drives or create shorter names, but ultimately, this will cause issues sooner or later.&lt;/p&gt;
&lt;p&gt;Fortunately, Windows can handle long files, but it's opt-in for legacy and compatibility reasons.&lt;/p&gt;
&lt;h2 id="enabling-long-paths-in-git"&gt;Enabling Long Paths in Git&lt;/h2&gt;
&lt;p&gt;To enable long paths in Git, you can set the following system configuration:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-bash"&gt;git config --system core.longpaths true
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id="enabling-long-paths-in-visual-studio"&gt;Enabling Long Paths in Visual Studio&lt;/h2&gt;
&lt;p&gt;For Visual Studio, you need to enable long paths by setting a Windows Registry Key. You can do this using PowerShell with the following command:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-PowerShell"&gt;New-ItemProperty `
    -Path &amp;quot;HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem&amp;quot; `
    -Name &amp;quot;LongPathsEnabled&amp;quot; `
    -Value 1 `
    -PropertyType DWORD `
    -Force
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;By following these steps, you can avoid the common pitfalls associated with long file and directory names in your Git repositories on Windows.&lt;/p&gt;
&lt;h3 id="disclaimer"&gt;Disclaimer&lt;/h3&gt;
&lt;p&gt;This isn't a silver bullet. While enabling long paths in Windows and Git helps in most scenarios, it's not a complete solution for all situations. Some workloads in Visual Studio can still encounter issues, particularly when paths are passed to other processes like legacy .NET Framework-based tools. If this is your process, you might want to consider using the &lt;a href="https://www.nuget.org/packages/Pri.LongPath"&gt;Pri.LongPath NuGet package&lt;/a&gt;, which provides drop-in replacements for System.IO APIs that handle long paths correctly.&lt;/p&gt;
</content:encoded>
			<comments xmlns="http://purl.org/rss/1.0/modules/slash/">0</comments>
		</item>
		<item>
			<title>Introducing Devlead.Testing.MockHttp</title>
			<link>https://www.devlead.se/posts/2025/2025-02-16-introducing-mockhttp-testing</link>
			<description>An opinionated .NET source package for mocking HTTP client requests</description>
			<author>devlead</author>
			<enclosure url="https://cdn.devlead.se/clipimg-vscode/2025/02/15/48b2ec90-3c5d-4bfb-9d12-838867e50011.png?sv=2023-01-03&amp;st=2025-02-15T20%253A33%253A23Z&amp;se=2031-02-16T20%253A33%253A00Z&amp;sr=b&amp;sp=r&amp;sig=OqeViFR%252B2YKVMXEVKWn6wC0g%252B3NtrxfUcfDS%252FASFOjY%253D" length="0" type="image" />
			<guid>https://www.devlead.se/posts/2025/2025-02-16-introducing-mockhttp-testing</guid>
			<pubDate>Sun, 16 Feb 2025 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;There are undoubtedly many sophisticated and comprehensive solutions out there for mocking HTTP requests in .NET applications. However, I found myself with a very specific need: I wanted a lightweight, low-friction way to mock third-party HTTP APIs within my unit tests, without a lot of ceremony or complexity. I needed something that was &amp;quot;good enough&amp;quot; for my use case, providing in-memory request/response simulation that would let me validate my HTTP client interactions.&lt;/p&gt;
&lt;p&gt;That's why I created Devlead.Testing.MockHttp. It's not trying to be the most feature-complete or elegant solution; it simply aims to solve this specific testing scenario in a straightforward way, with a minimum of ceremony, mimicking how the tested code would be used in a real application. If you have similar needs for basic HTTP mocking in your unit tests, this might be useful for you too.&lt;/p&gt;
&lt;p&gt;Even though it has a fairly limited scope, it still enables testing of a wide range of scenarios, i.e., validating request headers, status codes, authentication, and even a small state machine for testing retry logic/throttling and requiring certain requests to be made before others.&lt;/p&gt;
&lt;h2 id="overview-diagram"&gt;Overview diagram&lt;/h2&gt;
&lt;div class="mermaid"&gt;graph TB
    
    subgraph unit["Unit test"]
        direction TB
        Test1 &amp;lt;--"GET Index.html"--&gt; testioc
        Test2 &amp;lt;--"POST Api.json"--&gt; testioc 
        Test3 &amp;lt;--"PUT SecretApi.json"--&gt; testioc
    end

    subgraph testioc["ServiceProviderFixture&amp;amp;nbsp;(Test&amp;amp;nbsp;Inversion&amp;amp;nbsp;of&amp;amp;nbsp;Control&amp;amp;nbsp;Container)"]
        direction TB
        MyService{{"MyService(HttpClient&amp;amp;nbsp;client)"}}
        Mock{{"MockHttpClient:HttpClient&amp;lt;br/&gt;MockHttpClientFactory:IHttpClientFactory&amp;lt;br/&gt;MockHttpMessageHandlerFactory:IHttpMessageHandlerFactory"}}
        MyService &amp;lt;--&gt; Mock
    end

    subgraph mockhttp["Router"]
        direction TB
        Router&amp;#64;{ shape: procs, label: "HttpRequestMessage&amp;lt;br/&gt;to&amp;lt;br/&gt;HttpResponseMessage"}
    end

    subgraph assembly["Assembly&amp;amp;nbsp;Embedded&amp;amp;nbsp;Resources"]
        direction BT 
        Routes["Routes.json"]    
        Index["Index.html"]
        Api&amp;#64;{ shape: doc, label: "Api.json"}
        SecretApi&amp;#64;{ shape: doc, label: "SecretApi.json"}
        Index --&gt; Routes  
        Api --&gt; Routes
        SecretApi --&gt; Routes
    end

    testioc &amp;lt;--&gt; mockhttp
    mockhttp &amp;lt;-- Routes&amp;lt;/br&gt;configuration --&gt; assembly
&lt;/div&gt;
&lt;h2 id="dependency-injection-in-unit-tests"&gt;Dependency injection in unit tests?&lt;/h2&gt;
&lt;p&gt;My goal was to ensure that the unit test for constructing fixtures and object code closely resembles how they are used in real applications. For instance, if resolving your HTTP client is simply done with &lt;code&gt;AddHttpClient&amp;lt;MyService&amp;gt;()&lt;/code&gt; in the application, then that should be all that's needed for it to be resolved in tests. By using an IOC container to resolve the services, it ensures that the same logic to construct the services is used in the tests as in the application. It also makes tests more resilient to changes in the service construction logic, especially if you use common extension methods to configure the services.&lt;/p&gt;
&lt;p&gt;Let's walk through an example of that.&lt;/p&gt;
&lt;h3 id="example-service"&gt;Example Service&lt;/h3&gt;
&lt;p&gt;The service is a simple class that uses an &lt;code&gt;HttpClient&lt;/code&gt; to fetch data from a couple of different endpoints.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;public class MyService(HttpClient httpClient)
{
    public async Task&amp;lt;string&amp;gt; GetData()
    {
        var response = await httpClient.GetAsync(&amp;quot;https://example.com/index.txt&amp;quot;);
        return await response.Content.ReadAsStringAsync();
    }

    public async Task&amp;lt;User?&amp;gt; GetSecret()
    {
        return await httpClient.GetFromJsonAsync&amp;lt;User&amp;gt;(&amp;quot;https://example.com/login/secret.json&amp;quot;);
    }
}
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id="example-unit-test"&gt;Example Unit Test&lt;/h3&gt;
&lt;p&gt;The unit tests below are NUnit tests that verify the behavior of the &lt;code&gt;MyService&lt;/code&gt; class using &lt;code&gt;Devlead.Testing.MockHttp.Tests&lt;/code&gt; provided &lt;code&gt;ServiceProviderFixture&lt;/code&gt; to resolve the service. Methods are called as usual, and the results are snapshotted using &lt;a href="https://github.com/VerifyTests/Verify"&gt;Verify&lt;/a&gt;. Any exceptions or changes in the response are asserted and will fail the test.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;public class MyServiceTests
{
    [Test]
    public async Task GetData()
    {
        // Given
        var myService = ServiceProviderFixture.GetRequiredService&amp;lt;MyService&amp;gt;();

        // When
        var result = await myService.GetData();

        // Then
        await Verify(result);
    }

    [Test]
    public async Task GetUnauthorizedSecret()
    {
        // Given
        var myService = ServiceProviderFixture.GetRequiredService&amp;lt;MyService&amp;gt;();

        // When 
        var result = Assert.CatchAsync&amp;lt;HttpRequestException&amp;gt;(myService.GetSecret);

        // Then
        await Verify(result);
    }

    [Test]
    public async Task GetSecret()
    {
        // Given
        var myService = ServiceProviderFixture.GetRequiredService&amp;lt;MyService&amp;gt;(
                            configure =&amp;gt; configure.ConfigureMockHttpClient&amp;lt;Constants&amp;gt;(
                                            client =&amp;gt; client.DefaultRequestHeaders.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue(
                                                &amp;quot;Bearer&amp;quot;,
                                                &amp;quot;AccessToken&amp;quot;
                                                )
                                        )
                            );

        // When
        var result = await myService.GetSecret();

        // Then
        await Verify(result);
    }
}
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id="registering-the-service"&gt;Registering the service&lt;/h3&gt;
&lt;p&gt;The project provides a &lt;code&gt;ServiceProviderFixture&lt;/code&gt; partial class, which contains IOC helpers and a partial method &lt;code&gt;InitServiceProvider&lt;/code&gt; for you to implement to register your own registrations and any of their dependencies. In theory, your project could have multiple mocked routes within the same project, and &lt;code&gt;.AddMockHttpClient&amp;lt;Constants&amp;gt;()&lt;/code&gt; below picks up the routes from the assembly embedded resources relative to the type parameter &lt;code&gt;Constants&lt;/code&gt;.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;public static partial class ServiceProviderFixture
{
    static partial void InitServiceProvider(IServiceCollection services)
    {
        services.AddHttpClient&amp;lt;MyService&amp;gt;()
                .AddMockHttpClient&amp;lt;Constants&amp;gt;();
    }
}
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Services and instances registered in the &lt;code&gt;InitServiceProvider&lt;/code&gt; method will be available for all unit tests and can be resolved using the &lt;code&gt;ServiceProviderFixture.GetRequiredService&amp;lt;T&amp;gt;()&lt;/code&gt; method, as shown in the example unit test above. You can also register instances/services for a specific test or even configure the registrations using a delegate, as shown in the &lt;code&gt;GetSecret&lt;/code&gt; test.&lt;/p&gt;
&lt;p&gt;&lt;code&gt;GetRequiredService&lt;/code&gt; can resolve up to seven different types by passing one to seven type arguments, and each call to &lt;code&gt;GetRequiredService&lt;/code&gt; will create a new separate isolated IOC container instance, ensuring that each test can have its own isolated dependencies.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;var myService = ServiceProviderFixture
                    .GetRequiredService&amp;lt;MyService&amp;gt;();

var (
        myService,
        myService2
    ) = ServiceProviderFixture
            .GetRequiredService&amp;lt;MyService, MyService2&amp;gt;();

...

var (
        myService,
        myService2,
        myService3,
        myService4,
        myService5,
        myService6,
        myService7
    ) = ServiceProviderFixture
            .GetRequiredService&amp;lt;MyService, MyService2, MyService3, MyService4, MyService5, MyService6, MyService7&amp;gt;();
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;This makes it easy to resolve multiple services in a single test or even resolve the same service multiple times with different configurations.&lt;/p&gt;
&lt;p&gt;For example, resolving a &lt;code&gt;TimeProvider&lt;/code&gt; for testing date/time-related functionality and your service that uses it.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;// Given
var (
        timeProvider,
        myService
    ) = ServiceProviderFixture
            .GetRequiredService&amp;lt;FakeTimeProvider, MyService&amp;gt;();

// When
var result = myService.GetData();
var cachedResult = myService.GetData();
timeProvider.Advance(TimeSpan.FromDays(1));
var uncachedResult = myService.GetData();

// Then
await Verify(
    new {
        result,
        cachedResult,
        uncachedResult
    }
);
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id="registering-routes"&gt;Registering routes&lt;/h3&gt;
&lt;p&gt;Routes are configured using the &lt;code&gt;Routes.json&lt;/code&gt; file, which is embedded as an assembly resource. The file is used to configure the &lt;code&gt;Router&lt;/code&gt;, which is responsible for matching incoming requests to the correct response. The file is placed in a &amp;quot;Routes&amp;quot; folder relative to the type parameter used in &lt;code&gt;.AddMockHttpClient&amp;lt;T&amp;gt;()&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;The example routes file below provides two endpoints available via GET requests. The secret endpoint requires an access token in the Authorization header, while the index endpoint does not.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-json"&gt;[
  {
    &amp;quot;Request&amp;quot;: {
      &amp;quot;Methods&amp;quot;: [
        {
          &amp;quot;Method&amp;quot;: &amp;quot;GET&amp;quot;
        }
      ],
      &amp;quot;AbsoluteUri&amp;quot;: &amp;quot;https://example.com/login/secret.json&amp;quot;
    },
    &amp;quot;Responses&amp;quot;: [
      {
        &amp;quot;RequestHeaders&amp;quot;: {},
        &amp;quot;ContentResource&amp;quot;: &amp;quot;Example.Login.Secret.json&amp;quot;,
        &amp;quot;ContentType&amp;quot;: &amp;quot;application/json&amp;quot;,
        &amp;quot;ContentHeaders&amp;quot;: {},
        &amp;quot;StatusCode&amp;quot;: 200
      }
    ],
    &amp;quot;Authorization&amp;quot;: {
      &amp;quot;Authorization&amp;quot;: [
        &amp;quot;Bearer AccessToken&amp;quot;
      ]
    }
  },
  {
    &amp;quot;Request&amp;quot;: {
      &amp;quot;Methods&amp;quot;: [
        {
          &amp;quot;Method&amp;quot;: &amp;quot;GET&amp;quot;
        }
      ],
      &amp;quot;AbsoluteUri&amp;quot;: &amp;quot;https://example.com/index.txt&amp;quot;
    },
    &amp;quot;Responses&amp;quot;: [
      {
        &amp;quot;RequestHeaders&amp;quot;: {},
        &amp;quot;ContentResource&amp;quot;: &amp;quot;Example.Index.txt&amp;quot;,
        &amp;quot;ContentType&amp;quot;: &amp;quot;text/plain&amp;quot;,
        &amp;quot;ContentHeaders&amp;quot;: {},
        &amp;quot;StatusCode&amp;quot;: 200
      }
    ]
  }
]
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The &lt;code&gt;Router&lt;/code&gt; will match the request to the correct response based on the request method and absolute URI. If the request doesn't match any of the routes, a 404 Not Found response is returned. If authentication is required, the &lt;code&gt;Authorization&lt;/code&gt; section is used to validate the request headers against the configured values, and a 401 Unauthorized response is returned if it doesn't match.&lt;/p&gt;
&lt;h3 id="route-content"&gt;Route content&lt;/h3&gt;
&lt;p&gt;The content of the response is fetched from the assembly embedded resources, which is configured using the &lt;code&gt;ContentResource&lt;/code&gt; property. The content is read as a stream and converted to the appropriate content type. This means that the content can be a JSON file, a text file, an image, or even a binary file. The files specified in &lt;code&gt;ContentResource&lt;/code&gt; are relative to the &lt;code&gt;Routes.json&lt;/code&gt; file, i.e., the above configuration would have a folder structure like this:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;Constants.cs
Resources/Routes.json
Resources/Example/Index.txt
Resources/Example/Login/Secret.json
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;As with any embedded resource, directory separators are normalized to &lt;code&gt;.&lt;/code&gt; in the &lt;code&gt;ContentResource&lt;/code&gt; path. For example, &lt;code&gt;Example/Login/Secret.json&lt;/code&gt; above would be &lt;code&gt;Example.Login.Secret.json&lt;/code&gt; in the &lt;code&gt;Routes.json&lt;/code&gt; file.&lt;/p&gt;
&lt;p&gt;In your &lt;code&gt;.csproj&lt;/code&gt;, it would be configured something like this:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-xml"&gt;&amp;lt;ItemGroup&amp;gt;
    &amp;lt;None Remove=&amp;quot;Resources\Example\index.txt&amp;quot; /&amp;gt;
    &amp;lt;None Remove=&amp;quot;Resources\Example\Login\Secret.json&amp;quot; /&amp;gt;
    &amp;lt;None Remove=&amp;quot;Resources\Routes.json&amp;quot; /&amp;gt;
&amp;lt;/ItemGroup&amp;gt;

&amp;lt;ItemGroup&amp;gt;
    &amp;lt;EmbeddedResource Include=&amp;quot;Resources\Example\Index.txt&amp;quot; /&amp;gt;
    &amp;lt;EmbeddedResource Include=&amp;quot;Resources\Routes.json&amp;quot; /&amp;gt;
    &amp;lt;EmbeddedResource Include=&amp;quot;Resources\Example\Login\Secret.json&amp;quot; /&amp;gt;
&amp;lt;/ItemGroup&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id="advanced-scenarios"&gt;Advanced scenarios&lt;/h2&gt;
&lt;h3 id="state-machine"&gt;State machine&lt;/h3&gt;
&lt;p&gt;Routes can be configured to require certain requests to be made before others. This is done by setting the request to disabled:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-json"&gt;...
    &amp;quot;Request&amp;quot;: {
      &amp;quot;Methods&amp;quot;: [
        {
          &amp;quot;Method&amp;quot;: &amp;quot;HEAD&amp;quot;
        }
      ],
      &amp;quot;AbsoluteUri&amp;quot;: &amp;quot;https://azurestorageaccount.blob.core.windows.net/AzureStorageAccountContainer/NewFile.json&amp;quot;,
      &amp;quot;Disabled&amp;quot;: true
    },
...
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;In another route response, configure it to enable the above request using the &lt;code&gt;EnableRequests&lt;/code&gt; property:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-json"&gt;...
    &amp;quot;Request&amp;quot;: {
      &amp;quot;Methods&amp;quot;: [
        {
          &amp;quot;Method&amp;quot;: &amp;quot;PUT&amp;quot;
        }
      ],
      &amp;quot;AbsoluteUri&amp;quot;: &amp;quot;https://azurestorageaccount.blob.core.windows.net/AzureStorageAccountContainer/NewFile.json&amp;quot;
    },
    &amp;quot;Responses&amp;quot;: [
      {
        &amp;quot;RequestHeaders&amp;quot;: {},
        &amp;quot;ContentType&amp;quot;: &amp;quot;application/json&amp;quot;,
        &amp;quot;ContentResource&amp;quot;: &amp;quot;Commands.ArchiveCommandTests.NewFiles.NewFile.json&amp;quot;,
        &amp;quot;StatusCode&amp;quot;: 201,
        &amp;quot;EnableRequests&amp;quot;: [
          {
            &amp;quot;Method&amp;quot;: &amp;quot;HEAD&amp;quot;,
            &amp;quot;AbsoluteUri&amp;quot;: &amp;quot;https://azurestorageaccount.blob.core.windows.net/AzureStorageAccountContainer/NewFile.json&amp;quot;
          }
        ]
      }
    ],
...
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;So, the HEAD request will result in a 404 Not Found response, but the PUT request will result in a 201 Created response, and the HEAD request will be enabled.&lt;/p&gt;
&lt;h3 id="throttling"&gt;Throttling&lt;/h3&gt;
&lt;p&gt;Throttling can be configured by calling the &lt;code&gt;SimulateRetryAfter&lt;/code&gt; extension while registering your services.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-csharp"&gt;// Given
var (httpClient, timeProvider) = ServiceProviderFixture
                                .GetRequiredService&amp;lt;HttpClient, FakeTimeProvider&amp;gt;(
                                    services =&amp;gt; services.SimulateRetryAfter&amp;lt;Constants&amp;gt;(
                                        rateLimitOccurrenceCount: rateLimitOccurrenceCount,
                                        retryAfterInterval: TimeSpan.FromMinutes(1)
                                    )
                                );
TimeSpan timeAdvance = TimeSpan.FromMinutes(timeMinutesAdvance);
var responses = new List&amp;lt;HttpResponseMessage&amp;gt;();

// When
for (int i = 0; i &amp;lt;= rateLimitOccurrenceCount * 2; i++, timeProvider.Advance(timeAdvance))
{
    responses.Add(await httpClient.GetAsync(&amp;quot;https://example.com/index.txt&amp;quot;));
}

// Then
await Verify(responses);
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The above example will simulate a rate limit by advancing the time and checking the response status code. &lt;code&gt;rateLimitOccurrenceCount&lt;/code&gt; is the number of requests that will be allowed before the rate limit is applied, and &lt;code&gt;retryAfterInterval&lt;/code&gt; is for how long the rate limit will be applied once it occurs.&lt;/p&gt;
&lt;h3 id="request-headers"&gt;Request headers&lt;/h3&gt;
&lt;p&gt;Request headers can be configured to validate the request headers against the configured values, and different responses can be configured based on the request headers.&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-json"&gt;...
  {
    &amp;quot;Request&amp;quot;: {
      &amp;quot;Methods&amp;quot;: [
        {
          &amp;quot;Method&amp;quot;: &amp;quot;PUT&amp;quot;
        }
      ],
      &amp;quot;AbsoluteUri&amp;quot;: &amp;quot;https://azurestorageaccount.blob.core.windows.net/AzureStorageAccountContainer/NewFile.json&amp;quot;
    },
    &amp;quot;Responses&amp;quot;: [
      {
        &amp;quot;RequestHeaders&amp;quot;: {
          &amp;quot;Content-Type&amp;quot;: [ &amp;quot;application/json&amp;quot; ],
          &amp;quot;Content-Length&amp;quot;: [ &amp;quot;9&amp;quot; ],
          &amp;quot;x-ms-blob-type&amp;quot;: [ &amp;quot;BlockBlob&amp;quot; ],
          &amp;quot;Content-MD5&amp;quot;: [ &amp;quot;uasiD3l1Rg7NApFvCBOV1Q==&amp;quot; ]
        },
        &amp;quot;ContentType&amp;quot;: &amp;quot;application/json&amp;quot;,
        &amp;quot;ContentResource&amp;quot;: &amp;quot;Commands.ArchiveCommandTests.NewFiles.NewFile.json&amp;quot;,
        &amp;quot;ContentHeaders&amp;quot;: {},
        &amp;quot;StatusCode&amp;quot;: 201
      }
    ],
    &amp;quot;Authorization&amp;quot;: {
      &amp;quot;Authorization&amp;quot;: [
        &amp;quot;Bearer AccessToken&amp;quot;
      ]
    }
  },
...
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;In the above example, a 201 Created response is returned for PUT requests to the storage account blob container, but the request headers are validated against the configured values.&lt;/p&gt;
&lt;h3 id="md5-checksum"&gt;MD5 checksum&lt;/h3&gt;
&lt;p&gt;The Content-MD5 header is calculated and returned for all content responses.&lt;/p&gt;
&lt;h2 id="getting-started"&gt;Getting started&lt;/h2&gt;
&lt;p&gt;The package is available on &lt;a href="https://www.nuget.org/packages/Devlead.Testing.MockHttp/"&gt;NuGet&lt;/a&gt; and can be installed using the following command:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;dotnet add package Devlead.Testing.MockHttp
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The package is a source package and is supported on .NET 8 and above.&lt;/p&gt;
&lt;h3 id="example-projects"&gt;Example projects&lt;/h3&gt;
&lt;p&gt;The package is used in the following example projects:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="https://github.com/devlead/Devlead.Testing.MockHttp/tree/main/src/Devlead.Testing.MockHttp.Tests"&gt;Devlead.Testing.MockHttp.Tests&lt;/a&gt; - contains examples of many of the features.&lt;/li&gt;
&lt;li&gt;&lt;a href="https://github.com/devlead/Blobify"&gt;Blobify&lt;/a&gt; - its tests contain examples like enabling requests, request headers filtering, MD5 checksum validation, and more.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="contributing"&gt;Contributing&lt;/h2&gt;
&lt;p&gt;The project is open source, and contributions are welcome. Please feel free to submit a PR or an issue. You'll find the project on &lt;a href="https://github.com/devlead/Devlead.Testing.MockHttp"&gt;GitHub&lt;/a&gt;.&lt;/p&gt;
&lt;h2 id="conclusion"&gt;Conclusion&lt;/h2&gt;
&lt;p&gt;I hope you find this package useful. Feel free to let me know if you have any feedback or suggestions.&lt;/p&gt;
</content:encoded>
			<comments xmlns="http://purl.org/rss/1.0/modules/slash/">0</comments>
		</item>
		<item>
			<title>Preparing for .NET 9</title>
			<link>https://www.devlead.se/posts/2024/2024-09-22-preparing-for-dotnet-9</link>
			<description>Initial reflections after running .NET 9 in production</description>
			<author>devlead</author>
			<enclosure url="https://cdn.devlead.se/clipimg-vscode/2024/09/22/df979602c75a4074bff02d5d02fdb88e.jpg?sv=2023-01-03&amp;st=2024-09-22T12%253A57%253A23Z&amp;se=2035-07-29T12%253A57%253A00Z&amp;sr=b&amp;sp=r&amp;sig=V0HqKU5KQUe8JuTyKzmuxyNNyyX735PAm4M6Lx%252FaXoY%253D" length="0" type="image" />
			<guid>https://www.devlead.se/posts/2024/2024-09-22-preparing-for-dotnet-9</guid>
			<pubDate>Sun, 22 Sep 2024 00:00:00 GMT</pubDate>
			<content:encoded>&lt;p&gt;.NET 9 is just around the corner with the General Availability (GA) release scheduled for November 2024. The .NET 9 RC 1 (released September 10, 2024) already comes with a Go-Live license, meaning it’s supported by Microsoft for use in production environments.&lt;/p&gt;
&lt;p&gt;If you’re currently running .NET 6 or newer, I’ve found the migration process to .NET 9 to be fairly straightforward. Here are some key steps to guide you through the transition.&lt;/p&gt;
&lt;h3 id="update-dependencies"&gt;1. Update Dependencies&lt;/h3&gt;
&lt;p&gt;Update outdated dependencies. This is always a good practice before migrating, many incompatibility issues are often sorted this way. An excellent tool aiding with this is the &lt;a href="https://github.com/dotnet-outdated/dotnet-outdated"&gt;dotnet-outdated&lt;/a&gt; tool, run &lt;code&gt;dotnet outdated &amp;lt;solution/project folder&amp;gt;&lt;/code&gt; to check for any out of date packages and it can even update the packages for you.&lt;/p&gt;
&lt;h3 id="remove-obsolete-target-frameworks"&gt;2. Remove Obsolete Target Frameworks&lt;/h3&gt;
&lt;p&gt;If you are still targeting obsolete frameworks like &lt;code&gt;net7.0&lt;/code&gt;, it's time to clean them up. Many newer .NET 9 assemblies only target .NET 8 and above. If you need to maintain compatibility with .NET 6, you can use conditionals on your package references as a workaround during the interim, example:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-xml"&gt;    &amp;lt;PackageReference Condition=&amp;quot; '$(TargetFramework)' == 'net6.0' &amp;quot; Include=&amp;quot;Verify.Http&amp;quot; Version=&amp;quot;5.0.1&amp;quot; /&amp;gt;
    &amp;lt;PackageReference Condition=&amp;quot; '$(TargetFramework)' != 'net6.0' &amp;quot; Include=&amp;quot;Verify.Http&amp;quot; Version=&amp;quot;6.3.0&amp;quot; /&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;h3 id="update-global.json"&gt;3. Update &lt;code&gt;global.json&lt;/code&gt;&lt;/h3&gt;
&lt;p&gt;An easy way to update your &lt;code&gt;global.json&lt;/code&gt; is to simply delete it and run &lt;code&gt;dotnet new globaljson&lt;/code&gt;. This command will create a &lt;code&gt;global.json&lt;/code&gt; matching the preview SDK, which will work smoothly in your CI/CD pipeline.&lt;/p&gt;
&lt;h3 id="add-net9.0-target-framework-moniker-tfm"&gt;4. Add &lt;code&gt;net9.0&lt;/code&gt; Target Framework Moniker (TFM)&lt;/h3&gt;
&lt;p&gt;Add the &lt;code&gt;net9.0&lt;/code&gt; target framework to your project, using the &lt;code&gt;TargetFrameworks&lt;/code&gt; MSBuild property (if you're using &lt;code&gt;TargetFramework&lt;/code&gt; today and want to multitarget it will need to be relaced with &lt;code&gt;TargetFrameworks&lt;/code&gt;), example:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-xml"&gt;&amp;lt;TargetFrameworks&amp;gt;net9.0;net8.0&amp;lt;/TargetFrameworks&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;After November 12, 2024, the supported frameworks will be:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;.NET 8 (Long Term Support until November 10, 2026)&lt;/li&gt;
&lt;li&gt;.NET 9 (Standard Term Support, 18 months from release)&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id="build-and-address-issues"&gt;5. Build and Address Issues&lt;/h3&gt;
&lt;p&gt;Once you’ve set everything up, build your solution and resolve any issues that arise:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Source Issues&lt;/strong&gt;: The only code issue I encountered was an &lt;code&gt;Index&lt;/code&gt; extension method for &lt;code&gt;IEnumerable&amp;lt;T&amp;gt;&lt;/code&gt;, which is now built-in with .NET 9. In my case, the method was internal and semantically different, so I simply renamed it.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Dependency Errors/Warnings&lt;/strong&gt;: The .NET 9 SDK is more vocal about packages with security issues or deprecated dependencies. Even transitive dependencies (ones you don’t directly reference) might trigger warnings. &lt;code&gt;dotnet nuget why &amp;lt;solution/project folder&amp;gt; &amp;lt;packageid&amp;gt;&lt;/code&gt; command is helpful here, which is part of the .NET 9 SDK. You can either pin specific versions or migrate to replacement packages (especially common with Azure SDKs).&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;h3 id="my-experience-running.net-9-in-production"&gt;My Experience Running .NET 9 in Production&lt;/h3&gt;
&lt;p&gt;I’ve had code running on .NET 9 in production since the day after RC1. It’s not about being an early adopter for the sake of it, but about preparing for the future. By picking small, isolated workloads, I’m learning what challenges might come up during a larger migration. There are many things we can prepare for now so that the full migration is as smooth as possible.&lt;/p&gt;
&lt;p&gt;In fact, you can start using the new .NET 9 SDK today while still targeting older frameworks, and gaining access to new build-time features while staying on your current runtime.&lt;/p&gt;
&lt;p&gt;Overall, my experience running .NET 9 in production has been smooth sailing, with only minor issues. The one hiccup I encountered involved the .NET 9 base Docker images, which use a slightly newer Linux distribution, requiring some native binaries to be installed. But that’s exactly the kind of valuable lesson you want to learn early before migrating all your workloads. One common example is &lt;a href="https://www.nuget.org/packages/System.Text.Json"&gt;System.Text.Json&lt;/a&gt; which many packages reference old and outdated versions of, by explicitly adding a package reference to it, you're pinning the version used by your project, example:&lt;/p&gt;
&lt;pre&gt;&lt;code class="language-xml"&gt;&amp;lt;PackageReference Include=&amp;quot;System.Text.Json&amp;quot; Version=&amp;quot;8.0.4&amp;quot; /&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;&lt;a href="https://learn.microsoft.com/en-us/nuget/consume-packages/central-package-management"&gt;Central Package Management (CPM)&lt;/a&gt; is an good option to in one place for you solution handle versions of your packages including transitive.&lt;/p&gt;
&lt;h3 id="adding-net9.0-to-my-open-source-tools"&gt;Adding &lt;code&gt;net9.0&lt;/code&gt; to My Open-Source Tools&lt;/h3&gt;
&lt;p&gt;I’ve already started adding the &lt;code&gt;net9.0&lt;/code&gt; target framework to my OSS tools. Here are a few that have been shipped and published so far:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="https://www.nuget.org/packages/ARI"&gt;&lt;strong&gt;ARI&lt;/strong&gt; - Azure Resource Inventory&lt;/a&gt; .NET Tool: Inventories and documents Azure Tenant resources.&lt;/li&gt;
&lt;li&gt;&lt;a href="https://www.nuget.org/packages/Blobify"&gt;&lt;strong&gt;Blobify&lt;/strong&gt; - Blobify&lt;/a&gt; .NET Tool: Archives local files to Azure Blob Storage.&lt;/li&gt;
&lt;li&gt;&lt;a href="https://www.nuget.org/packages/BRI"&gt;&lt;strong&gt;BRI&lt;/strong&gt; - Bicep Registry Inventory&lt;/a&gt; .NET Tool: Inventories and documents Bicep modules in an Azure container registry.&lt;/li&gt;
&lt;li&gt;&lt;a href="https://www.nuget.org/packages/DPI"&gt;&lt;strong&gt;DPI&lt;/strong&gt; - Dependency Inventory&lt;/a&gt; .NET Tool: Inventories dependencies to Azure Log Analytics.&lt;/li&gt;
&lt;li&gt;&lt;a href="https://www.nuget.org/packages/UnpackDacPac"&gt;&lt;strong&gt;UnpackDacPac&lt;/strong&gt; - Unpack DAC Package&lt;/a&gt; .NET Tool: Extracts a DACPAC and generates a deployment script to a target folder, without needing a live database.&lt;/li&gt;
&lt;/ul&gt;
</content:encoded>
			<comments xmlns="http://purl.org/rss/1.0/modules/slash/">0</comments>
		</item>
	</channel>
</rss>