Microsoft has shot down the idea that WSL 3 is on the way. The articles that have been calling it WSL 3 mixed up a different feature, WSL Containers, which the company showed at Build 2026 and is now days away from shipping. The correction came straight from the team that builds Windows Subsystem for Linux.

TL; DR: WSL 3 does not exist. WSL Containers does, and it shows up in less than a week.

Microsoft has officially denied that WSL 3 exists.

Craig Loewen, the Product Manager at Microsoft responsible for the Windows Subsystem for Linux, posted on X to clear up: “As a PSA, there is no such thing as WSL 3! I’ve seen some articles talking about it, and it’s not currently a thing.” Loewen was addressing a wave of articles that misidentified a different announcement.

The confusion started from Microsoft Build 2026, where the company announced WSL Containers, a new built-in feature that lets you create, run, and interact with Linux containers directly on Windows without third-party tools like Docker Desktop. Popular publications reported this as WSL 3, partly because the abbreviation WSLc was floating around.

According to Loewen, WSL Containers is not a versioned successor to WSL 2. It is a new capability built on top of the existing WSL infrastructure. He also confirmed it will be available in just a week or so from his post on June 23, 2026.

What is WSL, and what are WSL Containers

If you are not a developer, here’s a quick primer. WSL stands for Windows Subsystem for Linux, and it is a feature built into Windows that lets you run Linux environments directly inside Windows, without the need to dual-boot into a separate OS or set up a full VM.

However, a container is a lightweight, isolated environment that packages an application along with everything it needs to run, including dependencies, libraries, and configuration. Unlike a VM, a container does not simulate an entire operating system. It shares the host OS kernel but keeps its own file system and process space.

The advantage is that containers are faster to start, easier to share, and portable across machines. WSL Containers brings this container functionality directly into WSL itself.

WSL Containers vs WSL 1 and WSL 2: what is different

WSL Containers is not a version number. It is a new layer of capability on top of WSL’s existing virtual machine infrastructure.

WSL 1 launched in August 2016 as a translation layer that converted Linux system calls into Windows ones. There wasn’t any real Linux kernel, so containers were a non-starter.

WSL 2 arrived in preview in May 2019 with a full Linux kernel running inside a lightweight managed VM, which made Docker Desktop possible.

	WSL 1 (2016)	WSL 2 (2019)	WSL Containers (2026)
Primary purpose	Run Linux command-line tools on Windows	Run a full Linux OS inside Windows	Run isolated Linux containers natively on Windows
Engine	Translation layer, no real Linux kernel	Real Linux kernel in a lightweight Hyper-V VM	Dedicated Hyper-V engine built for OCI containers
Container support	No	Yes, but needs Docker Desktop	Yes, natively via wslc.exe
Control surface	Windows Command Prompt or Linux terminal	Linux terminal inside a distro (e.g., Ubuntu)	wslc CLI from any Windows terminal

So, what problem is WSL Containers solving?

In case you didn’t know it already, developers who wanted Linux containers on Windows used Docker Desktop, which uses WSL 2 as its backend on Windows 11. Docker Desktop works well, but it comes with per-seat licensing costs for larger teams and needs a complex setup that IT administrators in enterprise environments have to manage separately.

WSL Containers removes the need for Docker

Containers can now be built, run, and deployed directly from Windows using wslc.exe, without installing Docker Desktop or any other third-party tool. The command syntax closely mirrors Docker, so developers do not face a steep relearning curve. WSL Containers also supports GPU passthrough via the Container Device Interface, which means you can run GPU-accelerated workloads like CUDA-based machine learning pipelines inside a Linux container on your Windows GPU drivers.

For enterprise IT administrators, the feature integrates into the existing Windows management infrastructure. Policy-based enablement through Group Policy or MDM controls, which containers can run and where images can be sourced from. Administrators can see running containers through standard Windows auditing tools, which is something Docker Desktop did not offer natively.

Microsoft announced WSL Containers at Build 2026

At Build 2026 on June 2, Microsoft positioned WSL Containers as a core part of its developer-optimized Windows 11 story. The official announcement, published by Executive Vice President Pavan Davuluri, described it as “a built-in way to create, run and interact with Linux containers on Windows.”

WSL Containers has two components:

1. The first is the exe CLI, which lets developers build, run, and deploy Linux containers directly from the command line, out of the box.
2. The second is the WSL Container API, which allows Windows application developers to use Linux containers programmatically as part of app logic, covering scenarios like running local AI workloads, container-based testing pipelines, and Linux-based data processing from within native Windows apps.

