Introduction

The Windows Package Manager, commonly known as winget, has rapidly evolved from a promising utility for power users into an indispensable tool for modern Windows administration, configuration, and DevOps workflows. Its ability to script and automate application lifecycle management has made it a core component of the Windows ecosystem. However, beneath the surface of its command-line interface, a profound architectural transformation is underway within the preview channels. This is not a minor update but a fundamental realignment of winget with Microsoft’s next-generation application platform technologies, bringing with it a new set of dependencies and deployment nuances.

While this strategic shift promises long-term benefits in performance, servicing, and feature velocity, it introduces significant new challenges for deployment, particularly in automated, enterprise-scale scenarios. The legacy methods of installation are no longer sufficient to handle the intricacies of this new foundation. This analysis serves a dual purpose: first, to provide an expert-level deconstruction of winget’s new dependency architecture, clarifying the changes and their implications. Second, it introduces Install-WinGetV2.ps1, a completely rewritten PowerShell script engineered from the ground up to master these new complexities and provide a robust, reliable, and enterprise-grade deployment solution for the modern era of winget.

Part 1: The New Foundation – Deconstructing Winget’s Modern Dependency Model

To understand the need for a new installation tool, one must first appreciate the fundamental changes occurring at the architectural level of the Windows Package Manager. This is a move from a simple, self-contained dependency model to a sophisticated, shared runtime framework that has profound implications for how the tool is installed, serviced, and managed.

A Strategic Leap to the Windows App SDK

The most significant change in recent winget preview versions is the migration away from the older WinUI 2 framework to the modern Windows App SDK. This is a deliberate and strategic decision by Microsoft. By rebuilding a critical, system-level command-line utility on its premier development platform, Microsoft is “dogfooding” the Windows App SDK, validating its stability and suitability for all classes of applications, not just those with a graphical user interface.

This transition is far more than a cosmetic refresh for the App Installer package that delivers winget. It is about future-proofing the package manager and aligning it with the platform where Microsoft is concentrating on its future innovation. Rebuilding the SDK provides winget with several key advantages. It gains access to a unified API surface that works consistently across a wide range of Windows versions, down to Windows 10 version 1809. This decoupling of APIs from the operating system allows winget to leverage the latest platform features without requiring a specific OS update. Furthermore, the Windows App SDK has a rapid and independent release cadence, enabling a faster delivery of new features to winget than would be possible if it were tied to the slower Windows OS release schedule.

This migration serves as a decisive vote of confidence from Microsoft in its own platform. When a foundational tool used daily by developers, IT professionals, and system administrators runs on the Windows App SDK, it signals to the entire developer community that this is the stable, reliable, and correct path for all future Windows desktop development. This implies a deep, long-term commitment to evolving winget in lockstep with the cutting edge of the Windows platform itself.

From Simple Libraries to a Serviced Runtime: A Comparative Analysis

The architectural shift is most evident when comparing the legacy dependency model to the new one. Previously, installing winget required the primary Microsoft.DesktopAppInstaller package along with two discrete libraries: the Visual C++ Runtimes (Microsoft.VCLibs) and a specific version of the WinUI 2 library (Microsoft.UI.Xaml). This model was straightforward, but it placed the burden of managing dependency versions on the administrator or the deployment script.

The new model replaces the single UI library with a comprehensive, multi-package framework known as the “Windows App SDK Runtime”. This moves winget from a model of bundled dependencies to a shared framework model. Instead of different applications on a system potentially carrying slightly different versions of UI libraries, they all share a single, centrally serviced runtime. When Microsoft issues a security or reliability update for the SDK runtime, it is delivered as a single update that benefits all dependent applications, including winget, simultaneously improving system efficiency and reducing the potential for versioning conflicts.

The following table provides a clear visual contrast of this evolution, illustrating the increased complexity that necessitates a more intelligent installation solution.

Legacy Dependency Model (Pre-WinUI 3) Windows App SDK Dependency Model (winget v1.12+ Preview)
Microsoft.DesktopAppInstaller_*.msixbundle Microsoft.DesktopAppInstaller_*.msixbundle
Microsoft.VCLibs.x64.14.00.Desktop.appx Microsoft.VCLibs.x64.14.00.Desktop.appx
Microsoft.UI.Xaml.2.8.x64.appx (example version) Microsoft.WindowsAppRuntime.1.7_*.msix (Framework)
Microsoft.WindowsAppSDK.Main.1.7_*.msix (Main)
Microsoft.WindowsAppSDK.Singleton_*.msix (Singleton)
Microsoft.WindowsAppSDK.DDLM.x64_*.msix (DDLM)

Anatomy of the Windows App SDK Runtime

The Windows App SDK Runtime is not a monolithic entity but a modular suite of packages, each with a distinct and critical function. This design provides robustness and is the modern architectural solution to historical Windows development problems, such as “DLL Hell,” where conflicting shared libraries could break applications. By installing winget with these dependencies, an administrator is not just installing a package manager; they are installing a piece of modern Windows infrastructure that makes the entire system more stable and manageable.

The runtime consists of four key components:

  • The Framework Package: This is the “engine and chassis” of the runtime. It is the largest component and contains the actual APIs, the complete WinUI 3 framework, and other core technologies that applications like winget call upon to function.
  • The Main Package: This component acts as the “servicing and logistics department.” It contains background services responsible for managing the runtime itself, handling dynamic dependencies, and enabling automatic updates of the Framework package.
  • The Singleton Package: Functioning as the “central dispatch,” this package manages system-wide resources that must exist as a single instance, such as push notification services. Its presence is required for the holistic operation of the runtime.
  • The Dynamic-Link Library Module (DDLM): This small, architecture-specific package is the “address book.” Its sole purpose is to locate the correct version of the Framework package installed on the system and direct the application to it.

The Official Bootstrapper: Understanding Repair-WinGetPackageManager

In response to the need for a scriptable, non-Microsoft Store installation method, Microsoft provides the Repair-WinGetPackageManager cmdlet within the Microsoft.WinGet.Client PowerShell module. This tool is a powerful orchestrator whose function extends far beyond simple repair. It is the official bootstrapping engine for winget, capable of performing clean installations, upgrades (including to pre-release versions), and is the recommended method for setting up winget in pristine environments, such as Windows Sandbox. The existence of this cmdlet is a direct acknowledgment from Microsoft that enterprise and automated deployment scenarios are a primary use case for winget.

However, a critical gap exists. While Repair-WinGetPackageManager is the official solution for non-Store deployments, it has documented issues when executed in the elevated “system context” (NT AUTHORITY\SYSTEM). This is the exact context used by leading enterprise management tools like Microsoft Intune and System Center Configuration Manager (SCCM). This creates a paradox: the official tool designed to solve the enterprise deployment problem fails in the most common enterprise deployment scenarios. This functional gap means that a more robust solution is not just a convenience but a necessity for achieving true, large-scale enterprise automation with winget.

Part 2: The Definitive Solution – A Deep Dive into Install-WinGetV2.ps1

The architectural evolution of winget and the limitations of the official tooling create a clear need for a purpose-built solution. Install-WinGetV2.ps1 is that solution, explicitly engineered to address the challenges of the new dependency model and provide a reliable path for all deployment scenarios.

GitHub – kkaminsk/InstallWinget-V2: Love it or hate it I’m starting from scratch.

Why a New Script? The “V2” Rewrite

This script is a complete rewrite of the previous Install-WinGet.ps1, which was designed for the simpler, legacy dependency model. The “V2” designation is intentional, signaling that this is a next-generation tool for a next-generation architecture. The complexity of the multi-package Windows App SDK Runtime, combined with the subtle but critical failure points of the official cmdlet in enterprise contexts, demanded a complete redesign. A simple patch to the old script would have been insufficient. The V2 rewrite represents a strategic response to a fundamental platform shift, embodying a deep understanding of the new architecture’s requirements and providing a solution that is more intelligent, resilient, and aware of real-world administrative challenges.

Core Features and Capabilities

