Analysis of COM Registrations missed by the Microsoft MSIX Packaging Tool: InProcServer32 exes


When using the Microsoft MSIX Packaging Tool, there are situations where the tool fails to register all COM CLSIDs in the AppXManifest.

While there may be many causes of COM registrations that are captured in the virtual registry being ignored, one strange one that shows up is a COM CLSID registration with an InProcServer32 key where the default value is an exe and not a dll.


I can't say that I understand why such a registration would happen; but possibly because this COM clsid is only utilized from the exe when running as a process, so that it is loaded "in-process" to itself, even though it exists in an exe.


One example application that has this behavior is TechSmith's SnagIt application.  I also noticed by running some scripts on systems with native apps installed that on one of my systems Visio.exe also registers a handle of InProcServer32 COM CLSID guids to itself.


Since the registration of COM under MSIX goes into the AppXManifest file, this leads to a problem in that you can't define an InProcessServer with a path that ends in anything other than ".dll".


While I believe that the ExeServer element is intended for out-of-process COM clsids, the documentation doesn't clearly define this.  


Is it possible to support such an application with MSIX registration in the AppXManifest (even if done by hand)?

0 Replies