Documentation is not confusing enough

[jeffbargmann]

It's about as clear as mud, but I think as clear as concrete would be more interesting.

Honest question: Microsoft seems to be going out of its way to make this more difficult for developers. We're a year in now and the situation hasn't improved. We already have code-signing and app model IDs etc. Will figure it out eventually here but is it really necessary to jump through all these poorly documented hoops? How is manually referencing a source at "C:\Program Files (x86)\Windows Kits\10\UnionMetadata<SDK_Version>\Windows.winmd" considered best practice in getting this done? Why isn't an actual command path given with MakeAppx.exe step, and instead, vague instructions? Why is every step of this made to be so manual? Is this really the level of quality of support you want to give, to enable devs to add menu items in Win11?

Sincerely. It looks like it's being made difficult on purpose.

[jeffbargmann]

Note to readers: give this sample a look. Much more usable sample from a non-Microsoft contributor. https://github.com/ikas-mc/ContextMenuForWindows11. Much appreciated R&D @ikas-mc.

It does involve sideloading a UWP app, but our strategy is just going to create a one-off package exclusively for context menu handling, because our hand has been forced, and we don't want to compromise reliability of the rest of our app with the package'ification distribution process. We'll just install this sideload package along with our app, and if it fails for some reason then all we'll lose is context menu support.

I understand the goal is to cut down on spam and to push the new packaging architecture, but fwiw the bad guys are gonna be the ones most motivated to figure this stuff out, and the last decade has shown that most apps in our ecosystem don't want/need this new packaging infrastructure. Casually-developed software will be what suffers the most. It doesn't need to be this hard. If it's that big a problem, provide more control for the user to turn this stuff off / utilize other existing runtime interfaces etc for app identification- don't require we package our app in an entirely new/different way. Thank you for listening and congrats on the development progress elsewhere in the shell.

[jerichoi224]

Dude, Can't agree more on what you mentioned. Trying to figure out this stuff and it just doesn't work at all.
Have to change everything written using IContextMenu to use IExplorerCommand instead, which is annoying enough, but then also need a signed package.. which I don't have for what I'm working on. So now I need a sparse package etc etc...

Really hoping the repo you mentioned works for me. Thanks for providing the link for reference!

[incheon-kim]

There is no any contraints information about Windows 11's new context menu extension.
It made me waste a bunch of time to find out which works or not. And it is not even clear if i did wrong. arghh!

Note to readers: give this sample a look. Much more usable sample from a non-Microsoft contributor. https://github.com/ikas-mc/ContextMenuForWindows11. Much appreciated R&D @ikas-mc.

It does involve sideloading a UWP app, but our strategy is just going to create a one-off package exclusively for context menu handling, because our hand has been forced, and we don't want to compromise reliability of the rest of our app with the package'ification distribution process. We'll just install this sideload package along with our app, and if it fails for some reason then all we'll lose is context menu support.

I understand the goal is to cut down on spam and to push the new packaging architecture, but fwiw the bad guys are gonna be the ones most motivated to figure this stuff out, and the last decade has shown that most apps in our ecosystem don't want/need this new packaging infrastructure. Casually-developed software will be what suffers the most. It doesn't need to be this hard. If it's that big a problem, provide more control for the user to turn this stuff off / utilize other existing runtime interfaces etc for app identification- don't require we package our app in an entirely new/different way. Thank you for listening and congrats on the development progress elsewhere in the shell.

about casually developed software, as an end-user, I gotta say, all software that are supposed to work for Windows 11 must support MSIX packaging.

dealing with .exe installers is a hell, specially software left overs, files, registry keys etc.

I love Windows store apps that work like Android apps, you can clear their data, you can repair them, reset them etc. and after you uninstall them, everything they installed is completely gone.

[FlurinBruehwiler]

I can't recommend https://github.com/xandfis/W11ContextMenuDemo and the accompanying video https://www.youtube.com/watch?v=LfBQm-FY-2I enough. It's way better than this repo, and it actually works.