Since then, we've discovered the need to create separate shell packages, with completely separate builds. The intention here was to make our shell integrations modular, and reduce dependencies between them as much as possible. There is one complicating factor in that we'd like all of the packages to share the same top-level ribbon menu item as the original package, and add their submenus into that at registration time. For a while, we were able to just copy the hierarchy in the .ctd file from the first package into the second, and just swap out the submenu bits. This seemed to work, as the registration process appeared to recognize and match the GUIDs from the previously installed package and just add in the submenu items from the new package in the correct spots. It's always been an assumption that this is what was happening internally with spregpkg.exe, with no way for us to actually confirm it.
However, with the newest upgrade to 4.3.10.1 (our previous version was 4.3.7,) this seems to have broken. After the upgrade, registering both packages caused duplicate menus to show up, from the top level down. I did find a solution to this, which involves the following:
- Modifying the original package (I'll refer to it as "Package A" from here on out) to set the export value on the ID we want to bind to from the second package (Package B) in the Symbols section to true
- Deploying and registering Package A as usual
- Modifying the .ctd file on the Package B to add an include alias with the href attribute set to location of the .cts file generated by Package A in its .ctd file
- Removing the nodes in (Package B).ctd that were copied over from Package A, and instead using <MenuRef id="PackageA:topRibbon" /> and adding the child groups and submenus accordingly.
Is there a better method for all of this?