Error 339 *.OCX' or one of its dependencies not correctly registered 2

[TLowder]

Hello,

VB6 setup via Package and Deployment Wizard

XP Pro

Run-time error : 339. component '*.OCX' or one of its dependencies not correctly registered: a file is miising or invalid

I'm getting the error on one computer when logged in as user. The program was installed under admin and works fine there. I've setup many other computers the same and haven't had this problem before. The only thing different would be that I used a newer setup than before, created with package and deployment wizard. The new version should not have changed from the last except for a newer exe and perhaps one new dll reference. I really don't think it was the setup that is bad just something perhaps in windows that caused this different behavior.

It's multiple ocx's in question. They were all nonstandard ocx's specific to my program. The first error was a custom button isbutton.ocx. I tried regsvr32 again, unregister and register again, then I unregistered it and put in app.path and it worked but the error moved to the next ocx - MTUSBHIDSwipe.ocx. Then it want to another ocx, I can't remember the name and don't have the computer with my as I left it with them just signed in as admin. I ended up stuck as it didn't work on the 3rd one, and besides who knows how many more there were. For now I can just leave it as admin cause it doesn't really matter on this station but I would still like to figure this out, especially if it happens again on another computer. I also tried adding a new user, reinstalling with the last setup I used that I know worked. But even if that is the issue I guess it was too late unless I deleted all the ocx's that gave me trouble then ran the old setup, maybe I should have tried
that.
So for now I have it working and anything I need to try won't be done till I go back to the location, which will be soon but I don't have immediate plans of going there. I wish I had noticed the error before I went to the client and had more time to figure it out. Unfortuanatly I did all my testing and setup in the admin account and didn't realize the user issue till I got on location.

Thanks for your help, any suggestions appreciated.

Tom

 

[Bluejay07]

I use Inno Script for setup and deployment. For the scripts, I have to physically add the ocx's used by VB6 and Inno Script compiler registers it during the setup.

With that being said (I haven't used Package and Deployment Wizard), have you verified that any required ocx is handled properly when creating the deployment package?

Other things that I have come across is if the user does not have sufficient rights or permissions on the machine.

Many users are given extremely basic user rights so that system settings are not tampered with. If the rights are limited, registering an ocx could be blocked. When it comes to user rights/permissions, I usually encounter problems while trying to access/edit an SQL database.

I hope you are able to figure things out.
Best of luck.

 

[dilettante]

Sounds a bit like PRB: Component Not Registered Error When Attempting to Run a VB Application.

 

[TLowder]

Thank you both for your responses.

Dilettante, Sounds exactly like that so I did some more reading. Since its XP Pro simple file sharing is turned on by default and you do not have access to the security tab. Next time at that computer I may need to turn off simple file sharing to be able to have access to the security tab as described. Then I will see if Users have read permissions on the neccesary files. Normally all this works fine. I wonder if simple file sharing is and was already turned off when I installed my app thus possibly causing this issue.

Other references I read if anyone else has the same issue -

http://support.microsoft.com/kb/308419

To turn off simple file sharing thus giving access to security tab -

http://support.microsoft.com/kb/307874#letmefixit

I'll post back after I get to the computer to give it a try.

Thanks,

Tom

 

[dilettante]

The only other suggestions I have may or may not be helpful.

Putting COM libraries "next to" your EXE

This is generally a bad idea unless you know your libraries are exclusive to your program. When the program starts and the libraries are not currently registered, the VB runtime will call their self-reg entrypoints. The result can be a mishmash of per-user component registrations. If some subsequent application using the same libraries is installed it will use your "private" copies (which are not private at all). Removing your application may break the second application.

Where to put 3rd party COM libraries?

Usually System32 is a bad idea because newer versions of Windows can be quite protective of this location. Most standard controls supplied with VB6 are meant to go there though, so you may have to use "smart installer" technology like Windows Installer to make everything go off without a hitch.

However even Microsoft doesn't do this with newer shared COM libraries. Instead they go into a subfolder beneath [ProgramFilesCommonFolder] also known as $(CommonFiles) also known as CSIDL_PROGRAM_FILES_COMMON, e.g. C:\Program Files\Common prior to Vista.

Most 3rd party components should ship with a .DEP file that provides this guidance to the PDW, but updated .DEP files are rare these days. Usually they go into a subfolder in the form: CompanyName\ProductName.

This avoids inadvertant self-registration and is compatible with normal installer "usage counting" of components to avoid their being removed early (i.e. while another program still needs them). Of course installing by calling regsvr32 (which just calls the library's self-reg entrypoint) doesn't set/update that counter. PDW setups should do so though for items installed as "shared.

 

[TLowder]

Just to update this thread with what I did -

Simple file sharing was already turned on as it should have been. So I did exacly what I said previously and it worked fine after 5 or 6 ocx's -

Turn off simple file sharing (To enable security tab)
Add 'Everyone' in the sercurity tab of each ocx giving error
Turn back on simple file sharing

Thanks for all your help.

Tom

 

[TLowder]

And also I had a look at my setup.lst files. For example this is one of the ocx's giving me the error -

File9=@IsButton.ocx,$(WinSysPath),$(DLLSelfRegister),$(Shared),5/23/08 10:09:13 PM,253952,1.0.0.0

This line was the exactly same in a previous setup package that I know worked. This should mean there was nothing wrong with the setup package I used and was not the cause of the error. I still don't know what originally caused this issue and its only happened on one computer.

Thanks,

Tom