• WSL containers CLI: wslc.exe to directly build, run and deploy Linux containers on Windows, or use its built-in alias container.exe to run the same familiar container commands
• WSL containers API: Access functions to run Linux containers programmatically in your native Windows apps – unlocking scenarios like running local AI workloads or using cloud-based containerized applications locally.

New commands and capabilities

• wslc container restart — restart a running container
• wslc container cp — copy files in and out via tar archive
• wslc system info — see the state of your container environment at a glance
• wslc network connect and wslc network disconnect — attach and detach containers from networks
• wslc network create now supports arbitrary network driver options
• wslc events – Streams real time container activity
• Container health checks are now supported
• --stop-timeout on wslc create and wslc run, including -1 for an infinite timeout
• --mount support during wslc create and wslc run
• A configurable storage path for the default wslc session, so you can put your container storage on the drive you want.

Enterprise manageability for WSL containers

• Allow WSL containers access - Control access to the entire WSL containers feature.
• WSL containers registry allow list - For WSL containers enterprise adoption, organizations need stronger controls over the container images that can be introduced into their environment. With container registry allow lists, administrators can define approved registries and help ensure developers only pull container images from that list, that meet organizational security and compliance requirements.

Partner and community integrations

• VS Code dev container support: Use wslc as your default driver for creating and interacting with VS Code dev containers
• Aspire: Aspire can use WSL Containers as first-class container runtime
• VS Code container extension: A popular extension to manage your containers in VS Code, now supports wslc.
• Lazywslc: A TUI dashboard to manage your WSL containers
• WSL Container Desktop: WinUI 3 desktop app for managing WSL containers, Kubernetes (k3s) and container registries.
• WSLc remote: A short wrapper script to run wslc from within WSL distros

What's next for WSL

Adding wslc compose

WSL fundamental improvements

Building the future of Linux on Windows, together

A predictable and low-disruption update

How to get it

Information for commercial and education customers

Staying protected and productive

Overheard in a recent conversation:

Enterprise Administrator: “The ***redacted*** application is awesome, but it really should be an MSIX package.”
Microsoft Developer: “Ummm, it already is.”

That sparked another question: How can you tell if an application is packaged or unpackaged?

Turns out there’s a few simple ways to check.

The key difference between packaged and unpackaged processes is whether they have package identity. Task Manager provides a convenient way to quickly see this:

1. Run taskmgr.exe
2. On the left, select Details
3. Right-click a column heading and select Select columns
4. Select Package name
5. Select OK

The list of processes now shows Package name:

• If the process is unpackaged, this field is blank.
• If the process is packaged, this field shows the package’s Display Name¹

For example:

In this example, AzVpnAppx.exe is a packaged process with the display name Azure VPN Client, whereas audiodg.exe has no Package name, so it’s unpackaged.

We also see AzVpnSysTrayApp.exe is a packaged process with the same display name as AzVpnAppx.exe. Display names are localized strings meant for human consumption, and thus aren’t guaranteed to be unique. They can be whatever the developer chooses to show.

¹ If Task Manager can’t resolve the package’s localized display name, the Package name column may instead show an ms-resource: value based on the DisplayName declared in AppxManifest.xml. Windows uses this resource reference to find the appropriate localized string rather than displaying the resource reference to the user.

The post Is it MSIX? Part 1: How to Tell if a Process Is Packaged appeared first on Inside MSIX.

Shiny.AppFunctions is a new package that lets the platform assistants call into your .NET app. You declare a function once, in C#, and it becomes:

• an App Intent on iOS 16+, available to Siri, Spotlight, the Shortcuts app and Apple Intelligence;
• an Android AppFunction on Android 16+, available to Gemini and other agents the system allows.

It’s coming in Shiny 5.8.

Apple and Google both want assistants to act inside apps, and both have shipped a way for apps to say what they can do. The two share nothing:

For a .NET developer, that’s two native languages, two build pipelines and two ways to describe the same “create an order” operation. They drift apart the moment one of them changes.

With Shiny.AppFunctions, the operation is a C# record and the handler is a C# class. The id, the parameters, their descriptions and the business logic are shared, and each platform gets its own native form generated from them.

builder
    .UseMauiApp<App>()
    .UseShiny();

builder.Services.AddAppFunctions();   // source-generated

That’s all the registration there is. AddAppFunctions() is written by the package’s source generator, and it registers every handler, entity query and delegate in your app.

