1

I ran into an issue yesterday trying to share an application I made with some friends. I gave them my exe and the osx files required to run the application. They tried to run it and kept getting messages about the files not being registered. So I told them to run Regsrv32.exe path/to/file/filename.ocx and they kept getting errors.

Come to find out, only way they could register these files was from an Administator command prompt. So that means that UAC is making it extremely hard for me to share my work with friends.

Is there a way I can create a setup file that will automatically register these files so I can distribute my application without people having to go through all this just to open my stuff?

John Saunders
  • 160,644
  • 26
  • 247
  • 397
FrostByte
  • 103
  • 9
  • 3
    Sure, by using any installation builder (Google "Inno Setup" for a free one that's quite good). Your friends will still have to run the installer as Administrator, however. – Ken White Sep 17 '14 at 18:00
  • 2
    Any installer that is designed to work on Vista or up will automatically prompt for elevation, though, so they won't have to do anything special to run it as an administrator. Of course, they will have to be signed in with an account that can install stuff (or at least be able to enter the credentials for such an account,) as with any other program. – reirab Sep 17 '14 at 18:02
  • Reirab the Inno Setup that Ken mentioned will that ask for elevation privileges also? If it asks that's perfect they can accept it and everything is good. Just sucks at the moment because I can't let anyone test my stuff till I get this worked out. – FrostByte Sep 17 '14 at 18:33
  • Actually I just downloaded the Inno Setup and I created an installed with my OCX files added and when they ran the setup it did not ask for permissions. So that program isn't going to work unless it has an option for it. – FrostByte Sep 17 '14 at 18:52
  • Actually did some research on Inno and you can add some tags in the code to auto register the files when it installs them. It works well, that's exactly what I needed. Thanks Ken White! – FrostByte Sep 17 '14 at 19:40
  • More advice about how to create an installer for VB6 program in this question http://stackoverflow.com/questions/23836/how-to-create-a-simple-install-system-for-vb6-on-xp-vista – MarkJ Sep 17 '14 at 23:02
  • How does this solve the need to have admin rights? Also, poorly authored InnoSetup scripts are one of the leading causes of DLL Hell today. I'd avoid it like the plague in favor of tools that help beginners create more correct deplyoment packages. Even the PDW is far better in novice hands. – Bob77 Sep 18 '14 at 07:55
  • You can use "registry-free-COM" so that your end users don't have to do anything "as administrator". See the top answer in this question http://stackoverflow.com/questions/270523/vb6-xcopy-deployment – MarkJ Sep 18 '14 at 14:21
  • @Bob77 Inno asks for privileges at the start of the setup.exe. As soon as you open the installer it tells you that you need privileges with the UAC. As soon as you click yes, it can do whatever it needs to do. As long as the installer prompts for privileges, there won't ever be an issue. – FrostByte Sep 18 '14 at 16:33
  • @MarkJ the link you provided has a dead link to the manifest. That doesn't do me any good if I can't access the page. – FrostByte Sep 18 '14 at 16:37
  • @MarkJ I did a little research on it on microsoft's website and from what I read a manifest file uses the .net framework. The whole reason I like vb6 is it doesn't require some framework in order to work. I can distribute the files needed and anyone can run it from any pc even windows xp. A person using windows xp would have to install .net framework just to use my installer seems to me like a silly idea. Especially when there is still a ton of users that are using windows xp. – FrostByte Sep 18 '14 at 16:53
  • You're right, the link is broken, thanks for telling me that. I see [here](http://web.archive.org/web/20140829021337/http://mmm4vb6.atom5.com/) that the author was having trouble with their hosting and has provided another location to get Make My Manifest - [download it here](https://app.box.com/s/yvm0wk95e1lachm7juf5). And it's not necessary for your user to install the .Net framework, this feature is not part of .Net. – MarkJ Sep 19 '14 at 11:01

2 Answers2

1

As Ken White has said Inno Setup is a great app to do just this. After you install the app use the wizard to create your setup file. It will show you the configuration in the main window when it's done. Just look for the code that says...

[Files]
Source: "C:\path to files\whatever.ocx" DestDir: "{app}"; Flags: ignoreversion

At the end of the line after Flags: just add regserver so it looks like this.

[Files]
Source: "C:\path to files\whatever.ocx" DestDir: "{app}"; Flags: ignoreversion regserver

Now your setup will automatic register that ocx file after it places it in the folder. :)

Make sure after you add the new code in you recompile the setup from the menu at the top.

Deanna
  • 23,876
  • 7
  • 71
  • 156
