Spontaneous reconfig MS Office when running my Setup

[Pirie]

I have a serious problem with a Setup for my VB6 application that I have made with SF7:

In the file list I have a number of MS OCX's and DLL's which I install to %SystemFolder%. For each file I have "Never overwrite existing file" set. Furthermore, for the OCX's I have "Register COM interfaces" set where possible.

I also have VB6 checked under "Dependencies".

The problem is this:

When I run the setup on a PC where "Microsoft Office 2003" is installed, it causes MS Office to spontaneously try to reconfigure itself. It looks as if I am overwriting and possibly reregistering a DLL or OCX that MS Office also uses. However, I thought I had prevented that by using "Never overwrite existing file".

If this happens when a new customer is using the Setup then I'm worried that this will scare him into abandoning our setp procedure for good.

Does anybody know what could be causing this and how I can prevent this from happening from within SF7?

[jassing]

If you (examples only) register c:\windows\system32\msfile.ocx
and office had it in c:\program files\common files\Microsoft shared\msfile.ocx
Now you've reconfigured msfile.ocx to be yours w/o overwriting it.

[Pirie]

If I follow you correctly, a better approach would be not to Register each MS OCX automatically using the File Properties but, in coding:

1. Interrogate Registry to see if the OCX is already registered.

2. Only register if the OCX is not already registered.

As far as I can see, it's safe to copy the OCX to Windows\System32 with 'Don't overwrite existing file'.

If this is correct, then the next question is 'How do I determine whether an OCX is already registered'?

[jassing]

the next question is 'How do I determine whether an OCX is already registered'?

Depending on the object, you need to check for a registry entry.
sometimes the easist way to do this is to export the registry; then do a regsvr32 on the ocx and export the registry then compare the two exports.

You can also use something like regmon to monitor the registry changes that it makes.

Of course, you need to do this on a system that doesn't already have it. or do a regsvr32 /u 1st.

[Pirie]

mmm... It sounds quite complicated to automate this in an sf7 procedure.

I suppose that I could also program my sf7 installation procedure to install all MS dependencies to my installation folder (not Windows\System32) and not register them. In that way, I don't get in the way of any other apps (like MS Office) that use some of the files and have registered them. This approach goes at the expense of having duplicate copies of controls on the user's system of course but it seems to me that this would be safe. Do you agree?

[jassing]

You would do the investigation OUTSIDE of SUF -- on a test machine, manually; once you identify the registry setting that indicates the ocx is installed & registered, you SUF could would simple do a Registry.DoesKeyExist() call to determine whether or not to install it.

yes, just installing it your application folder would lead to multiple copies of the file installed -- but what you're doing now also does that.

[rosalind]

The problem you are facing regarding your computer is a complicated one. one of my friend had faced the similar problem earlier. He had sought help from supportonclick.com and it solved his problem immediately. You may also opt for their support and i hope it will also help to solve your problem.