A function is a record marked [AppFunction] that implements IAppFunction<TResult>. Its properties are the parameters, and one handler runs it:

using Shiny.AppFunctions;

public enum Priority { Low, Normal, Urgent }

public record OrderResult(string Number, int Quantity, double Total);

[AppFunction("create_order", Description = "Creates an order for a customer")]
[AppShortcut("Create an order in ${applicationName}", ShortTitle = "New Order", SystemImage = "cart.badge.plus")]
public record CreateOrder(
    [property: AppParameter(Title = "Customer", Description = "Who the order is for")] Customer Customer,
    int Quantity,
    Priority Priority,
    string? Note
) : IAppFunction<OrderResult>;

public class CreateOrderHandler(OrderStore store) : IAppFunctionHandler<CreateOrder, OrderResult>
{
    public Task<OrderResult> Handle(CreateOrder request, AppFunctionContext context, CancellationToken cancellationToken)
    {
        if (request.Quantity is < 1 or > 1000)
            throw new AppFunctionException(AppFunctionErrorCode.InvalidArgument, "Quantity must be between 1 and 1000");

        var order = store.Create(request.Customer, request.Quantity, request.Priority, request.Note);
        context.Say($"Order {order.Number} is in.");
        return Task.FromResult(new OrderResult(order.Number, order.Quantity, order.Total));
    }
}

That one declaration is everything both assistants need:

• The id (create_order) is the same on both platforms. It’s the name a saved Shortcut and an agent refer to.
• The description is what Siri, Apple Intelligence and Gemini use to decide when to call the function.
• The parameters come from the record. Constructor parameters are required unless nullable, so Note is optional everywhere. Priority becomes an AppEnum on iOS and an enumerated value in the Android schema.
• context.Say(...) is what Siri shows or speaks. On Android it comes back with the result, in a response extra.
• AppFunctionException fails the call with a code that maps to each platform’s own error. The message is shown or spoken to the user, so it’s written for them.

The handler is resolved from a new DI scope for every call, so it takes your services like anything else in the app.

An entity is an app object that can be a parameter: a customer, a playlist, a project. Mark a record with [AppEntity] and give it a query:

[AppEntity("customer", Title = "Customer")]
public record Customer(string Id, string Name, string City);

public class CustomerQuery(ICustomers customers) : IAppEntityQuery<Customer>
{
    public Task<IReadOnlyList<Customer>> GetByIds(IReadOnlyList<string> ids, CancellationToken ct) => customers.ByIds(ids, ct);
    public Task<IReadOnlyList<Customer>> Search(string text, CancellationToken ct) => customers.Search(text, ct);
    public Task<IReadOnlyList<Customer>> Suggested(CancellationToken ct) => customers.Recent(ct);
}

This is where the two platforms differ most, and where one declaration pays off:

• On iOS it’s a real App Entity. Siri and Shortcuts show a picker: Suggested before the user types, Search while they type, and GetByIds to load the one they chose.
• On Android there are no entity queries, so agents send an id. Shiny generates a companion search_customer function from the same query, returning [{ id, title }], so Gemini can find the customer first and then call create_order with its id.

Either way, the id is resolved back to a Customer through your query before the handler runs. An id the query doesn’t know fails the call with NotFound.

[AppShortcut] turns a function into an App Shortcut. It’s available to Siri and Spotlight as soon as the app is installed, and the user doesn’t have to set anything up:

[AppFunction("count_open_orders", Title = "Open Orders", Description = "Counts the orders that have not shipped")]
[AppShortcut("How many orders are open in ${applicationName}", SystemImage = "shippingbox")]
[AppShortcut("Open orders in ${applicationName}")]
public record CountOpenOrders : IAppFunction<int>;

Every phrase must include ${applicationName}, and iOS allows up to 10 App Shortcuts per app. Both are checked at compile time. The attribute is ignored on Android, where Gemini works from the function’s description instead.

An assistant can call your app when the user isn’t signed in, or when a feature is switched off. An IAppFunctionDelegate sees every call before and after the handler:

public class SignInDelegate(IAuth auth) : IAppFunctionDelegate
{
    public Task<AppFunctionGate> OnInvoking(AppFunctionContext context, CancellationToken ct)
        => Task.FromResult(context.FunctionId == "cancel_order" && !auth.IsSignedIn
            ? AppFunctionGate.OpenApp("Sign in to cancel orders.")
            : AppFunctionGate.Allow);
}

