Backstory about Notepad++<\/h4>\n
Notepad++ is a free XML file editor program for Windows that is available on the internet.\u00a0 It has been around a long time<\/em>, we aren’t sure how long but probably before Windows Vista.<\/p>\n Notepad++ originally implemented the Shell Extension Context Menu Handler iContext interface.\u00a0 In fact, most Windows software products that add a context menu use the traditional type of handler for this purpose.<\/p>\n At some point, Notepad++ switched over to the newer Shell Context Menu Command Handler iExplorerCommand interface.\u00a0 We don’t see a lot of apps doing this.<\/p>\n 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.\u00a0 It always seems to just adds an entry to the list that says “Open in Notepad++” when the right click occurs.\u00a0 It also registers this to all file types, using the Classes\\* key to register its shell extension.\u00a0 I mean, it could have been just a simple Shell verb!\u00a0\u00a0<\/p>\n More recently, the developer decided to take on the mess that Microsoft created in Windows 11 with right clicks.\u00a0 Their IExplorerCommand added menus were not appearing directly on the menu seen when you right-click.\u00a0 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).<\/p>\n When the installer runs, it adds the files to the system.\u00a0 In addition to the main program, this includes these two files in a subfolder.<\/p>\n The dll is the file that implements the context menu.\u00a0 The second is the msix package to be used in the installation later.<\/p>\n 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:<\/p>\n The rundll32 command also registered the COM CLSID as shown here:<\/p>\n These are the kind of registrations that a natively installed program would normally do.<\/p>\n But they also have this small MSIX package inside their traditional exe installation program.<\/strong>\u00a0 \u00a0I have previously written about this in a blog post two years ago when attempting to re-package the entire application into an MSIX package:\u00a0The Strange New Twists in Notepad++ Context Menu \u2013 Confessions of a Guru<\/a> , although at the time I really didn’t understand why the developer did this.<\/p>\n 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.\u00a0 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:<\/p>\n 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.\u00a0 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.<\/p>\n 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.\u00a0 You just repackaged it, and it was fine with no special steps needed.\u00a0<\/p>\n App-V packagers also developed a solution to manually handle Notepad++ with the Shell Context Menu Handler with the IExplorerCommand interface.\u00a0 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.\u00a0 A tad ugly, but got the job done.<\/p>\n Then comes changes that Microsoft made in Windows 24H2.\u00a0 This messed up the App-V solution.\u00a0 A customer asked, so I looked into this further.<\/p>\n The MSIX package that the installer added was not a typical MSIX package.\u00a0 It contains no files that are part of the package!\u00a0 It is a “sparse package”, which is one that references files that are not part of the package.\u00a0 The vendor exe installer places this msix file right next to the dll which holds the context menu handler implementation.\u00a0 I did not understand the significance of this when I was looking to create a full MSIX package since we discard their msix file.<\/p>\n Investigating further for the App-V issue, I found that the package declares the capability “UnvirtualizedResources”<\/strong>, which, it turns out, allows the package AppXManifest.xml file to reference files that are not part of the package.\u00a0 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<\/a>\u00a0and Blog RegistryWriteVirtualization<\/a>) features, but never made the connection to this usage.<\/p>\n 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.\u00a0 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.<\/p>\n But instead, the vendor exe installer uses a trick when installing the package to tell the package what folder the dll will be in.\u00a0 Although we think that the installer uses the PackageManager interface, the equivalent for the PowerShell command to add the argument -ExternalLocation <URI><\/strong> 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”.\u00a0 This trick makes the relative path to the file found in the AppXManifest file work when Windows Explorer sees the right click.<\/p>\n 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…).\u00a0 Even when the installation is a traditional exe installation.<\/p>\n So, what does this mean for the App-V packaging?\u00a0 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.\u00a0 We change our recipe to have the Publish script call this PowerShell file.<\/p>\n So what does the PowerShell file do?\u00a0 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.\u00a0 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.\u00a0 For example, if the App-V package name was “NPP”:<\/p>\n\n\n\n![\"\"](\"https:\/\/www.tmurgent.com\/TmBlog\/wp-content\/uploads\/2025\/11\/NPP_Files-300x97.jpg\")
<\/p>\n<\/div>\n![\"\"](\"https:\/\/www.tmurgent.com\/TmBlog\/wp-content\/uploads\/2025\/11\/NPP_SHex_RunDll-300x166.jpg\")
<\/p>\n<\/div>\n![\"\"](\"https:\/\/www.tmurgent.com\/TmBlog\/wp-content\/uploads\/2025\/11\/NPP_SHex_Clsid-300x51.jpg\")
<\/p>\n<\/div>\n![\"\"](\"https:\/\/www.tmurgent.com\/TmBlog\/wp-content\/uploads\/2025\/11\/NPP_MsixManifest-300x194.jpg\")
<\/p>\n<\/div>\nThe App-V issue<\/h4>\n
What was this magic MSIX package?<\/h4>\n