FrostByte
  • 103
  • 9
  • And then hope you author your install and uninstall scripts to properly increment, check, and decrement component usage counts in the registry... so that when some poor user uninstalls your Inno-fied application he doesn't break 18 other applications on his PC by deleting shared libraries. This is happening far too often, and as a result I consider Inno to be malware. Not evil in itself but unsafe at any speed. – Bob77 Sep 19 '14 at 15:23
  • @Bob77 That can only happen if you have your setup install your files into the system directory or some folder where other applications may access the files. If you distribute your files into their whole program files folder and have them deleted as your application is deleted there is no way that could happen. You will only be deleting the files you had installed nothing else. The moral of the story is you can't fix stupid. Isolate your files from the rest of the operating system and problem solved. – FrostByte Oct 03 '14 at 21:06
  • 1
    ActiveX registration is global, and has nothing to do with file placement. This is exactly why InnoSetup leads to so much DLL Hell. If you want such libraries isolated you must use isolation (SxS) manifests and then *not* register them at all. – Bob77 Oct 04 '14 at 16:52
  • Adding the 'sharedfile' flag to the script should prevent the problem that Bob describes. I do agree that Frostbyte's remark about that installing the ocx to another folder than the Windows system folder will prevent dll hell is untrue. – Dabblernl Oct 04 '14 at 17:31
0

I suggest you consider using a proper installer rather than a legacy scripted installer technology such as InnoSetup, which is worse than most because it relies on hand-built scripts.

Common scenario:

  • App A uses a proper installer, everything is fine.
  • App B uses InnoSetup with a weakly-authored script. This copies one or more ActiveX libraries to non-standard locations and they overlap with those installed properly by A. Sadly the Inno script re-registers the libraries and now the registry points to the weird locations.
  • Everything runs Ok... for a while.
  • App B is uninstalled, and not bothering with using proper library locations as specified in the libraries' .DEP files, and not bothering to respect library usage counts, it deletes its own copies of the libraries.
  • Now app A, C, D, E, etc. that used any of these libraries are all broken.
  • And who gets the support calls?? Not Captain Inno!

Another scenario:

  • App Q uses InnoSetup with a weakly-authored script. This pulls the same stunts, but maybe even copies a few libraries where they actually belong.
  • App Q gets uninstalled, but just deletes the libraries and leaves now-broken registration entries behind.
  • App R uses one or more of the same libraries, but using a proper installer sees them already installed (since they are registered) and doesn't copy them.
  • App R will never run.
  • And who gets the support calls? Not Captain Inno!

Yes another:

  • App W is a VB6 program that got "installed" by just copying the EXE and all related ActiveX DLLs and OCXs next to the EXE (same folder).
  • First run of app W, the VB6 runtime can't find the libraries registered but tracks them down via DLL Search (LoadLibrary) and self-registers them in place.
  • App X is installed via a proper installer, sees the libraries it needs are already registered and doesn't copy them to their proper locations or re-register them.
  • Everything is fine... for a while.
  • User "uninstalls" app W by deleting its EXE folder (taking the libraries with it).
  • Now app X, Y, Z, etc. that used any of these libraries are broken. Even a reinstall doesn't help.
  • And who gets the support calls? Not Perfessor XCopy!

What we have is a collision between those who follow deployment rules and those who ignore them... or just make their own up.

What's the honest guy to do?

The only answer is to decry this whenever it is recommended, and in the meantime use isolated assemblies with SxS manifests in self defense.

Bob77
  • 13,167
  • 1
  • 29
  • 37
  • I think you may be doing Inno setup an injustice. Reading the docs for the 'sharedfile' flag under the [Files] section it seems that Inno setup is capable of playing nice with shared dlls. Moreover: We use Inno for many years and have not seen any dll issues on uninstall. – Dabblernl Oct 04 '14 at 17:22
  • There is no problem with InnoSetup itself. However it is far too widely misused, typically by copy/pasting substandard scripts or attempting shenanigans such as dumping libraries into strange locations and later deleting them. In careful hands it works *just fine*. One can cause problems using anyone's installer tools improperly, it is just more likely with those tools relying on hand-crafted scripting. – Bob77 Oct 05 '14 at 13:29
  • So, what 'proper' installer would you recommend then? – Dabblernl Oct 05 '14 at 14:36
  • Even the PDW can be far safer, though it also has issues (especially if you do not keep the `[Do Not Redistribute]` section of VB6DEP.INI up to date - it isn't 1998 anymore). But you are better off using Visual Studio 6.0 Installer 1.1 or a 3rd party commercial product that can build proper MSI packages. – Bob77 Oct 05 '14 at 16:19
  • Thank you for the explanation of all this. I actually forgot that once you register the files they are global so anything installed after them that actually requires those files will use the same ones. I can see that being an issue. I'll check into doing it the ways you suggest. Thanks again. – FrostByte Oct 05 '14 at 22:42
  • Okay, so if I want to install the ocx files and register them, but install them into system32 or SysWoW64 and have it so they stay there and not uninstalled if the application is uninstalled what is the best way to achieve this? – FrostByte Oct 05 '14 at 22:45
  • OCX files should come with a .DEP file that says where they should be installed. In most cases non-Microsoft libraries should never go into System32, but into a Program Files\Common Files subfolder, though sadly many 3rd parties break that rule. A decent install packager looks for those .DEP files and uses the specified location. If you create your own OCX you should be creating a corresponding .DEP file too. As far removal of shared libraries, there are usage counts stored in the registry that get created, incremented, or decremented as applications are installed or uninstalled. – Bob77 Oct 06 '14 at 02:44