Install-WinGetV2.ps1 is built on a foundation of features designed to overcome the challenges outlined in the new winget ecosystem.

  • Non-Interactive Mode: With much fighting, a method has been found to use this script silently. It was frustrating to have the script work so well and then be held up by the installation of NuGet.
  • Intelligent, Resilient Dependency Handling: The script goes beyond being a simple wrapper for Repair-WinGetPackageManager. It contains robust logic to orchestrate the download and side-loading of the entire suite of Windows App SDK packages. It ensures the correct versions are fetched and installed in the proper sequence, providing a more durable and transparent installation process than the official cmdlet alone.
  • Enterprise-Ready by Design (System Context Aware): This is the script’s most critical feature. It is engineered to solve the system context problem where the official tool fails. By incorporating logic that utilizes the Add-AppxProvisionedPackage cmdlet, the script can correctly “stage” the WinGet application and all its dependencies for all users on a machine. This makes it reliable for deployments via Intune, SCCM, and other management systems that execute installations as the system user.
  • Granular Version and Channel Control: The script provides clear parameters to target the desired WinGet version precisely. Administrators can choose to install the latest stable release or opt-in to the preview channel by using a dedicated switch. This allows for consistent and predictable deployments across different environments, from development and testing (preview) to production (stable).
  • Transparent and Verbose Logging: Building upon the logging capabilities of its predecessor, the V2 script features enhanced, verbose logging. The log file provides a clear, step-by-step transcript of the entire process, including the download and installation of each dependency package (Framework, Main, Singleton, and DDLM). This level of detail is crucial for auditing and troubleshooting complex, multi-stage automated deployments in enterprise environments.

Part 3: Install-WinGetV2.ps1 in Action – Usage and Scenarios

The actual value of Install-WinGetV2.ps1 is demonstrated through its practical application in standard and advanced administrative scenarios.

Prerequisites and Basic Usage

The script is designed to run on any system that meets the minimum requirements for winget itself: PowerShell 5.1 or higher on Windows 10 version 1809 (build 17763) or later. For the most common use case—installing the latest stable version of winget on a workstation, the process is straightforward. From an elevated PowerShell prompt, execute the following commands:

# Example: Basic Installation of Stable WinGet
.\Install-WinGetV2.ps1 -LogPath “C:\Temp\Winget-install.log”

# Example: Preview Installation of WinGet
.\Install-WinGetV2.ps1 -IncludePrerelease -LogPath “C:\Temp\Winget-install.log”

Parameter Deep Dive

The script’s flexibility is exposed through a set of powerful parameters designed to handle various administrative needs.

  • -InstallPrerelease: A switch parameter that instructs the script to download and install the latest preview version of WinGet. This will automatically handle the installation of the required Windows App SDK runtime dependencies.
  • -Force: A switch parameter that compels the script to perform a re-installation even if it detects an existing version of WinGet. This is invaluable for repairing a corrupted installation or forcing an environment back to a known-good state.
  • -LogPath: A string parameter that allows the user to specify a custom file path for the verbose log file. This is essential for enterprise environments where logs must be collected in a centralized location for auditing and analysis.
  • -AllUsers: A switch parameter that invokes the enterprise-grade installation logic using Add-AppxProvisionedPackage. This is the key to successfully deploying WinGet via Intune or SCCM, as it correctly installs the application in the system context for all current and future users of the machine.

Advanced Deployment Scenarios

The script truly excels in complex, automated scenarios where reliability is paramount.

Scenario 1: Basic Installation (Windows Server 2022)

First, open the PowerShell prompt as an administrator and configure the PowerShell security.

# Inside a Windows Administrative PowerShell prompt
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process -Force

A screen shot of a computer AI-generated content may be incorrect.

Next, download the PowerShell script.

Invoke-WebRequest -Uri “https://raw.githubusercontent.com/kkaminsk/InstallWinget-V2/refs/heads/main/Install-WingetV2.ps1” -OutFile “Install-WinGetV2.ps1”

A screen shot of a computer code AI-generated content may be incorrect.

Finally, run the script.

PowerShell.exe -NonInteractive .\Install-WinGetV2.ps1 A computer screen with many colorful text AI-generated content may be incorrect.