Build 2026 also had a few other Linux tools for Windows 11. Coreutils for Windows is now generally available, bringing over 75 familiar Linux command-line utilities like ls, grep, cp, and mv natively to Windows without WSL or a VM. Built on the open-source uutils project in Rust, these commands run directly on Windows, which means scripts that use them work without modification. The Intelligent Terminal, an experimental feature that brings context-aware AI assistance directly into the terminal, was also previewed at the same event.

Why Microsoft keeps investing in Linux on Windows

Microsoft’s investments in WSL and Linux tooling are not altruistic. The company knows that if Windows becomes the easiest place to run Linux workloads, developers have fewer reasons to switch to macOS or a native Linux setup. We wrote about this when Microsoft outlined plans to upgrade WSL with faster file access, better networking, and easier setup.

Modern software development is overwhelmingly Linux-first. Build pipelines run on Linux. Cloud infrastructure runs on Linux. AI frameworks like PyTorch, TensorFlow, llama.cpp, and Ollama are built and optimized for Linux environments. Developers working on Windows have historically had to either fight their tools or maintain a separate Linux environment alongside their Windows machine.

With WSL 2 handling Linux kernel compatibility and WSL Containers eliminating the need for Docker Desktop, Microsoft is trying to remove every reason a developer might have to reach for a different platform. Coreutils on top of that means even the command-line muscle memory that belongs to macOS and Linux now works on Windows out of the box.

It’s good news for developers. Each iteration of WSL has consistently improved the experience. I’m also a fan of how WSL Containers arrive as a routine WSL update, available to every Windows 11 user without a major OS upgrade.

The post Microsoft denies WSL 3 exists, reveals Windows 11’s WSL Containers ship next week appeared first on Windows Latest

I came across a new open-source Blazor component library called BlazorDX : https://github.com/logixrcorp/BlazorDX What caught my attention is the angle it takes. It isn’t a productivity skin over Bootstrap — it’s a secure-by-default, headless, AOT-safe component system for .NET 10. It has zero runtime reflection (grid and JSON binding come from C# source generators), it survives full IL trimming, and the heavy work — sorting, filtering, aggregating — runs in a Rust → WASM kern

Currently available as a beta in Xcode 27, Swift 6.4 introduces a range of enhancements: better C interoperability, simplified OS availability check, fine-grained warning control, async support in defer, efficient iteration for non-noncopyable types, up to 4x faster URL parsing, and improved interoperability between Swift Testing and XCTest.

By Sergio De Simone

Give GitHub Copilot its own microVM with a firewall and monitoring so that you can worry less about what your AI is doing.

Back in 2021 I wrote about my preferred .NET console stack, an opinionated alternative to dotnet new console built around Spectre.Console, dependency injection, and structured logging. That recipe worked well, and I've since used it as the foundation for several tools, including ARI, Blobify, DPI, BRI, and AZDOI. 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.

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 Devlead.Console, a versioned source NuGet package. That combination gives you the easy onboarding of a template with the maintainability of a normal package dependency.

Why templates alone fall short

A .NET template is distributed as a NuGet package and installed with dotnet new install. 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.

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.

NuGet packages solve the opposite problem nicely. Pin a version, run dotnet restore, and every consumer gets the same dependency. Source packages take that a step further for glue code: the .cs files compile into your assembly rather than hiding behind a lib/ reference, which keeps the copy/paste ergonomics while removing drift.

Source packages: best of both worlds

I touched on source packages last year when introducing Devlead.Testing.MockHttp. The same arguments apply here:

• A source package ships .cs files as compile-time content under contentFiles/cs/{tfm}/..., not as a traditional library reference.
• The code is compiled into your application assembly, so you can step through it, extend it, and reason about it like your own code.
• You extend the shared bootstrap using partial classes and partial methods in your project, without forking the package.
• Versioning, release notes, and dependency update tooling (i.e. Renovate) work the same as for any other NuGet package.

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.

Devlead.Console

Devlead.Console is the source package that contains the shared bootstrap. It keeps the same opinionated philosophy as the 2021 template:

• Dependency injection via Microsoft.Extensions
• Command-line parsing via Spectre.Console.Cli
• Logging via Microsoft.Extensions.Logging.Console
• Configuration via Microsoft.Extensions.Configuration
• Source Link via the built-in .NET SDK support (no separate package reference needed)

What changed is how you interact with it. Instead of a top-level Program.cs with all the wiring inlined, you implement a partial class Program and hook into optional partial methods:

public partial class Program
{
    static partial void ConfigureInMemory(IDictionary<string, string?> configData)
    {
        configData.Add("TestService__Version", "1.0.0.0");
    }

    static partial void AddServices(IServiceCollection services)
    {
        services
            .AddOptions<TestServiceSettings>()
            .BindConfiguration(nameof(TestService));

        services.AddSingleton<TestService>();
    }

    static partial void ConfigureApp(AppServiceConfig appServiceConfig)
    {
        appServiceConfig
            .AddCommand<TestCommand>("test")
                .WithDescription("Example test command.")
                .WithExample(["test"]);

        appServiceConfig
            .AddBranch(
                "yolo",
                c => c.AddCommand<TestCommand>("test")
                        .WithDescription("Example test command.")
                        .WithExample(["yolo", "test"])
            );

        appServiceConfig.SetApplicationName("myapp");
    }
}

The partial methods cover the three places you typically need to customize:

• ConfigureInMemory for in-memory settings during development or testing
• AddServices for dependency injection registrations
• ConfigureApp for commands, nested branches, and the application name

The resulting CLI supports commands like myapp test and myapp yolo test. For Spectre.Console patterns around settings classes, validation attributes, and command structure, the 2021 post still applies; that part of the developer experience has not changed.

If you need full control, set UseDefaultProgram to false in your project file and provide your own Program implementation. See the Devlead.Console README for details.

A typical project file references the package like any other dependency:

<ItemGroup>
  <PackageReference Include="Devlead.Console" Version="2026.6.23.767" />
</ItemGroup>

The package multi-targets net8.0, net9.0, and net10.0, so you can stay on a supported LTS or current SDK without maintaining separate bootstrap code per framework.

Devlead.Console.Template today

Devlead.Console.Template has been refactored to use Devlead.Console. It still scaffolds a working console application, but now with minimal moving parts:

dotnet new install Devlead.Console.Template
dotnet new devleadconsole -n MyConsole

You can also pick the target framework explicitly (net8.0, net9.0, or net10.0, default is net10.0):

dotnet new devleadconsole -n MyConsole --framework net8.0

The template owns your application-specific code: the project file, a sample command and settings class, and the partial Program 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.

Compared to the 2021 folder layout, you still get a Commands folder with your command, settings, and validation code. What you no longer get is a full copy of the bootstrap Program.cs that silently drifts from project to project.

Devlead.SourcePack

Packaging a source NuGet by hand means wrestling with MSBuild: contentFiles, BuildAction=Compile, per-target-framework paths, and making sure dotnet pack produces something consumers can actually restore. To simplify that, I created Devlead.SourcePack, an opinionated MSBuild package for authoring source NuGet packages using the standard SDK dotnet pack workflow.

Devlead.Console is built with Devlead.SourcePack, as is Devlead.Testing.MockHttp. If you want to author your own source packages, the Devlead.SourcePack README covers the properties and item types. This post stays focused on consuming the console stack rather than publishing new source packages.

Example projects

Devlead.Console is used in several real-world tools:

• ARI - Azure Resource Inventory, documents tenant resources as markdown
• Blobify - archives local files to Azure Blob Storage
• BRI - Bicep Registry Inventory, documents modules in an Azure container registry
• DPI - Dependency Inventory, reports NuGet dependencies to Azure Log Analytics
• AZDOI - Azure DevOps Inventory, documents an Azure DevOps organization (a community project I've had the pleasure of mentoring)
• UnpackDacPac - unpacks SQL Server DACPAC files

Each of these started from the same opinionated bootstrap and then added domain-specific commands and services on top.

Getting started

Install the template and scaffold a new project:

dotnet new install Devlead.Console.Template
dotnet new devleadconsole -n MyTool

The template includes a PackageReference to Devlead.Console. To update to a newer version:

dotnet add package Devlead.Console

From there, replace the sample command with your own, register services in AddServices, and wire up commands in ConfigureApp. The Devlead.Console README has the full API reference.

Conclusion

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.

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.

References

• Devlead.Console (NuGet)
• Devlead.Console.Template (NuGet)
• Devlead.SourcePack (NuGet)
• My preferred .NET console stack (2021)
• Introducing Devlead.Testing.MockHttp (2025)
• Spectre.Console (NuGet)
• Spectre.Console.Cli (NuGet)

Writers need to make readers care when they read a book. In this post, we share nine ways to create an unforgettable read.

What makes a novel unputdownable and unforgettable? For me, it is when the author has managed to make me care, sometimes desperately and irrationally, about the characters and the stories they have to tell. I am concerned about them and emotionally invested in their ability to move forward despite the odds.

The post Make Readers Care: 9 Ways To Create An Unforgettable Story appeared first on Writers Write.