6

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.

Improve this question
8
  • 1
    If you fire up categories.exe (in same folder as arcmap.exe) and expand the Esri Mx Commandbars folder, do you see your toolbar's progid there? If not, try clicking "Add object" and browse to the dll that has the toolbar. docs.microsoft.com/en-us/windows/desktop/com/…
    – Kirk Kuykendall
    Sep 26, 2018 at 14:45
  • Thank you @Kirk for reminding me of the adult way to check for registered items. That utility lists the toolbar in question. The intermittence I noted takes the form of always displaying properly for me, never working for some, and sometimes working for some other users. For the sake of thoroughness, I asked someone who hasn't been able to see that toolbar to run categories.exe, and it lists the toolbar as well.
    – Dan Narsavage
    Sep 26, 2018 at 16:07
  • When you say "delete the user's profile", does that mean you've deleted the normal.mxt too?
    – Kirk Kuykendall
    Sep 26, 2018 at 19:03
  • 1
    Is it listed under Computer\HKEY_CURRENT_USER\Software\ESRI\Desktop10.X\ArcMap\Settings\CommandBarNameCache ?
    – Kirk Kuykendall
    Sep 26, 2018 at 19:11
  • @KirkKuykendall yes, all of C:\Users\UserName went up in smoke and the user was removed from . . . some "UserProfiles" registry key. And No! It's not listed in the user's CommandBarNameCache! Finally something concrete! Thank you!
    – Dan Narsavage
    Sep 26, 2018 at 19:25

2 Answers 2

Reset to default
2

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.

Improve this answer
4
  • I think maybe I'm missing something. The /u flag specifies UNregistration, no? So after executing that I should NOT see the toolbar & commands, right? Trying this on my dev machine... Running sans /s results in a success message and removal of the ecfg file from the CATID folder (leaving said folder empty in my case) as expected. But the toolbar & most commands still show up when I next open ArcMap. Some of those commands behave badly (I didn't bother tracking down the errors) but they're still there. Everything disappears (as expected) when I uninstall the extension using ARP.
    – Dan Narsavage
    Nov 2, 2018 at 17:18
  • 1
    @idestlaborum Yeah, you´re right with the unregistering. The purpose here is delete any registration from a previous build. However we also call esriregasm on build, which I forgot to mention.
    – MakePeaceGreatAgain
    Nov 2, 2018 at 21:21
  • This extension's installer runs esriregasm during install and uninstall. Does your script run in addition to that, or in place of it?
    – Dan Narsavage
    Nov 3, 2018 at 17:00
  • That depends on how you deploy your extension or your machine. Usually the installer is responsibe for registering. But if you compile your project without installing it, you have to manually register the assembly for ArcGIS as described above.
    – MakePeaceGreatAgain
    Nov 5, 2018 at 7:52
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.