Custom ArcObjects Toolbar Unavailable for Some Users

Question

I'm responsible for maintaining an extension to ArcMap that consists of a toolbar with a bunch of menus & commands & tools. It uses the old-style COM registration for all of its UI. Recent installations on our test machines have intermittently refused to put the toolbar in the list of toolbars that users can select. It is listed for me (a local admin) always; for others sometimes, and for still others never.

Even when the toolbar is not listed, most of the custom commands and such (likely all of them, but there are several dozen and I'm too lazy to take a definitive tally) are available in ArcMap's Customize window.

At first I assumed that the COM registration was failing specifically for the toolbar, but there is a registry entry for HKEY_CLASSES_ROOT\CLSID\MyToolbars.ProgID.MatchesMyToolbars.NetNamespace so I think everything looks okay there.

Where else might I look to find a cause of this issue?

Updates & Fresh Breadcrumbs

1. Based on Kirk's advice in the comments I confirmed that the toolbar is registered using the categories.exe utility.

2. A coworker discovered that if he enables the extension that comes in the same library as the toolbar, closes ArcMap, then reopens ArcMap, the toolbar appears in the list. Deleting the user's profile indeed resets the problem.

3. A well-meaning sysadmin found that running CCleaner clears up the problem, but they ran it wholesale and made no log of what was changed. On the one remaining test machine that wasn't CCleaned, I re-did that cleaning incrementally to determine which piece of flotsam causes the problem but came up empty-handed.

4. All but one of the test machines (the one that I cleaned manually in (3)) have been rebuilt from a new image and the problem persists. If anything its intermittence has decreased, and the toolbar is more likely not to be available.

5. After the rebuild I was able to determine with a moderate level of confidence (still some intermittence) that the installation protocol I use on our test computers contains bugs. Working on a potential fix now.

Answer 1

We regularily have the same problem. Thus we created a script that does all the unregistration of old COM-objects and re-registering a newer version - e.g. efter compiling our ArcObjects-code. This script executes ESRIRegAsm to do the esri-registration:

set EsriRegasm="%CommonProgramFiles%\ArcGIS\bin\ESRIRegAsm.exe"
IF EXIST MyAssembly.DLL %EsriRegasm% /p:desktop /u /s MyAssembly.dll

After re-building our assembly and calling EsriRegAsm again in order to register the new version you should be able to see the entry within the windows-registry as mentioned in your question plus an ECFG-file with the samext same name as your assembly (with extension .ecfg) in C:\Program Files (x86)\Common Files\ArcGIS\Desktop10.6\Configuration\CATID. If the file is not there, ArcMap won´t find your toolbar.

You can also open that file, it´s basically a zip-file containing a config.xml. This file contains the GUIDs of your toolbars and its related tools and commands.

In some cases you may have a file from a previous build also, which has a name similar to {3c7448a8-c8b9-4704-aa14-699ed583132b}_MyAssemmbly.cmds. You should delete those files.

Answer 2

Let the Installer Handle Itself

After a couple of the test computers were rebuilt, the problem became somewhat less intermittent and I was able to track it down to installation; more specifically to uninstalling previous versions. I have a batch file that automates installing new builds on all the test machines. To uninstall old versions, that batch file contained a line like . . .

psexec \\machineName wmic product where "name = 'My Terrible Extension'" call uninstall

. . . and that seems to have caused the issues at hand. The WIX-based installer uninstalls all older versions on its own (with a MajorUpgrade element), and there's no need for my batch file to specify uninstallation separately. The problem seems to have gone away after removing that psexec ... call uninstall bit from that batch file.

My previous understanding of MSI was that it only looked at the first three parts of version numbers, and the specific uninstall was my consequent attempt to keep the Add/Remove Programs window somewhat clean (and leave no question about what's being tested) since installs on the test computers are frequent and usually involve changes only to the fourth portion of the version number. But after re-running the batch file sans psexec ... call uninstall, I found that v8.0.3.833 was no longer listed in ARP after v8.0.3.834 was installed.

For good measure though, I plan either to add AllowSameVersionUpgrades="yes" to the MajorUpgrade element in the WXS, or to go back and redo the version numbering scheme for this project on our build server so that it changes the third portion instead of the fourth. This thing doesn't see enough action to necessitate using all four parts of its version number.