Specification: Parallel Installation by denelon · Pull Request #6295 · microsoft/winget-cli

denelon · 2026-06-17T18:36:00Z

📖 Description

Specification for parallel package installation in multi-package operations. When more than one package is being installed or upgraded — including winget upgrade --all, winget import, and winget configure flows — packages are scheduled across parallel and serialized execution lanes based on installer type safety:

MSIX: concurrent (up to 6, platform limit)
Inno/NSIS/Portable/ZIP: concurrent (safe, no shared state)
MSI/Burn/EXE: serialized (respects _MSIExecute mutex)

Includes download-ahead scheduling, retry on mutex contention, dependency-aware ordering, and SafeForParallel manifest field for opt-in EXE parallelism.

Authored with GitHub Copilot assistance.

🔗 References

Related Issues:

🔍 Validation

Spec document — no code changes to validate.

✅ Checklist

Signed the Contributor License Agreement
Linked to an issue
Updated Release Notes (if applicable)
Updated documentation (if applicable)
Updated Copilot instructions (if build, architecture, or conventions changed)

📋 Issue Type

Bug fix
Feature
Task

Microsoft Reviewers: Open in CodeFlow

Specification for parallel package installation across multi-package operations (upgrade --all, import, configure). MSIX concurrent, MSI serialized, download-ahead scheduling with retry logic. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Trenly · 2026-06-17T18:42:35Z

+- **Distributed installation** — For fleet management, schedule package downloads during off-peak hours and install during maintenance windows
+- **Resume on reboot** — If a reboot interrupts a batch, resume remaining packages after restart
+
+## Resources


This should also consider

Decouple Download and Install Steps #4105

Trenly · 2026-06-17T18:44:14Z

