Lessons learned while working with ActiveX, Cab Files, INF files and automatic downloading

As I approach the end of a project that involves packaging an application within an ActiveX container, I thought it would be helpful to share some of the odd discoveries that I have experienced. Some of these will be documented on MSDN and some will be documented no-where! I searched endlessly to find out why some of the behaviour was working the way I saw it working, but found no answers. Enter the madness of ActiveX….

In my situation we have a somewhat complex application that is served up by a container activeX control (an OCX main window). To package up the files required for this application we create a cab file which contains all the dll’s etc.. and especially an INF file (with the same name as the ocx) which has instructions for Internet Explorer indicating how the application should be installed. The main components are:

1. The HTML tag that points to the location of the CAB file and the specific version of the OCX file container inside the cab file.

<OBJECT ID=”ctrl” CLASSID=”CLSID:14895D16-934D-40a1-B805-7CD3C36CE7E3″ CODEBASE=”CabTest.CAB#Version=2,0,50727″>

2. The OCX file, properly version stamped (confirm by right clicking on the ocx file and viewing the file version)

3. The INF file properly formatted (see comments below)

4. The Cab File properly build and deployed in the location where the HTML tag points to.

Things to watch out for:

– If the HTML tag is incorrectly formed, the CAB file may download but version checking may not work. The net result is that when you update the CAB on the Web Server hosting it, clients will not automatically download the new version. One example would be:

BAD TAG

<OBJECT ID=”ctrl” CLASSID=”CLSID:14895D16-934D-40a1-B805-7CD3C36CE7E3″ CODEBASE=”CabTest.CAB#Version=”2,0,50727″>

GOOD TAG

<OBJECT ID=”ctrl” CLASSID=”CLSID:14895D16-934D-40a1-B805-7CD3C36CE7E3″ CODEBASE=”CabTest.CAB#Version=2,0,50727″>

This tag will still allow the CAB to initiall download and install on a computer that has never seen the ActiveX control, but won’t download new version when the version # is changed. The problem is that ” character is in front of the version number and it should not be. If you expereince problems with new versions not auto-prompting to download, then check the HTML tag.

-INF file entries. There is a lot of information on MSDN regarding INF files, I will just mention some things that I feel are not clear or not mentioned at all on MSDN. First of all you’ll want to specify a FileVersion= entry and a DestDir= entry for ALL files. If you don’t specify the FileVersion=1,0,0,0 (where the version # is shown in Windows by right clicking and looking at the version tab for each file) then when Internet Explorer Downloads your cab file, it will check the environment variable called PATH (the system path) and if it finds any of the files already existing in the search path (with a different version or not) it will skip those files in the cab file and use the files that are already on your computer. By specifying a version you are enforcing that the version must be >= the version you specified in the INF. That leads me to the next interesting fact. Assume you are testing on your developer box and you already have some files in the system path. When you download the cab file, it will REPLACE the existing files that are found in the search path if they have a lesser version than the version you specify in the INF FileVersion= entry. That is weird, because you might expect to load DLL’s dynamically etc.. from the downloaded Program Files folder where IE usually places files that it extracts from your CAB file. To find out where these “rogue” files are located, open a command prompt and navigate to the cached downloads folder (usually c:\windows\downloaded program files) and type in the name of the file in question for example: mydll.dll. If it is found in the search path, windows will ask you to open that file using the program of your choice (i picked notepad). This will show you exactly where windows is finding that DLL. There seems to be NO WAY to force your files to be placed in the auto download folder if the files already exist elsewhere. Ytry to deploy files into C:Windows or c:\windows\system by setting the DestDir= value to 10 or 11, but that is a fairly cheesy fix (if it even works at all).

– When visiting the page that contains the HTML tag for my activeX control I just get a red X or a get errors from my half exploding activeX application. If that is what you are experiencing, check to see how far the Cab install was able to get to. Use cdllogview (check MSDN for the location to download it) and check the cached downloads folder (usually c:\windows\downloaded program files) to see if all the files that you expected to get extracted from the CAB file exist in here (or in a conflict.X subfolder). If not, it may be that one or more of those files in the CAB ALREADY exist in the system path and thus is causing you grief. You may force these misplaced files to get replaced with a newer version (see above) by entering a FileVersion= entry in the INF file but you cannot make the auto-deploy force the placement of these files to be in the auto download folder.

That’s all for now.


5 Responses to Lessons learned while working with ActiveX, Cab Files, INF files and automatic downloading

  1. Pingback:dykin's me2DAY

  2. Avatar Chris Denham
    Chris Denham says:

    I know I’m replying to a posting from over a year ago, but in my first adventure into ActiveX cab file installation, I discover exactly the problem you describe. i.e.

    1) If you don’t sepecify a FileVersion, it doesn’t install a DLL that it finds on the path even if it’s older than the one you want to install.

    2) If you do specify a FileVersion, it OVERWRITES older versions of DLL’s it finds on the path.

    Both cases seem totally unacceptable to me, what the heck is Microsoft playing at?

    In case 1, you control may not work beacuse it is using an old version of a dependency, or it may suddenly stop working when decide to remove some software that you didn’t realise had become a dependency of your control.

    In case 2, the activex cab installation completely f***s up another application that is incompatible with an upgraded dll! I could even just be coincidence that the dll has the same name, but performs a totally different function.

    Have you discovered any workarounds for this problem? I can’t find any info about it, and I can’t believe its not a major pain for anyone that writes activex controls then depend on any commonly named dlls.
    Chris Denham

  3. Unfortunately I know of no work-around. I no longer work in the realm of this activeX stuff so I haven’t kept up to date on any new developments. The last I looked I noticed that Vista and IE8 were introducing a way to install ActiveX controls “per user” instead of system wide. That may solve many problems, but I don’t klnow how far along that technology has come?

  4. Avatar Chris Denham
    Chris Denham says:

    Ok, thanks. I think I would like NOT to be working in ActiveX realm too. It’s an ugly mess, and combined with the dll hell and its “cure worse than disease” solution of Side-by-Side libraries, is a very grim ordeal.

    I noticed the “per user” ActiveX on IE8&Vista (at last!). Seems to work ok, but haven’t yet checked if is fixes this particular problem. Unfortuately I still need to support XP/IE7 in anycase.

    I’m tempted to try an alternative mechanism where something else gets run to unpack the dependencies next to the ocx. Maybe I could get the inf file to run a ‘mini’ installer, or make the ocx registration function perform the unpacking.

    Thanks for listening to my rant. 😉
    Chris.

  5. Hi Guys,

    Wondering if u can help me with this issue. Any help will be great, and Thanks in Advance!

    The ActiveX control that I am trying to install using the above method has different versions for different OS. Can you help with the way to do that? The rest code looks exactly same.

    Thanks and Regards,
    Sahil