Packaging my app

[namazso]

So i have a shell extension that adds a property sheet page to file properties: https://github.com/namazso/OpenHashTab

Since I already have an user-only installer, I thought it would be possible to pack as at least runFullTrust appx. I was thinking of making a "manager" application where users can enable context menu and property sheet page (since the later obviously can't be solved with appx as of now, nor will it ever be a high priority).

And this is the point where the hurdles came: Full path to program files changes every version, and there's no appropriate hooks (install, update, uninstall) where i could run custom code to adjust for this. There are also no symlinks or anything that just point to latest one. For registering my COM class the old way, I need to provide the path to the dll.

Okay, next idea was that surely there must be a way to register a COM class from appx manifest, right? Apparently yes, there is! I hacked up a quick manifest with this snippet, mainly crowdsourced from github search:

		<com:Extension Category="windows.comInterface">
			<com:ComInterface>
				<com:ProxyStub DisplayName="OpenHashTab Shell Extension"
							   Id="23b5bdd4-7669-42b8-9cdc-beebc8a5baa9">
					<com2:ProxyStubDll ProcessorArchitecture="x64"
									   Path="OpenHashTab.dll" />
				</com:ProxyStub>
				<com:Interface Id="23b5bdd4-7669-42b8-9cdc-beebc8a5baa9"
							   ProxyStubClsid="23b5bdd4-7669-42b8-9cdc-beebc8a5baa9" />
			</com:ComInterface>
		</com:Extension>

However, this seems to not register the way I want - It appears in various subfolders of HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PackagedCom\. And additionally ProcessorArchitecture does not support ARM64 which is probably an oversight by Microsoft. I tried registering the clsid as property sheet page and as expected it doesn't work.

Does anyone have any suggestions on how I could achieve this, or should I just accept AppX is just incapable of this as of now, even with the runFullTrust capability?

[ghost]

why are you thinking to package it(zip it) in the first place?
what advantage will you get using AppX ?

[namazso]

I need a package identity for having a top level context menu entry on windows 11 anyways, so it would be great to package the whole thing, and possibly do a Microsoft Store release too.

[ghost]

you can use sparse packaging, windows 11 store accepts raw exe even PWAs

[namazso]

yes, that's the backup plan.

[samiranshah-zz]

This is unfortunately outside the scope of what can be configured in appxmanifests. This sort of Shell extension requires implementing an inproc class that’s visible from outside of the package, which is not supported.

From the manifest snippet, it looks like you are trying to use one of the few types of inproc activation we do support from outside of the package: proxy/stub activation. Although proxy/stub factories are implemented as inproc COM classes, they’re slightly special; they’re only visible when COM is specifically activating a proxy/stub class. Since they’re invisible to normal inproc activations, Shell doesn’t see them when attempting to activate the registered extension CLSID. That’s the immediate reason why this doesn’t work.

For the time being, the best option would be to use sparse packages. Until Appxmanifests and the Shell support this sort of extension explicitly (similar to windows.fileExplorerContextMenus), a full Desktop Bridge package is not viable for this scenario.

[namazso]

well, this is unfortunate. Since (unlike context menus) property sheet pages don't make sense in a sandboxed environment, i don't hold my hopes high for any kind of appx support for this in the near future. It's also the reason i was looking at workarounds a runFullTrust could (ab)use. It's unfortunate that that fails on such a simple problem as not having a stable path across versions.