+```
+
+> [!IMPORTANT]
+> Downloads and MSIX installations can overlap — an MSIX install can begin as soon as its download completes, even while other downloads are still in progress. The serialized queue also starts as soon as its first package finishes downloading. The phases are logical, not strictly sequential.


Is this limited just to MSIX install overlap? Couldn't downloads overlap with any install?

Trenly · 2026-06-17T18:45:03Z

+  - Architecture: x64
+    InstallerType: exe
+    InstallerUrl: https://example.com/app-setup.exe
+    SafeForParallel: true  # Declares this installer is safe for concurrent execution


How is this validated on package submission? Just because a user declares it does not mean it is true - especially in the case where two EXEs could be trying to write to the same resources if they are not MSI-backed

Trenly · 2026-06-17T18:47:49Z

+
+| Setting | Default | Min | Max | Description |
+|---------|---------|-----|-----|-------------|
+| `maxConcurrentDownloads` | 5 | 1 | 20 | Parallel downloads |


Any setting for no limit? 0?

I don't think I will approve code that doesn't have a limit, so the setting might as well have one.

Trenly · 2026-06-17T18:48:38Z

+
+### Schema Version
+
+Requires manifest schema version 1.29.0 for the `SafeForParallel` field. Parallel installation itself does not require schema changes — it works with existing manifests using installer type classification.


Remove version specfic information

Trenly · 2026-06-17T18:48:51Z

+### Validation Pipeline Impact
+
+- `SafeForParallel` is a new optional boolean field on installer entries
+- Validation: if `InstallerType` is `msi` or `burn` and `SafeForParallel: true`, reject as invalid (these types are inherently unsafe for parallel execution)


Trenly · 2026-06-17T18:49:20Z

+### Validation Pipeline Impact
+
+- `SafeForParallel` is a new optional boolean field on installer entries
+- Validation: if `InstallerType` is `msi` or `burn` and `SafeForParallel: true`, reject as invalid (these types are inherently unsafe for parallel execution)


Needs to consider the effective installer type, not declared installer type to appropriately handle packages in Zip files

Trenly · 2026-06-17T18:50:18Z

+- Progress display uses text status markers (✓ ● ○ ✗) alongside descriptions for screen readers
+- Non-VT fallback ensures full accessibility without virtual terminal sequences
+- JSON output mode (`--output json`) provides machine-readable progress events
+- Summary line always includes text count (not just visual indicators)


Need to ensure redirected output is captured properly with no contamination

Trenly · 2026-06-17T18:52:11Z

+
+## Abstract
+
+Enable parallel package installation in WinGet when multiple packages are being installed or upgraded simultaneously. This applies to `winget install` with multiple packages, `winget upgrade --all`, `winget import`, and `winget configure` flows. Packages are classified by installer type safety: MSIX packages can be installed concurrently (up to a configurable limit), while MSI/EXE packages that rely on the Windows Installer mutex are serialized. A dependency-aware scheduler maximizes throughput while respecting installer constraints.


Does this also affect winget download with multiple packages being able to be downloaded in parallel?

Win32 installers (including Inno, NSIS, portable) offer no platform-level parallel guarantees. Only MSIX has concurrent deployment support from the platform. All non-MSIX installers now use the serialized queue. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

mominshaikhdev · 2026-06-18T15:01:02Z

Not only install or upgrade but also It needs uninstall too. Uninstalling multiple programs in a serial or concurrent where posssible.

Trenly · 2026-06-18T15:10:11Z

Not only install or upgrade but also It needs uninstall too. Uninstalling multiple programs in a serial or concurrent where posssible.

I feel like this should be a separate feature request

JohnMcPMS · 2026-06-23T18:51:52Z

+
+Even in the serialized queue, Windows Update or another system process may hold the `_MSIExecute` mutex when the next MSI package is ready to install:
+
+1. Before starting an MSI installation, check the mutex state


I would prefer that we just detect the error and handle appropriately.

JohnMcPMS · 2026-06-23T18:56:42Z

+
+#### `winget configure`
+
+Configuration files with multiple `Microsoft.WinGet/Package` resources are parallelized by the WinGet configuration engine:


I don't think that this is the right approach. If we feel like this is relevant, we should have a new resource (or modify the existing) that takes an array of package specifications and it can take care of things. Special casing resources in the execution engine is not a good idea long term.

JohnMcPMS · 2026-06-23T19:01:47Z

+
+### Progress Reporting
+
+Multi-package progress uses a consolidated display:


There are a few options shown as examples throughout this spec. It would be good to have a singular style that covers all of the cases and phases.

JohnMcPMS · 2026-06-23T19:04:08Z

+
+| Setting | Default | Min | Max | Description |
+|---------|---------|-----|-----|-------------|
+| `maxConcurrentDownloads` | 5 | 1 | 20 | Parallel downloads |


I don't think I will approve code that doesn't have a limit, so the setting might as well have one.

JohnMcPMS · 2026-06-23T20:40:28Z

+| `maxConcurrentDownloads` | N/A | `MaxConcurrentDownloads` | GPO wins |
+| `maxConcurrentMsix` | N/A | `MaxConcurrentMsix` | GPO wins |
+
+### Group Policy


This doesn't feel like GP-type stuff.

JohnMcPMS · 2026-06-23T20:42:41Z

+    UInt32 MaxConcurrentOperations { get; set; };
+}
+
+interface IBatchInstallResult


This interface isn't referenced elsewhere. Is the intention to have a new batching function? COM already largely does what this spec is asking for, so I'm not sure that is needed.

JohnMcPMS · 2026-06-23T20:43:21Z

+    Boolean AllowParallelInstallation { get; set; };
+    UInt32 MaxConcurrentOperations { get; set; };


COM already does this, but if we wanted to give control it would be done on the PackageManager.

JohnMcPMS · 2026-06-23T20:43:43Z

+
+interface IPackageInstallResult2 : IPackageInstallResult
+{
+    InstallExecutionLane ExecutionLane { get; };  // MsixParallel, Win32Serialized, Skipped


I don't see any value in indicating this.

JohnMcPMS · 2026-06-23T20:45:48Z

+
+- Progress display uses text status markers (✓ ● ○ ✗) alongside descriptions for screen readers
+- Non-VT fallback ensures full accessibility without virtual terminal sequences
+- JSON output mode (`--output json`) provides machine-readable progress events


If you want that, it should be its own spec.

JohnMcPMS · 2026-06-23T20:47:03Z

+
+- **Fully backwards compatible** — Default behavior includes parallel MSIX, but `--sequential` restores fully sequential behavior
+- No manifest schema changes — works with all existing manifests using the `InstallerType` field
+- Single-package operations (`winget install Foo`) are unaffected (nothing to parallelize)


False, as dependencies are explicitly called out for parallelization in the spec.

florelis · 2026-06-26T22:31:37Z

+When users run operations that install multiple packages — `winget upgrade --all`, `winget import`, or `winget configure` — packages are installed sequentially today. For a workstation with 30 packages to upgrade, this can take 30+ minutes even though most time is spent waiting on downloads and independent installations.
+
+Key observations:
+- MSIX packages can be deployed concurrently (the deployment engine handles this natively, with a platform limit of ~6 concurrent operations)


Is this a documented limit, or something the MSIX team told us?

florelis · 2026-06-26T22:33:13Z

+- MSIX packages can be deployed concurrently (the deployment engine handles this natively, with a platform limit of ~6 concurrent operations)
+- MSI packages use the global `_MSIExecute` mutex — only one MSI can install at a time system-wide
+- All other Win32 installers (EXE, Inno, NSIS, Burn) offer no parallel guarantees — they may modify shared system state (PATH, registry, shared DLLs, file associations) in ways that conflict when run concurrently
+- Downloads are always safe to parallelize regardless of installer type


Unless we run into disk size limitations. There is the possibility of someone having enough space to save only one installer at once on the disk they use for that.

florelis · 2026-06-26T22:36:17Z

+| `portable` | Win32 serialized | Lightweight, but may still write to shared locations (PATH, shims) |
+| `zip` | Win32 serialized | Extraction may target shared directories |


There probably isn't much benefit to it since these should be fast anyways, but we could do things to ensure that these are safe to run in parallel.

florelis · 2026-06-26T22:38:13Z

+  [MSIX pool]   ████████░░ 4/5
+  [Win32 queue] ██████░░░░ 3/7  (current: Microsoft.DotNet.SDK.8)


I'm not sure users would care about the distinction. We could just report it as if there was a single queue.

florelis · 2026-06-26T22:48:00Z

+- **Realistic speedup** — For a mixed workload (some MSIX, mostly Win32), expect 1.5-2.5× improvement due to download overlap and concurrent MSIX. Pure-Win32 workloads benefit only from parallel downloads.
+- **Memory** — Each concurrent MSIX deployment has low overhead. Win32 queue runs one process at a time.
+
+## Potential Issues


Trying to download multiple installers could saturate the network adapter, and potentially be disruptive.

If we try parallel downloads from the beginning of the operation, that may end up making the first download take longer to complete, which could push the whole operation to take longer. Maybe instead of "download multiple packages at once" we could just do "download packages one by one, while others install"

Trenly reviewed Jun 17, 2026

View reviewed changes

JohnMcPMS reviewed Jun 23, 2026

View reviewed changes

florelis reviewed Jun 26, 2026

View reviewed changes


		### Schema Version

		Requires manifest schema version 1.29.0 for the `SafeForParallel` field. Parallel installation itself does not require schema changes — it works with existing manifests using installer type classification.


		## Abstract

		Enable parallel package installation in WinGet when multiple packages are being installed or upgraded simultaneously. This applies to `winget install` with multiple packages, `winget upgrade --all`, `winget import`, and `winget configure` flows. Packages are classified by installer type safety: MSIX packages can be installed concurrently (up to a configurable limit), while MSI/EXE packages that rely on the Windows Installer mutex are serialized. A dependency-aware scheduler maximizes throughput while respecting installer constraints.


		Even in the serialized queue, Windows Update or another system process may hold the `_MSIExecute` mutex when the next MSI package is ready to install:

		1. Before starting an MSI installation, check the mutex state


		#### `winget configure`

		Configuration files with multiple `Microsoft.WinGet/Package` resources are parallelized by the WinGet configuration engine:


		### Progress Reporting

		Multi-package progress uses a consolidated display:

		Boolean AllowParallelInstallation { get; set; };
		UInt32 MaxConcurrentOperations { get; set; };

		\| `portable` \| Win32 serialized \| Lightweight, but may still write to shared locations (PATH, shims) \|
		\| `zip` \| Win32 serialized \| Extraction may target shared directories \|

		[MSIX pool] ████████░░ 4/5
		[Win32 queue] ██████░░░░ 3/7 (current: Microsoft.DotNet.SDK.8)

Uh oh!

Conversation

denelon commented Jun 17, 2026 • edited by microsoft-github-policy-service Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📖 Description

🔗 References

🔍 Validation

✅ Checklist

📋 Issue Type

Microsoft Reviewers: Open in CodeFlow

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mominshaikhdev commented Jun 18, 2026

Uh oh!

Trenly commented Jun 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

denelon commented Jun 17, 2026 •

edited by microsoft-github-policy-service Bot

Loading