In Vernor Vinge’s science fiction novel A Deepness in the Sky, one of the characters works as a software archaeologist, mining thousands of years of code and libraries to find the solutions to development problems. In that fictional far future, every problem has been solved at least once, often in many ways with different interfaces for different languages and processor families.
Today’s software development world isn’t quite that complex, as we only have a few decades of programming to build on. Working with a platform as old as Windows, with all its layers and history and all the possible ways to build code on it, we’re still left to look for the right SDK and API to use in our toolchains. Microsoft’s layers of abstractions try to help, but they can cause confusion and make it hard to migrate code from older frameworks to the state-of-the-art ones for today.
All those layers are one reason why it’s unfashionable to write native Windows applications, as it can be hard to find the right prerequisites to developing with your choice of tools.
Separating software development from the OS
It’s also been hard to get the right SDKs and APIs to reach all your users. Microsoft used to only ship new developer bits with new OS releases, slowing progress and making it hard to get the latest features to users. Things began to change with the shift to rolling Windows releases with Windows 10, in the guise of “Windows as a service.” The intent was not so much that Microsoft controlled your PCs, but that developers would be able to address the widest possible audience with the latest features, allowing Windows developers to give their users the same experience as on iOS or Android.
Microsoft could finally separate the developer platform from the OS, shipping new developer tools and SDKs on their own schedule and in their own separate packages. That process has led to today’s Windows App SDK, a set of cross-language tools that provide native access to key Windows functions and APIs, including devices’ built-in neural processing units. Even with this and the ability for tools like Visual Studio to automatically install dependencies, it can still be hard to put all the necessary pieces together, let alone for other development tools and environments.
With Microsoft long having had the ambition to put its tools where developers are, there’s a need to put the necessary scaffolding and toolchain in place for alternative development environments and languages, especially where it comes to supporting cross-platform development in languages like Dart or Swift.
What’s needed is a way to automate the process of bringing the necessary libraries and environments to your choice of development tools. Windows development is as much about systems programming as it is building graphical user interfaces. Low-level code in Rust or C++ needs the same level of support as a .NET C# application, even if you’re using Vim or Eclipse.
Microsoft rediscovers the command line
A key element of Microsoft’s current developer strategy is its rediscovery of the command line. Spurred on by both the complete reworking of the Windows terminal and by the release of WSL, Microsoft has delivered a whole suite of command-line tools, covering everything from Azure to .NET, as well as the GitHub Copilot agent orchestration tools. By using the same terminal tool inside its programming editor, you’re able to code, manage, and run without losing context and flow.
One of the latest CLI tools works with the Windows App SDK, simplifying the process of creating, building, and publishing Windows applications without using Visual Studio and encompassing most toolchains used for Windows development. It’s an open source project, hosted on GitHub.
Getting the tool on a development PC requires installing it via WinGet. Open a Windows Terminal and run an install command, restarting your terminal to ensure that you’re working with updated environment variables. In addition to the CLI tool, there is an experimental GUI that can quickly add debug identities to existing code.
Bootstrap Windows development with winapp
With winapp installed, you’re ready to put together a Windows development environment with a single command. Running winapp init on a development PC puts you into an interactive environment where a few simple questions take you from an application name to a ready-to-go environment, complete with Windows’ developer mode enabled (if you’re starting on a brand-new PC). If you’ve already set up developer mode and downloaded the SDKs, the tool will use what you have ready—after checking that you have the latest versions.
A handful of minutes later and the SDK will have created all the necessary files for your application, downloaded and installed the required SDKs and libraries, and set up the required manifests and configuration files—even configuring the certificates needed for code signing and application packaging. One downside is that it doesn’t create a new directory for your code. You need to do this first and then run the CLI tool from a terminal running in your new directory.
Winapp CLI commands replace key steps in the software development life cycle, with the intent of simply leaving you to write code. The first step, init, sets up the necessary scaffolding for building a Windows application. If you’re using Node.js, the next step, node create-addon, puts the templates in place to link your JavaScript code to native Windows functions.
Once you’ve written your code, it’s time to go back to winapp to set up the tools for testing and packaging. This includes the ability to generate signing certificates and build the required identity for debugging without packaging your code as MSIX bundles. Finally, it simplifies the process of packaging your code for distribution, either using your own platform or via the Microsoft Store. There’s no need to worry about whether you’re building x64 or Arm code; winapp will work for both.
As the documentation notes, this process takes out between 10 and 12 steps (depending on your choice of platform), turning them into four simple CLI commands. Your code also gains the benefits of integration with the Windows platform, using the Windows App SDK APIs.
Working with winapp and Rust
Usefully Microsoft provides documentation for working with alternate toolchains beyond the familiar .NET and C++. One key development environment being addressed by winapp is Rust development, helping you build memory-safe Windows applications and reducing the risk of security breaches in your code.
Working with Rust requires a basic Rust toolchain, which can be installed with the familiar rustup command. Once Rust is installed on your development PC, create a new Rust application and open a terminal in its directory. With winapp installed, run its init command to add the scaffolding of a Windows application around the default Rust code. However, when prompted to install the Windows App SDKs, choose the option to not install an SDK. You will need to install the Windows crate to provide access to Windows APIs.
As winapp creates the temporary identity to test your code, as well as the manifest and certificates used to package Rust code as MSIX, you can now use your choice of editor to build an application before building a release with the Rust compiler and using winapp to install the developer certificate created when you initialized the application before packaging the resulting binary.
Using winapp in Node.js and Electron
Running the CLI tool in JavaScript environments like Electron or Node.js is slightly different from directly using it in Windows’ own terminal, as you’re working inside another CLI environment. Here you need to install it using npm and run it with npx. However, once you’re inside the winapp CLI environment, you can use the same commands to manage your JavaScript Windows application’s life cycle.
You’re not limited to using the CLI on a Windows PC: You can use it as part of a GitHub runner or inside Azure DevOps, allowing it to become part of your CI/CD pipeline. Microsoft provides actions for both tools to quickly install it in runners and agents, simplifying automated builds and tests.
Tools such as the Windows App SDK’s CLI are increasingly important. We’re now spending most of our time inside our development environments, and having key utilities a few keystrokes away inside a terminal gives us the necessary shortcuts to be more productive. Having it in your development toolchain should save time and let you concentrate on code instead of worrying about all the steps to package and sign your applications.
Go to Source
Author:
