Package and Deployment error

[NeilFrank]

I have used the Inno Setup Compiler to create an installer for my VB6 application, which I’ve developed on an XP machine. I use the resulting setup.exe to successfully install the app on my two Windows 7 machines. However, in both cases, when I try to run the app I get the following error:

Component ‘MSWINSCK.OCX’ or one of its dependencies not correctly registered: a file is missing or invalid

As far as I know, I do not use this .ocx in my app. (It is in the WINDOWS\system32 directory on my XP machine).

After some sleuthing, I found

http://angrybyte.com/windows-hacks/mswinsck-ocx-for-64-bit-windows-7-vista/.

This had me install MSWINSCK.OCX in the Windows\SysWOW64 directory (as opposed to the Windows\System32 directory) on my Windows 7 machine. Unfortunately, an attempt to register this file on my Windows 7 machine [regsvr32 c:\windows\syswow64\MSWINSCK.OCX] gave me the following error:

RegSvr32: The module “c:\windows\syswow64\MSWINSCK.OCX” was loaded but the call to DllRegisterServer failed with the error code 0x8002801c.

More googling finds

http://answers.microsoft.com/en-us/...002801c/518c72cd-2a89-47fa-bf01-cb88470b1f0c,

which tells me to obtain an up to date version of mscomct2.ocx (from

http://activex.microsoft.com/controls/vb6/mscomct2.cab).

I install this in C:\Windows\SysWOW64 on my Windows 7 machine. However, an attempt to register this gave the same error code 0x8002801c message.

Any thoughts? Thanks in advance for your expert help.

 

[HughLerwill]

I'm not familiar with Inno however;

>I do not use this .ocx in my app

So have you checked to ensure that it is not included in the Inno installation script? There seems little point in jumping through hopps to install it if you really do not need it.

 

[dilettante]

If you get the error at runtime, then clearly your program is trying to use this control. If you "don't know" your program uses it this suggests a possible malware infection - though that seems like a stretch.

I consider tools like Inno Setup fairly hazardous, since they do little to help you get things right. Instead people seem to copy/paste script snippets they find lying around on the Internet and use them blindly, leading to all sorts of DLL Hell for users gulled into running the resulting installers.

This screwing around trying to manually dump things into SysWOW64 and register them doesn't bode well. With a proper installer you should not even need to be aware of the filesystem redirection done for 32-bit processes.


Take a step back and try to create and deploy a setup package created using the PDW. If you can't get this right, using a product with sharp knives on the dashboard facing the front seat occupants (like Inno) isn't going to help you.

Ideally you would give up on legacy scripted installers and use Windows Installer packages instead. This requires a little more understanding of proper component registration, however the standard merge modules take care of this for VB6 components.

 

[NeilFrank]

I had checked. MSWINSCK.ocx is not in my Inno script.

I hadn't realized that Inno Setup was unreliable. I will certainly try the PDW.

 

[dilettante]

No, there is nothing unreliable about Inno Setup. It just has no way to keep you from doing bad things by mistake.

Of course that OCX isn't in your script. Your program clearly requires it and cannot find it once installed. That's why you get that error message.

 

[NeilFrank]

When I run the setup.exe on the XP machine on which I developed the app, all is well. What does this tell me?

 

[strongm]

Absolutely nothing. The development machine already has all the required controls installed.

 

[Bluejay07]

FYI,
When using regsvr32 on Windows 7, click the start orb and type cmd. Before clicking on it, right click and Run As Administrator. I believe administrator rights is also required to register any other file.

In addition, InnoSetup has a function to specify x86 computers, although I haven't fully tested it yet. This will install files into the proper folder regardless if the system is 32 or 63 bit.

ArchitechturesAllowed=x86

In addition, here is line of code my company has used in Inno Setup for winsock.

Source: "C:\Windows\system32\MSWINSCK.OCX"; DestDir: "{sys}"; Flags: restartreplace uninsneveruninstall sharedfile regserver

If at first you don't succeed, then sky diving wasn't meant for you!

 

[NeilFrank]

Thank you, Bluejay07. I'll give these a try.

 

[TLowder]

Another thought is to put it in the CommonFilesSys dir

File8=@MSWINSCK.OCX,$(CommonFilesSys),$(DLLSelfRegister),$(Shared),3/9/04 12:00:00 AM,124688,6.1.97.82

I've found its best to put files here for non admin windows users. This may help your issue too. I have never done anything with windows 7, but there should be the same or similiar dir.

Tom

 

[NeilFrank]

Thanks TLowder. Will look into this as well.

 

[dilettante]

Don't dump these kinds of libraries into random locations, you just make a mess of users' systems. The particular OCX, like most that come with VB6, has an associated .DEP file that among other things tells installers where it is supposed to be installed.

Inno is not smart enough to look at .DEP files, so users of that tool tend to create all sorts of messes leading to DLL Hell.


The original problem appears to be that your program uses the Winsock control and your copy/pasted script failed to deploy it.

Use a tool that doesn't have so many sharp edges and you won't have these problems.