Install Woes

WOMM Certified!

I built an Arcmap extension on 9.2 SP 5, built an MSI and sent it off to the tester who tried to install on 9.2 SP3. He got the dreaded “Unable to get installer types…” message. All references to ESRI assemblies had their “Requires Specific Version” attribute set to False.

So I followed Richie Carmichael’s steps to create a ROBUST installer, and built a new msi. I only included the the Toolbar and Mx Extension in the reg file … these are really the only classes needing COM exposure. I really didn’t want to click on every COM class and change its attributes, so I just removed them from the reg file. Another annoyance: VS2005’s import command chokes on reg files containing comments.

Tried to install again – same problem. Maybe I missed one of Richie’s steps?

So I installed .NET explorer onto the test machine, copied the offending DLL to it, and examined its dependencies. When I double clicked on the Spatial Analyst assembly it could not find it. After looking further, it couldn’t find any of the assemblies from build 1420.

Perhaps setting “specific version” to false only provides backwards compatibility – not forward. I resolved by including those DLLs in the MSI. Since we are dealing with COM behind the scenes, signatures shouldn’t change, so having an assembly that is more recent than the COM library shouldn’t cause problems, should it? I sit with fingers crossed, waiting for test results.

If not, it seems like ESRI could provide policy files that specifying forward compatibility within a minor revision.

When I have time, I will re-visit Richies’ Robust steps. I must confess I’ve never really worried that much about uninstallation, but from what he says, I probably should:

However, once installed correctly a user may experience problems uninstalling the custom component if one or more of the dependencies is missing. This may arise if the user has uninstalled ArcGIS Desktop or upgraded (or downgraded) to another version. The only workaround is for the user to restore the same environment as during install time.

I’m anxious to get this project out the door to continue work on solutions using the DBMS for deployment of assemblies. This makes me realize I should see if there’s a way to do bindingRedirects (like those in policy-files) with assemblies dynamically loaded from blobs in the DBMS.


14 comments so far

  1. Ed on

    Glad I’m not the only one.

    I too have taken a look at Richie’s steps and thought about implementing them. But in the end, because SPs are free, and users should for their own good have them installed, I just make them a precondition of my installer and catch that error that way. 98% of my clients have had no problems.

  2. Kirk Kuykendall on

    This msi is being deployed to a large organization whose IT department is required to thoroughly test each new SP before installing them. Needless to say, they are a bit behind the curve.

  3. Thomas Emge on


    there is no ‘easy’ workaround.

    What I’ve done in the past (and I am still doing it) is to keep the original, final assemblies around and compile against those. What does it means?
    You copy the assemblies (meaning the DotNET folder) from your 9.2 install into separate folder before you install any SP. Within your project you then manually reference the required assemblies using the “Browse” tab as opposed to the “.NET” tab. At that point the development machine is always targeting the official release (for 9.2 it would be build 1324) regardless of the actual SP on the development machine or the SP on final deployment machine. The only requirement is that some sort of 9.2 version is installed.
    It mostly works across releases as well. So you could have 9.2 on the development machine but targeting 9.0 on the deployment machine if you were building your project against the .NET build 535 assemblies. However there are some gotchas between releases with respect to introducing new namespaces and libraries.
    I should mention that it is a completely ESRI unsupported approach 😉

    Good luck,


  4. Kirk Kuykendall on

    Hi Thomas –

    Thanks for the response. Has ESRI considered supporting forward compatibility via the policy files?
    Instead of this:

    bindingRedirect oldVersion=”″
    Maybe this:
    bindingRedirect oldVersion=”″


  5. Thomas Emge on


    I am not sure….in case they didn’t it would be a nice enhancement request.

    – Thomas

  6. Paolo on

    We came at the same point.
    We decided to build an installer on an ArcGis desktop 9.0 platform without any SP. This way will work for 9.1 and 9.2 and any service pack.

  7. Colby on

    The problem, as far as I have been able to trace, is that Use Specific Version only tells the compiler not to worry the version of a reference when compiling the dll. As far as I can see, it doesn’t impact the runtime binding of the .dll. That is, if your build machine has v1.1.1.1, then the resulting .dll will look for v1.1.1.1 on the target machine (following all of Fusion’s redirection policies, of course).

    As for linking against a newer version and hoping that it will successfully run against an older version, It may work, but it’s risky. What happens if you take advantage of a method, interface, or CoClass that was introduced in v1.1.1.2 and want to run against v1.1.1.1?

    The easiest solution I have found is to set up a build machine installed with the oldest version of ArcObjects your application is willing to support. You still have to set Specific Version to false (or it won’t compile), but it has solved the problem consistently.

    FWIW, I use CruiseControl.Net, NUnit, NCover, and a few other common utilities to listen to changes to the source control repository, and start up a new build whenever there are changes. The build runs the unit tests in debug mode and, if successful, builds a release version including the installer. It takes a little work to get all of the version numbers to update correctly, but once configured correctly, you always have a compiled version of the application for QA. Moreover, it’s traceable via its version number back to a label in source control so you can figure out where you broke functionality that used to work.

    Sorry for the length. Hope this helps.

  8. Kirk Kuykendall on

    Hey Colby –

    Thanks for the feedback.

    I’m hoping that the COM underpinnings of ArcObjects means no new methods are introduced to an interface. (I’m not using the ArcGIS Server assemblies) Within a service pack, I don’t think new interfaces are introduced.

    I really can’t afford separate machines for different service packs. Maybe some day virtual machines will be practical for this.

    I wish someone hosted a service with cruisecontrol where I could manage source and run arcobjects tests as you describe.


  9. Colby on


    We virtualized all of the build machines. Since they weren’t being used interactively, there were no real performance constraints. So, we just built a bunch of machines hosted by Virtual Server on a cheap Windows 2003 Server box (lots of RAM and disk space, but cheap processor). The nice part about that was being able to have environments to build from ArcObjects 8.3 all the way up to the present release. It also meant you could spin up a particular version to troubleshoot a client bug report.

    As for the changes between versions, the only time I had real problems was when ESRI decided to change namespaces for the .NET helper classes. That broke any hope for forward and backward compatibility.


  10. Kirk Kuykendall on

    Colby –

    Thanks, I think I’d better do something like this. My list of legacy platforms is growing faster than my inventory of machines.


  11. Paolo on

    “As for the changes between versions, the only time I had real problems was when ESRI decided to change namespaces for the .NET helper classes. That broke any hope for forward and backward compatibility.”

    it was, if i remember, the shift from 8.3 to 9.0 and i was very disappointed.
    Anyway, also from 9.1 to 9.2 we had problems because of geodatabase supporting double precision.

  12. Kirk Kuykendall on

    Hey Paolo – Yes, I think ESRI broke a few COM rules (like changing GUIDs of TypeLibs) for 8.3->9.0. It was a Revolution though, not a Revision, so I guess it can be excused.

  13. Kirk Kuykendall on

    Enhance request for policy file changes has been submitted: NIM036896

  14. […] of .NET Forward Compatibility I’ve whined about this before. As Entchev points out, new service packs often break extensions. I’m not certain it is […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: