my vb project is looking for OCXs in the wrong directory

[ddiamond]

When I try to open a visual basic project that someone else created, I get an error message that it can't find vsflex8.ocx. I do have vsflex8.ocx installed on my computer, but not in the directory that vb was searching. Here is the line from the vbp file:

Object={BEEECC20-4D5F-4F8B-BFDC-5D9B6FBDE09D}#1.0#0; vsflex8.ocx

What determines which directory vb will search? I would have assumed the directory was stored in the registry when I installed the component, but I guess I'm wrong. I could hard code the directory into the vbp file, but then it might break on someone elses computer. Does anyone have a more flexible solution? Any advice is appreciated.

 

[gmmastros]

You may have multiple instances of the vsflex8.ocx file registered on your computer. There is a registry cleaner that I use in circumstances like this. It's freeware and can be found here.

http://www.geocities.com/drdole/ScreenShots/OleClean.html

I'm not sure if this will resolve your problem, but I suspect it will.

Good luck.

-George

Strong and bitter words indicate a weak cause. - Fortune cookie wisdom

 

[ddiamond]

Is OleClean safe?

 

[ddiamond]

George,

OleClean did not help, but I finally did get it working. What I did was load the project with errors. Then I manually made a reference to the OCX in question and then save the vbp file under a different name (I only save the vbp file, not any of the other forms/modules/classes). The strange part is that after doing this, both the new and the original vbp file worked. I compared the 2 files in a text editor, and they were identical. So I don't know why it worked, but it did.

- Dan

 

[gmmastros]

>> Is OleClean safe?

The page I directed you to makes it sounds nasty, like you could end up loosing your whole system, etc, etc.

I use OleClean at least every couple months for the last 4 years (or so), and have never had a problem.

Anyway, I'm glad you got it to work.

-George

Strong and bitter words indicate a weak cause. - Fortune cookie wisdom

 

[yacyac]

Dan
I have had this problem in the past when i have created a program on one computer and then moved it to another. The problem definitely is that computer1 and computer2 have the dll or ocx in different places. Correcting it is easy. Open the project, then select project > Component. If you click on each component you are using, you will see the location of the dll or ocx it is using. You can then change this path.

 

[ddiamond]

Thanks George and yacyac.

George, when you run OleClean, it shows a lot of stuff that I know nothing about. Do you normally just select everything, or do you only select the things that you know are safe to delete?

yacyac, I'm still unclear where the dll path is being stored. I did not see the path in the vbp file. You are correct in that I did move this project from one computer to another, and the path of the dll was pointing to its lacation on the original computer.

 

[gmmastros]

I always select everything that OleClean suggests. Maybe I am a little naive, but I have never had a problem running it. Instead, it has always fixed my problem.

-George

Strong and bitter words indicate a weak cause. - Fortune cookie wisdom

 

[BobRodes]

<What determines which directory vb will search?

That's in the registry. There's only one location for each class in a system. To find it, run regedit and look up the classid. You'll find it in HKEY_CLASSES_ROOT\CLSID; there will be a massive number of GUIDs. Look up the GUID for your object (in your case BEEECC20-4D5F-4F8B-BFDC-5D9B6FBDE09D) and open that node. Inside, you'll see a folder called InProcServer32 (if you're looking for a dll or ocx). Open that folder, and you'll see the location of the dll or ocx that the system is looking for when you instantiate the classid.

If you don't know the classid, you'll have to look for it with the progid first. The progid takes the form myComponentName.myClassName, and is also in the HKEY_CLASSES_ROOT hive (that's what Microsoft calls them; why they don't call them folders I don't really know). Find your progid, and in its folder you'll find a CLSID folder which has the classid in it. Use this to look up the InProcServer32 value in the CLSID folder.

HTH

Bob

p. s. The fact that there's only one location per classid per opsys instance is one of the chief sources of "DLL Hell." The .Net world allows multiple versions of a class to run on the same system, by including the location of any dlls used by a dll or exe in a "manifest" that is a part of the dll or exe file, rather than requiring a single location in the registry. (That is an oversimplification, for it is not always exactly true.

http://msdn.microsoft.com/library/d.../en-us/cpguide/html/cpconassemblymanifest.asp

contains a more complete explanation of manifests for those interested.)

 

[ddiamond]

Bob,

So that would explain why when I fixed the dll path in one project, it fixed it for all projects. We have already started moving our classic ASP apps to .NET, but based on what you said about dll hell, perhaps it makes sense to start migrating our VB 6.0 apps to .NET, although I have a feeling it will be more of a rewrite than a migration.

-Dan

 

[dilettante]

I think this sort of problem can be brought about by flaky installers, improper manual installation, erroneous or interrupted uninstalls and the like. Sometimes it can be the result of bad component versioning, but for the most part system DLLs have handled compatability well enough to keep people from ignoring the rules when installing new versions.

Sooner or later though some DLL/OCX pollution is bound to happen to you. The process is hardly foolproof as we've known for a long time.

You might want to read up on things like DLL/COM Redirection and Side By Side Components.

Implementing Side-by-Side Component Sharing in Applications (Expanded)

That article discusses why the registry is not the only way a COM class's location is determined. It also describes how to use this in your own applications and component libraries to avoid making a mess when you break compatability in new versions.

These options have been around for a while now. They aren't perfect, don't work in every case, and in some cases are specifically prohibited... but in the general case they offer you alternatives to DLL Hell.

The manifest isn't a .Net-only concept and the ideas were not new with .Net, but it does offer more benefits for .Net assemblies than for Win32 applications.

 

[ddiamond]

Thanks everyone for your advice.