[RESOLVED] VB6 Deploy Depenencies issue on Win7 64 bit.

Hi,

I have a Out of Process ACTIVEX EXE that will run under all OSes from XP to Windows 7 32 bit, but not run under windows 7 x64 unless I first start it's hosting application as administrator or install the VB6 IDE on that faulting box.

I am redistributing comdlg32.ocx, comctl32.ocx, mscomct2.ocx from cumulative update roll up for the Visual Basic 6.0 Service Pack 6 Runtime Extended Files with it.

Since installing the VB6 IDE on the faulting Win7 64 bit box to fix it is that a sure fire dependency issue?

Thanks in advance again,

:Ron

Are you creating a setup or just a dependency file?

Ya know, the dependency file is what I'll persue.

Seems a bit over zealous though. As it my program won't run without a truckload of stuff - which seems as though it's just not so.
I will walk some of the file over and see if one fixes it though.

Good idea,
Thanks.

:Ron

I'm amazed this even "works" on 32-bit post-XP Windows systems as described, but it may be falling through the Pachinko Machine of legacy appcompat with a favorably kludged result I suppose. It only works on XP and other downlevel systems if run by users in the Administrators group, something long discouraged.


The question I'd have is why your installer doesn't register the ActiveX EXE properly? Any results achieved by installing the VB6 development system falls into the same category of thrashing around, since it has no direct bearing on this.

You are relying on self-registration on first run, which is why running the ActiveX EXE's client elevated takes care of this.


Even a PDW setup is smart enough to handle this properly. If you are using the PDW then we'd need to see your setup.lst file, which may not have been created properly somehow.

Quote:

---

Originally Posted by bitman

I am redistributing comdlg32.ocx, comctl32.ocx, mscomct2.ocx from cumulative update roll up for the Visual Basic 6.0 Service Pack 6 Runtime Extended Files with it.

---

As far as I know there is no version of this "update" (and Microsoft has published at least 5 known attempts to get this right) that did not contain numerous off-by-one bugs as well as causing issues with COM interface versioning and "ghost" class ID registration on victim systems.

Worse yet if you fall into the trap of installing these "updates" they can't be rolled back. The only real fix is to reformat the partition and reinstall Windows.

We've discussed this many times here.

I can open a cmd windows as administrator and do a filname / registerserver so the registration is ok
The registery entrys all good. It's not a registration issue. AFAIK

I can even see class initialize() start up as it says so but it dies with the first object = new formname.

- But only on x64 and only if the VB6 is not install AND if I don't first run the app as admin

It is very weird.

Right now my beta testers are just running the host app as admin (once) and were all golden but it's goota get fixed.
:-)

:ron

Quote:

---

Originally Posted by bitman

I can open a cmd windows as administrator and do a filname / registerserver so the registration is ok
The registery entrys all good. It's not a registration issue. AFAIK

---

This is how self-registration is done (actually the switch is /regserver). So clearly it is a registration issue.

Quote:

---

Originally Posted by bitman

I can even see class initialize() start up as it says so but it dies with the first object = new formname.

- But only on x64 and only if the VB6 is not install AND if I don't first run the app as admin

---

Yes, you need to register this ActiveX server to use it.

Quote:

---

Originally Posted by bitman

Right now my beta testers are just running the host app as admin (once) and were all golden but it's goota get fixed.

---

Your program is not a "host" in any sense of the word. It is a client.

It's Fixed! - Thank God it's Fixed!

MSCOMCT2.OCX exists but is not registered by default in x64 SP1

Cue the band.....

I think if you check Windows 7 does not come with this OCX at all.

After Win7 SP1 with IE10 all sorts of odd things occur with its registration though, as discussed here several times. Again, a proper installer should take care of that.

It does.

I have a Win7 x64 Sp1 disc here, just reformatted verified the file is in syswow64, added the regsvr32 for the mscomct2.ocx files to the installer commit, installed that and away we go!
:-)

Thanks for all your help!

Moved to the Application Deployment forum.

Joacim!

What Up! :D

Quote:

---

Originally Posted by bitman

Thanks for all your help!

---

Does that mean you have resolved the issue? If so please mark the thread "Resolved".