2

I have a VB6 Application that I am deploying using Microsoft Development Environment.

The install package is working for Windows 7/10 32/64 bit.

The problem I am having is if a second user logs into windows and runs the installed app some of the controls are not working. Forms that contain MSCOMCT2.OCX, TABCTL32.OCX and maybe others fail saying: "Component ... or one of is dependencies not correctly registered: a file is missing or invalid"

But once again for the user that installed the app all is good. I see in other installs there is a choice to install for only me or all users. I don't see a way to implement that in "Microsoft Development Environment", is this my problem?

What changes if you install an app for All users?

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
GDutton
  • 164
  • 14
  • 1
    I have to ask, what is the "Microsoft Development Environment"? I don't know that and Google doesn't find it either. As for the problem itself: you need to register these controls as with administrative permissions _(seems to work fine, as it works for one user)_ **and** make them accessible to _all_ users. Typically these files and their dependencies are located in SYSTEM32 (32-bit) or SysWOW64 (64-bit). – Hel O'Ween Oct 22 '21 at 07:13
  • MDE is what my Co uses to build deployment packages its copyright is Microsoft 1987-1998! The install works fine for the first user (the user that installed it) but not for the second user. The controls are being registered by an administrative account. They are being put into the system directories. – GDutton Oct 22 '21 at 11:49
  • Hmm, that's strange. So just to clarify that: the second user logs into the _same_ machine as the first user for whom the application works properly? If nothing else, try another installer like the free [Inno Setup](https://jrsoftware.org/isinfo.php), perhaps along with [this VB6 addin](https://jrsoftware.org/is3rdparty.php). It's hard to give advice for MDE, when it doesn't even shows up in search results. – Hel O'Ween Oct 22 '21 at 12:07
  • This probably has to do with registry virtualization. The application may be running in some kind of compatibility mode so that the controls are not really being installed system-wide. – StayOnTarget Oct 22 '21 at 12:10
  • Yeah, it sounds like some legacy scripted setup that was not run elevated. – Bob77 Oct 22 '21 at 19:02

1 Answers1

1

This may have to do with registry virtualization. The application may be running in some kind of compatibility mode so that the controls are not really being installed system-wide.

I'm not too familiar with those settings but it might be possible to adjust them so that the DLLs/OCX files are genuinely registered for all users and the application runs accordingly. There is a risk that if the compatibility settings were set intentionally, this could break something else.

Hopefully this is a useful starting point.

I will add that IMO installing the application not to require registration whatsoever is a much more robust solution. See How can you force VB6 to use the DLLs and OCXs from the app directory?

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81