How to add reference so dll resides in system32

[mmarino]

This might be very simple, but I can't find an answer. I have a vb6 group project (.vbg) that contains 2 dlls and one executable. It all works fine until I want to install on a different machine. If I put all 3 files (dlls and exe) in the same directory (the App dir), it runs correctly. However, I'd like to put the dll files in the windows\system32\ directory and just have the executable in the App directory. When I do this, the executable won't run. Is there anything specific that I have to do? I've tried changing the references to point to my local system32 directory and compile the executable that way, but it makes no difference.
Thanks in advance,

Monica

 

[harebrain]

Have you registered the dlls?

 

[BobRodes]

No, Monica, I'm afraid it isn't very simple. Let's break it down. First, the reason that you have a vbg file is to be able to debug across intraprocess project boundaries without having two instances of the VB IDE running. It has NO (repeat NO) implications as regards compiled code. I believe you're having problems because you're not quite clear on this.

I assume that you're telling me that you have one Standard EXE project and two ActiveX DLL projects that are all contained in one group. I also assume that you have set your EXE project as the startup one. Given all that, to debug, open the EXE project (click on it in the project explorer window, and go into references. You should see your ActiveX DLL component names, and possibly twice (twice if you've already compiled the code). If you see one of them twice, you'll notice that you have one reference to a DLL file and one reference to a VBP (!) file. You'll want to select that one, since that is the uncompiled version so you can step through it.

Now, when you say "install on a different machine", I'm not clear whether you mean "deploy the compiled version" or "copy the source code to another machine and use the VB IDE there". I'm going to assume the latter. If you do this, you have to make sure that all the files are in exactly the same directory structure as the source machine, because VB can't see files in a new directory. The vbg file, for example, looks for each vbp file associated with it in the path that it was in when you saved the vbg file. So, the way to change this is to open, for example, the vbg file, manually add the missing projects in again, and resave the file.

If you're talking about deploying compiled code, say so and we can go over that a bit.

HTH

Bob

 

[BobRodes]

<If you're talking about deploying compiled code, say so and we can go over that a bit.

<Have you registered the dlls?

Starting with that.

 

[mmarino]

Thank you so much for your answers... Yes I mean deploying compiled code. I did register the dlls, or at least I thought they were getting registered (I'm using Wise Install). I will double check that the dlls are getting registered and will post back on monday.
Thanks a bunch

Monica

 

[mmarino]

Ok, I doubled checked, and I do have the files being registered by the install program. Anything else I should check?
Thanks for your help.

Monica

 

[BobRodes]

I would double check that the files can in fact be found where the registry says they're supposed to be. Run regedit, look in HKEY_CLASSES_ROOT for your component name. Look for one of your classes (you'll see componentname.classname). Open the folder, open the CLSID folder underneath. Now, you'll see a GUID in the top right window. Keeping that GUID visible, scroll the left window to the CLSID folder under HKEY_CLASSES_ROOT. This is a (huge) list of all classids registered in the system. Open the folder, scroll to the clsid (folder) that you have showing in the top right. Open that folder. You'll see a folder called InProcSvr32. Open that, and on the right you will see the dll file that gets opened when someone instantiates a member of that class. Check whether that file is in fact the one you're trying to instantiate, both location on the disk and the version.

HTH

Bob

 

[SBerthold]

>Ok, I doubled checked, and I do have the files being registered by the install program

You need to tell the installation program to install these files in the \System32 directory, and then they should get registered there. It looks like as you have the installer putting thoses files into the App folder, and therefore the installer is registering them there. If you are then manually moving the files to \System32, then first unregister them from the App folder, then copy and register them in the System32 folder.

 

[mmarino]

Thank you for all your answers. My problem was that my program expects an ini file in the App directory, but when it doesn't find it, it tries to create one by calling functions in the dlls, so it's somehow expecting them to be in the App directory. So I'm going to have to keep them there to get the other functionality to work correctly.
Thanks a lot for all your help.

Monica