Secenario 2: Bootstrapping a Windows Sandbox

Using Winget in a Sandbox environment is an easy way to install software for limited testing or use. Windows Sandbox is in the middle ground between testing on a whole virtual machine and a local PC. It still relies on virtualization but limits its capabilities so as not to be an entire virtual machine.

The official method for installing WinGet in a pristine Windows Sandbox environment involves several manual PowerShell commands. Install-WinGetV2.ps1 streamlines this process into a single, reliable action, making it trivial to spin up sandboxed testing environments.

Installing Windows Sandbox

Make sure virtualization is enabled in the CPU and the edition of Windows is Pro, Enterprise or Education.

From an administrative PowerShell prompt, run the following command to install the Windows Sandbox.

Enable-WindowsOptionalFeature -Online -FeatureName ”Containers-DisposableClientVM” -All

The install will take a moment.

A screen shot of a computer AI-generated content may be incorrect.

To use the feature, a machine restart is required. Press Y then enter to reboot the machine.

A screen shot of a computer AI-generated content may be incorrect.

You can then search and launch Windows Sanbox via the Start Menu.

A screenshot of a computer AI-generated content may be incorrect.

Windows Sandbox will then appear.

A computer screen shot of a blue swirly object AI-generated content may be incorrect.

Winget installation for Sandboxes

First, set the PowerShell execution policy.

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process -Force

A black screen with white text AI-generated content may be incorrect.

Now, download the script.

Invoke-WebRequest -Uri “https://raw.githubusercontent.com/kkaminsk/InstallWinget-V2/refs/heads/main/Install-WingetV2.ps1” -OutFile “Install-WinGetV2.ps1”

Then run the script to install winget.

PowerShell.exe -NonInteractive .\Install-WinGetV2.ps1

A screen shot of a computer program AI-generated content may be incorrect.

Scenario 3: Integrating with WinGet Configuration

The winget configure command allows administrators to use YAML files to declare and enforce a machine’s desired state, a powerful feature for modern configuration management. Install-WinGetV2.ps1 serves as the perfect foundational step for these workflows. An automation script can first call Install-WinGetV2.ps1 to guarantee the reliable installation of the winget engine itself. Immediately following a successful installation, the script can proceed to call winget configure –file .\config.yaml, confident that the underlying tool is present and correctly installed. This positions the script as a critical enabler for adopting desired state configuration practices on Windows.

For example, we can install a series of applications by using the following process. First let’s install winget in a sandbox from an administrative PowerShell prompt.

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process -Force

Invoke-WebRequest -Uri “https://raw.githubusercontent.com/kkaminsk/InstallWinget-V2/refs/heads/main/Install-WingetV2.ps1” -OutFile “Install-WinGetV2.ps1”

Invoke-WebRequest -Uri “https://raw.githubusercontent.com/kkaminsk/InstallWinget-V2/refs/heads/main/YAMLExample/config.yaml” -OutFile “config.yaml”

PowerShell.exe -NonInteractive .\Install-WinGetV2.ps1

A screen shot of a computer program AI-generated content may be incorrect.

Next use winget to install the packages defined in the config.yaml.

winget configure -f .\config.yaml –accept-configuration-agreements

A screenshot of a computer program AI-generated content may be incorrect.

Conclusion and Next Steps

The Windows Package Manager is undergoing significant and necessary architectural evolution, aligning itself with the future of the Windows platform by adopting the Windows App SDK. While this transition brings long-term benefits, it has also introduced a deployment and automation gap, particularly for enterprise customers who rely on scripting to manage Windows application deployment.

Install-WinGetV2.ps1 has been engineered as the tool to bridge that gap. It provides the reliability, enterprise-readiness, and transparent logging required for modern system administration. By handling the new complex dependency chain and solving the critical system context installation problem, the script surpasses the official tooling for automated deployments. It enables robust, scalable management of winget across a variety of situations in the Enterprise.

To leverage this powerful solution, administrators and developers are encouraged to visit the official GitHub repository at https://github.com/kkaminsk/InstallWinget-V2. There, you can download the script, review the code, and engage with the project by reporting issues or contributing enhancements.