This is a story about a native windows application installer that needed MSIX to help it work right. And a story about how the App-V package of that app needed MSIX to help it work right. And yes, also a story about how the MSIX package of that app works just right.
Let’s learn about the Shell extension context menu handler hell, our good friend, Notepad++, and a previously uncovered feature of MSIX that saves the day!
Backstory about Shell Extension Context Menus
There are (at least) three ways that an application can add right-click menus to files of certain types into the Windows explorer.
- Shell Integration Verb Commands. The application installer registers hard-coded menu item names and the command to run under a key named “Shell” under the filetype (or a ProgId pointed to by the filetype) in the windows registry classes key. The Windows Explorer process will consult the registry and add these items to the popup list when the user right-clicks on a file of this type. This method has been in Windows for a long as anyone can remember; it is older than dirt.
- Shell Extension Context Menu Handler. The application installer adds a COM In-Process dll that internally implements the IContext interface and registers it under the ShellEx key of the filetype/progid. This is sometimes referred to as the “traditional” or “legacy” version of the context menu handler. The Windows explorer will call this shell extension handler and ask it which menu items to add. This makes the list more dynamic as the handler can choose to look at the situation and offer different items for different situations. This method has also been around in Windows a really long time; it is as old as dirt.
- Shell Context Menu Command Handler. The application installer adds a COM In-Process dll that internally implements the IExplorerCommand interface and registers it under the Shell key of the filetype/progid, but using a registry item named ExplorerCommandHandler. This is sometimes referred to as the “Modern” version of the context menu handler. Like the traditional handler, this interface is called by Windows Explorer and asks which menus to add to the right click of the file. It has only been around since Windows Vista. Just a young puppy by Windows standards.
Backstory about Notepad++
Notepad++ is a free XML file editor program for Windows that is available on the internet. It has been around a long time, we aren’t sure how long but probably before Windows Vista.
Notepad++ originally implemented the Shell Extension Context Menu Handler iContext interface. In fact, most Windows software products that add a context menu use the traditional type of handler for this purpose.
At some point, Notepad++ switched over to the newer Shell Context Menu Command Handler iExplorerCommand interface. We don’t see a lot of apps doing this.
The odd thing is that, as far as we know, the result returned by the handler is always the same – it really isn’t dynamic. It always seems to just adds an entry to the list that says “Open in Notepad++” when the right click occurs. It also registers this to all file types, using the Classes\* key to register its shell extension. I mean, it could have been just a simple Shell verb!
More recently, the developer decided to take on the mess that Microsoft created in Windows 11 with right clicks. Their IExplorerCommand added menus were not appearing directly on the menu seen when you right-click. Instead, you had to select the “Show more options” item to see the full list (or hold the shift key when you right-click – something few people know to do).
When the installer runs, it adds the files to the system. In addition to the main program, this includes these two files in a subfolder.
The dll is the file that implements the context menu. The second is the msix package to be used in the installation later.
The installer next calls rundll32.exe against the NppShell.dll file that is the modern context menu handler implementation using the Shell and ExplorerCommandHandler item:
The rundll32 command also registered the COM CLSID as shown here:
These are the kind of registrations that a natively installed program would normally do.
But they also have this small MSIX package inside their traditional exe installation program. I have previously written about this in a blog post two years ago when attempting to re-package the entire application into an MSIX package: The Strange New Twists in Notepad++ Context Menu – Confessions of a Guru , although at the time I really didn’t understand why the developer did this.
My MSIX solution was to add detection of these new type of registry entries created by Rundll32 (which I had never seen before) into TMEditX and fix up the AppXManifest file to use the desktop4:FileExplorerContextMenu element for “modern” context menus. This is seamless and easy for repackaging into MSIX as it is an automatic default fixup in TMEditX. In essence, this means adding the same two applications extensions seen in the vendor msix package AppXManifest file here:
When this is vendor MSIX package installed by the native vendor exe installer into the system, there is now also a “PackagedCom” registration that can be seen in the registry. But previously I never understood how that vendor worked with the natively installed application until I was called up by a customer in Germany with an App-V problem involving this application.
The App-V issue
Many years ago, App-V had a well-known solution for the original context menu handler that required no special effort for someone repackaging Notepad++ with the old-schoolShell Extension Context Menu Handler with the IContext interface. You just repackaged it, and it was fine with no special steps needed.
App-V packagers also developed a solution to manually handle Notepad++ with the Shell Context Menu Handler with the IExplorerCommand interface. This typically involved an App-V package Publishing script to run regsvr32.exe against the context menu handler dll so that it was natively added to the registry. A tad ugly, but got the job done.
Then comes changes that Microsoft made in Windows 24H2. This messed up the App-V solution. A customer asked, so I looked into this further.
What was this magic MSIX package?
The MSIX package that the installer added was not a typical MSIX package. It contains no files that are part of the package! It is a “sparse package”, which is one that references files that are not part of the package. The vendor exe installer places this msix file right next to the dll which holds the context menu handler implementation. I did not understand the significance of this when I was looking to create a full MSIX package since we discard their msix file.
Investigating further for the App-V issue, I found that the package declares the capability “UnvirtualizedResources”, which, it turns out, allows the package AppXManifest.xml file to reference files that are not part of the package. Normally this is not possible, which is why I never understood that package. I previously uncovered this capability as also being needed for the unrelated “Flexible Virtualization” (See White Paper FileSystemWriteVirtualization and Blog RegistryWriteVirtualization) features, but never made the connection to this usage.
This vendor msix package appears to exist only for the purpose of adding the modern shell extension using the desktop4:FIleExplorerContextMenu element, along with the com:comserver element for the CLSID. These elements reference the name of the dll as a relative file, and if the file was in the root of the package then the UnvirtualizedResources capability would not have been needed.
But instead, the vendor exe installer uses a trick when installing the package to tell the package what folder the dll will be in. Although we think that the installer uses the PackageManager interface, the equivalent for the PowerShell command to add the argument -ExternalLocation <URI> to the Add-AppXPackage command, where <URI> is the folder where the exe installer placed the dll (by default under “C:\Program Files\Notepad++\contextMenu”. This trick makes the relative path to the file found in the AppXManifest file work when Windows Explorer sees the right click.
By installing the context menu handler this modern package way, the traditional installer get a right-click menu that appears like it used to before Microsoft messed things up. (I’m sure that someone from Microsoft would argue that it was for a good reason, but I am not listening…). Even when the installation is a traditional exe installation.
So, what does this mean for the App-V packaging? Well, it means that we can repackage into App-V and add a simple ps1 file into the folder that contains the dll and msix file. We change our recipe to have the Publish script call this PowerShell file.
So what does the PowerShell file do? It calls get-appvclientpackage against the known name of the package “Notepad XXX”, extracts the installation location of the App-V package from the returned object, which of course is not under C:\ProgramData\AppV and guids. It then runs the command Add-AppXPackage -ExternalLocation “<folder>\VFS\ProgramFilesX64\Notepad++\contextMenu” “<folder>\VFS\ProgramFilesX64\Notepad++\contextMenu\NppShell.msix” where <folder> is the returned installation location of the App-V package. For example, if the App-V package name was “NPP”:
|
$InsidePath = “VFS\ProgramFIlesX64\Notepad++\contextMenu” |
The customer reports that the App-V package now works as expected, and we learn a new trick for MSIX packages that will probably come in handy for other things.