AppFunctionGate.Deny(message) refuses the call. AppFunctionGate.OpenApp(message) asks the user to continue in the app on iOS, and then runs the call again in the foreground; on Android it refuses with the message. OnInvoked receives the result or the exception, which makes it the place for logging and telemetry. context.Platform tells you whether Siri or Gemini made the call. Delegates are found and registered by the generator.

The source generator and the build step ship inside the package:

• Generated C#: AddAppFunctions(), the function descriptors, and reflection-free argument binding, dispatch and result writing. It’s trim- and AOT-safe.
• iOS: the Swift App Intents, App Entities, entity queries and AppShortcutsProvider, compiled with swiftc into the app. Apple’s App Intents metadata and Siri phrase processors run before signing.
• Android: the AppFunctions schema, added to the app as assets. The AppFunctionService arrives through the manifest merger.

There’s no Swift, no Kotlin, no Info.plist entry, no entitlement and no AndroidManifest entry to write. The iOS build needs Xcode, since it runs swiftc and Apple’s processors.

The generator also checks your declarations: a missing handler, an unsupported parameter type, a duplicate id or a Siri phrase without ${applicationName} is a build error (SHAF001–SHAF013), not a failure at runtime.

AppFunctionDispatcher runs the same pipeline Siri and Gemini use — new scope, binding, delegates, handler, JSON result — from inside the app:

var outcome = await dispatcher.Execute(
    new AppFunctionInvocation("create_order"),
    """{"customer":"acme","quantity":2,"priority":"Normal"}""",
    CancellationToken.None
);

Every function in dispatcher.Registry.Functions exposes GetParametersJsonSchema(). That’s enough to hand your app’s functions to an in-app AI chat as tools, or to an MCP server, without declaring them a third time.

On an Android 16+ emulator, the shell can list and call your functions, the same way an agent does:

adb shell cmd app_function list-app-functions --package com.mycompany.myapp

adb shell "cmd app_function execute-app-function --package com.mycompany.myapp \
  --function create_order --parameters '{\"customer\":\"acme\",\"quantity\":2,\"priority\":\"Normal\"}'"

On iOS, install the app and search for a shortcut’s title in Spotlight (“New Order”), or find the app’s actions in the Shortcuts app.

• Platforms: iOS 16+ and Android 16 (API 36)+. Below Android 16 the package does nothing. There’s no Mac Catalyst, macOS or Windows bridge; net10.0 has the contracts and the dispatcher.
• Declare functions in the app project. The generator scans only the app, not class libraries. The services, enums and result types they use can live anywhere.
• Calls can be cold starts with no UI. Persist what a handler changes, and don’t touch pages from it.
• Parameters are string, int, long, double, bool, DateTimeOffset, enums and entities. Results can also be records and lists.
• Titles and descriptions are not localized yet.

• App Functions documentation
• Delegates and in-process calls
• Platform, build and testing
• Sample: a small orders app with create, count, look up and cancel functions, a customer entity, two App Shortcuts and a sign-in delegate. Its App Functions page shows every call Siri or Gemini made.

Game data rarely looks the same for very long. A player document might start out with just a username and a score, and a few sprints later, it needs an inventory, a set of unlocked achievements, and a friends list, each shaped differently from the last. MongoDB's document model is a natural fit for that kind of growth, since a new field is just a new field, with no migration to write and no join to add. A match record can embed both players directly, scores and all, so reading back a finished match is a single document lookup rather than a query spread across multiple tables. Atomic operators like $inc and $max also mean stats and high scores can be updated safely by many concurrent players at once, without the application code having to coordinate a read-then-write itself.

In this tutorial, we're going to build a simple multiplayer game. Each player controls a white square on a canvas, and for thirty seconds, yellow coin squares spawn at random positions. Whoever collects the most coins when the timer runs out wins. Movement, coin spawning, and scoring all happen over WebSockets through Socket.io, with the server acting as the single source of truth for everything that happens during a match. MongoDB sits underneath that, storing player accounts, match records, and the leaderboard.

We'll use TypeScript, Zod, Socket.io, and Express on the backend, and Phaser, TypeScript, and Socket.io on the frontend. The MongoDB Node.js driver is used directly, without an ODM like Mongoose, so every query in this tutorial is plain driver code. If you'd rather skip ahead or just want to run the finished project, the full source is available on GitHub.

The post Multiplayer Game Development with TypeScript, Phaser, Socket.io, and MongoDB appeared first on DEV.