Add manifest validation COM API specification

[Kaleb Luedtke (Trenly)]

📖 Description

Adds a specification for a new Microsoft.Management.Deployment COM API that validates singleton and multi-file WinGet manifests using the existing native validation pipeline.

The proposed API:

• accepts a manifest file or directory path;
• supports full, partial, and schema-only validation;
• exposes warning and verified-publisher validation options;
• returns structured, forward-compatible diagnostics; and
• intentionally excludes network-dependent MSIX installer payload validation.

The specification also describes result semantics, compatibility, security, performance, activation, and test coverage. GitHub Copilot assisted with codebase analysis and drafting.

🔗 References

Related Issues

• Add manifest validation COM API #6545
• PowerShell Module Full Parity with WinGet CLI #6288

🔍 Validation

• Ran git diff --check.
• No automated tests were run because this change only adds design documentation.

✅ Checklist

• Signed the Contributor License Agreement
• Linked to an issue
• Updated Release Notes (not applicable to a specification-only change)
• Updated documentation (if applicable)
• Updated Copilot instructions (not applicable; no build, architecture, or convention changes)

📋 Issue Type

• Bug fix
• Feature
• Task

Microsoft Reviewers: Open in CodeFlow

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Kaleb Luedtke (Trenly)]

After more research this is aready implemented by wingetutil.dll, however, a native COM interface could be complimentary to the DLL and / or would be more accessible to those building manifest tooling

[JohnMcPMS]

After more research this is aready implemented by wingetutil.dll, however, a native COM interface could be complimentary to the DLL and / or would be more accessible to those building manifest tooling

I'm just not sure of who the customer is really. This seems so niche and anyone who really wants to do it has an avenue.

[Kaleb Luedtke (Trenly)]

After more research this is aready implemented by wingetutil.dll, however, a native COM interface could be complimentary to the DLL and / or would be more accessible to those building manifest tooling

I'm just not sure of who the customer is really. This seems so niche and anyone who really wants to do it has an avenue.

Part of it would be the internal requests for the PowerShell module to have all of the capabilities of the CLI - adding this to the COM server would enable that more easily. I'm also thinking of other tooling like Komac which could benefit from not having to pull in the additional DLL

[JohnMcPMS]

Not sure that this needs to be async. We should start sync and add async if there is demand in the future.

[JohnMcPMS]

Null options should be supported as equivalent to a default constructed options.