Documentation on AppXManifest COM Schema for Com:ComInterface

[TimMangan]

Describe the bug

The documentation for COM:ComInterface https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-com-cominterface and the chain below them are shown as a child of the COM:Extension under an Application. This likely stems from the COM:Extension documentation showing it only as an Application extension when it can be either an Application level extension or a Package level extension, depending on its contents.

The Package-level COM:Extension is used to define typelibs, interfaces, and proxystubs. The SDK schema files confirm this. Microsoft's MSIX Packaging Tool always creates them this way, MakeAppx/MakeMsix utilities also support them this way.

As I see it, at least the following documentation pages need updating:

• https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-com-extension
• https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-com-cominterface
• https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-com-proxystub
• https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-com2-proxystubdll (Also check title on that page as it says COM when it is COM2)
• https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-com-interface
• https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-com-typelib
• https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-com-version
• https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-com-win32path
• https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-com-win64path

Some of the elements might have dual use both under Application and Package level in certain scenarios.

Quite possibly the COM4:ComInterface also needs some reviewing, but I'm not trying to work with it currently.

I am pretty sure that I reported this as an issue on the direct page back when we reported issues that way several years ago (probably Drew might remember it) but it was never resolved.

Steps to reproduce the bug

Review the COM schema files for the AppXManifest from the SDK.
Look at the referenced documentation pages for hierarchy structure.

Expected behavior

No response

Screenshots

No response

NuGet package version

None

Packaging type

Packaged (MSIX)

Windows version

No response

IDE

No response

Additional context

Here is an example of usage form seen in AppXManifest files:

<Package ...>
<Identity ... />
...

...


<com:Extension Category="window.comInterface">
com:ComInterface
<com:TypeLib Id="...">
<com:Version VersionNumber="..." ... >
<com:Win32Path Path="..." />
</com:Version>
</com:TypeLib>
<com:Interface Id="..." ... >
<com:TypeLib Id="...">
...
</com:TypeLib>
</com:Interface>
</com:Extension>

[DarranRowe]

The annoying thing about docs updates is that it is often faster to do it yourself.
The fastest and most definitive course of action would be to mirror the MicrosoftDocs/winrt-related repo, make the changes that you think are needed and then create a pr out of it.

This isn't the first time that docs have been stale for a long period, I still remember that it took years for the namespaces for application manifests to be fixed. They were https for such a long period of time.

[DrusTheAxe]

Thank you for reporting this. I've passed along word to the doc and dev team.