Powertoys: Refactor PowerRename context menu registration to be reusable

[crutkas]

Other tools such as Image Resizer will need this. We should have a single base for how stuff hooks into the shell. This could be we have 2 libs for .NET and for C++ that other Toys call into but each toy shouldn't have to reimplement this work

FYI: @arjunbalgovind we'd have to migrate work toward this common base once it is online. in short term, mimic how powerrename does stuff for MSIX registration.

[arjunbalgovind]

@crutkas Since we currently have an independently working ImageResizer, I'll first work on moving that into PowerToys and I'll take up the context menu code migration after that since the two threads of work are more or less independent.

[crutkas]

For image Resizer, we'd migrate to this item in the future. The FYI was just to make you aware we want to have one system way to hook stuff up if at all possible.

[wjk]

Just a quick heads-up if we're going to be refactoring this: It is entirely possible to register a COM class in an MSIX package without needing to write an EXE server and calling CoRegisterClassObject(), by using the com:SurrogateServer element. I used this technique in my MSIX shell extension, and it works very well. Hope this helps!

[crutkas]

Wonder if this will solve #1197

[enricogior]

Hi @wjk
we didn't use that approach because it was causing the PowerRename UI to be modal (and block the Explorer UI thread). We will retry that approach, it requires a code refactoring of the PowerRename library since it was originally designed for MSI and we we use as it is we hit the bloacked UI thread issue. We will give it a try since at this stage that may solves two issues (the perf problem and the dialog not showing in the foreground).

[yuyoyuppe]

Alright, using COM SurrogateServer instead of ExeServer didn't solve the foreground issue, since CoAllowSetForegroundWindow call from explorer.exe doesn't propagate for both of these process chains:

• explorer => \
• explorer => \

[yuyoyuppe]

@wjk we might be unaware - what are the benefits of using SurrogateServer instead of ExeServer?

[wjk]

Just the ease in writing the server code, really. In particular, .NET Core doesn't support CoRegisterClassObject(), while it can easily generate an in-proc COM loader. Other than that, I see no differences between the two approaches. Thanks!

[crutkas]

more in terms of MSIX, closing for now