How to roll out a new Version of an ActiveX Control written in VB6

Question

I have to maintain an old active x control written in VB6.

As we developed some new functions for it, I now need to roll out this new version to the users. How can this be done in the least obstrusive way?

The control is embedded like this

<OBJECT classid="clsid:..." CODEBASE="activex/plugin/myOCX.CAB#version=1,0,0,42">
    <PARAM name="RunOnLoad" value="true"></PARAM>
    [...]
</OBJECT>

No, when I change the #version to the actual one (1,0,0,80), it doesn't change anything. IE still loads the old version (which I can check through a function that alerts the version of the OCX).

Only when I delete the OCX from my machine and then load the page, it prints out the new version.

Obviously, the users can't and shouldn't have to do that. So the question remains: How can I effectively force my users on the new version, once it's been deployed to the server?

Answer 1

As IE successfully downloads and installs the component after you delete existing version from your machine, it's all about versioning. At this point I could think of several scenarios.

Scenario 1: bad .INF file

Open your .CAB file. You shall see .INF file inside. Open this .INF file and locate [<component name>.ocx] section. Check value of FileVersion=..., it should be FileVersion=1,0,0,80. I found out that this value is not updated automatically if you update existing .CAB file via .BAT script previously generated by Package & Deployment Wizard.

Scenario 2: Test environment polluted by the build process

Another scenario I can think of is that you are testing on the same machine that you used to build new version of your control. In that case your control could be registered by the build process. Here it helps to understand how does COM activation work anyway? It is always a good idea to test on a machine other than build server though.

Possibility 1: build process created AppID named-value under HCKR\CLSID\{clsid} registry key

As per KB167597:

In pseudo-code, here's how component download is controlled for the <OBJECT> tag:

   Check the Registry for CLSID
   If CLSID of OBJECT is NOT found in the registry
      Download OBJECT
   Else If no #Version specified in CODEBASE tag
      Use OBJECT installed on system
   Else
      Check InprocServer32 key for location of installed component
      If File version of installed component < CODEBASE #Version Tag
         Download OBJECT

There are a couple of exceptions to the above sequence. If an AppID key is found under the CLSID, the component is usually registered to run through DCOM and is not updated. Also, an Installed Version key takes precedence over the file version. This is used for Java classes and non-PE (portable executable) files.

To confirm the idea, check if there is AppID registry value for your component on the machine you use for testing. Your users, most likely, will not have AppID set for the CLSID on their machines. That's unless your component is used in at least one more different scenario, of course. Larry Osterman has a blog post When do you need an APPID in your COM registration? Also check this MSDN blog post if you're unsure what AppID is.

How can I find out if AppID is set for a CLSID? Open registry editor regedt32, and check values under HKEY_CLASSES_ROOT\CLSID\{<clsid>} key. Look for AppId named-value of type REG_SZ.

Possibility 2: build process altered default value of HCKR\CLSID\{clsid}\InprocServer32 registry key

Check default value ((Default)) of HCKR\CLSID\{clsid}\InprocServer32 registry key. If it points to the location you use as output of component compilation process then it, most likely, has been set during build (unless you put build results directly to C:\WINDOWS\Downloaded Program Files which I really doubt). OS uses this value to determine what binary to use on COM component activation. Run regsvr32 /u <path to the .ocx created during compilation> and re-run your test with a webpage.

---

If nothing helps, you need to investigate the issue more carefully. Fire up Process Monitor, ask it to trace registry and file system activity for IE process, and see how IE decides (not to) update your control. Interesting information in collected traces should begin right after registry query for your control's CLSID.