I have an older ocx version in a downloaded MS Merge Module.
The Merge Module is added to the AI package.

There is a newer version of the ocx from MS, but I need the older version for now..

This 32 bit ocx is normally installed into the SysWOW64 folder.

So, with that said, I want to install the older version along side with a possible present newer version.

The customer may already have the older version installed, or the newer one.

Should I remove the file from the merge module (it is the only file in it), add it in AI to the application folder, and use the Isolated Components function on it?

What happens if the same version is already in the SysWOW64 folder? Or is there no worry here?

Thank you!

clint

Hello Clint,

Considering your scenario I think the safest approach would be to simply add the related OCX file alongside your application files (in the same folder) in "Files and Folders" page. Also, there is no need to add the OCX component in the Isolated Components list of your application component. This option is useful when having a file A installed under a SharedDirectoryA, and a another file B installed under a DirectoryB. If you will add the ComponentA in the isolated components list of ComponentB, then at install time the file A, outside of being installed in SharedDirectoryA, it will be also copied in the DirectoryB (the installation folder of the file B).

What happens if the same version is already in the SysWOW64 folder? Or is there no worry here?

If the same version (or a higher one) of the file already exists on target machine, then the already existing file won't be overwritten. Please take a look on the "File Versioning Rules" article.

All the best,
Daniel

Hello Daniel,
Thank you for your reply.

Concerning File Versioning rules: This is an older Microsoft Com ocx for VB6 and I am concerned with the registry, and things getting messed up if just simply installed it in the Application folder.

Problem is, MS will not be updating this OCX any longer (last in 2010) and the last update it has flaws (it is definitely flaws only in the OCX) with certain functionality which my application uses.

I am afraid just placing the Ocx in the app folder will break everything and cause problems, being a self registering component.

I was told on another site (tek-tips.com/eng-tips.com) by a MVP that I need to use a maniscript for reg-free COM packaging in order to isolate the OCX (such as this: Side-By-Side Manifest Maker). I was hoping AI could handle something like this. I was also told that using the IsolationComponents action would mess things up bad. And that in any case, placing the this type of ocx in the Apps folder is an absolute no-no.

So, I am not sure what to do now. I cannot risk messing up customers machines, therefore I need to ask for more specifics.

(I have uploaded the MSM file with the older version).

Thank you.
clint

Hello Clint,

Unfortunately, we don't have any predefined support to register side by side different versions of a COM OCX file. Also, I'm afraid I'm not aware how this can be achieved.

All the best,
Daniel

Hi Daniel,

Just got done testing a solution, and saw your post. But I still need your help with something (at the bottom in bold)

I created a manifest with help from another person on that mentioned site.

The OCX gets installed, and not registered, in a sub folder of the application is located, which is named "DEP" (Any name can be used, as long as it is set in the manifest.

The with a text editor I created a file called:
SomeApp.Exe.Manifest
(Replacing SomeApp.exe of course with the real name of the exe)

Contents of the manifest are: And, it seems to work.

Any warnings from your end?

I also need you to tell me how to keep MSI from registering the ocx. It must not be registered in the Windows registry.
Is it enought to do take the check mark away in the file properties "Registration" tab "Auto Register File"?

Thank you!
clint

Hi Daniel,

it also works if there is already the same OCX and Version number installed on the system.

But, I will for now just manually install this on a case-by-case basis, as the problem arises, because nothing else needs to be done except adding the manifest file and OCX in a sub folder.

From hundreds of custioners over the past 5 years since this OCX update was published, there has only been this one incident.


Thank you for your time!

clint

Hello Clint,

Any warnings from your end?

I also need you to tell me how to keep MSI from registering the ocx. It must not be registered in the Windows registry.

I'm not sure, but I think as long as you don't register the installed OCX file, you shouldn't encounter any conflicts. In order to not register the installed OCX file on target system, yes, you should make sure no option from our "Registration" tab is checked.

All the best,
Daniel