We help IT Professionals succeed at work.

DLL Path Problem in Visual Basic

rajesh_khater
on
My VB project uses a few custom DLLs which are in a project subdirectory.

When I prepare a Setup and install the program in the same machine in a different folder, the Setup program copies the DLLs into the Windows system32 directory.

After that, if I open my VB project and go to Project->References, I find that all DLLs path point to the system32 directory, not the project subdirectory. Then I have to manually re-register the DLLs giving the path of the subdirectory.

Is there a way I can install and test my program on the same machine without changing the DLL paths in my project ?
Comment
Watch Question

Jorge PaulinoIT Pro/Developer
BRONZE EXPERT
Top Expert 2008

Commented:
>> When I prepare a Setup and install the program in the same machine in a different folder, the Setup program copies the DLLs into the Windows system32 directory.

But you can select, when you create your setup projetc, the target of all the files. You can choose for the dll's to saty in the same dir of the exe file.

Commented:
I think that the dlls need to be in the same directory as the exe to use them as a side-by-side implementation.  The references I do not think would change, but the executable would look for a local copy, before finding a globaly registered version.

It does also depend on your service pack for VB...
http://support.microsoft.com/kb/828629

Author

Commented:
Even if I choose the DLLs to stay in the same folder as the one where the application is installed, still since the DLL gets registered with the new path, so my VB project also starts pointing to that path !!

I have VB SP 6.
Commented:
Hi.

It depends on the nature of the dll. If it's just a regular DLL (those you create with C, C++, PowerBasic or whatever), then the EXE will generally try to find them in the same folder it is installed.

Since you mention you have to set up references from VB  pointing to your dlls, they are COM dlls, which are different from regular dlls.

When looking for a COM dll, the EXE asks the system where to find it by letting Windows know the COM Dll ID. The OS then checks the registry to find the same ID, and points to the folder where the DLL was last registered. That is, by default, the \system32 folder (in NT+) or the \system folder (w9x/ME).

As jpaulino says, you can define the target for DLL install from within the setup builder. Keep in mind, however, that if you are going to redistribute your app then you should place COM Dlls in the {winsys} folder, because if a file already exists there, the OS will keep the most up-to-date version installed. Important dlls are there that are usually used by many applications; and you don't want to make the system point to an older version of the dll, which may crash previously installed apps.

I can recommend a setup builder (Inno setup) which makes it easy to control things such as version management and such. Just google for it.

Well, I hope that helps.

Greetings from Argentina!

Pablo.

Author

Commented:
Thanks for explaining about COM Dlls. But the question remains unsolved. What can I do so that the DLL path does not change in the VB project ??

Since these are COM Dlls, even VB project asks the system about the DLL path by giving the DLL id, and so it starts pointing to the last regstered path.

And during installation on the same machine, the last registered path changes.!
Commented:
The installer is I am assuming registering the DLLs where ever it installs them to.

I would agree with purquiz and use innoSetup, it is free very versatile and provides much more flexability than most installers I have used.  It also does not "brand" the installer, which I always looks more professional.

http://www.jrsoftware.org/isinfo.php

I use it all the time, and it is by far my fave!

Commented:
Another solution (if you have the source code of the dlls) is to include their classes into the app itself, thus avoiding the need to register them as COM providers.

Commented:
you mean, make them not be dlls?

Yeah, I suppose that is a fair suggestion.

Commented:
I have the answer...

The exe will always use the Registered version by default.  On Windows XP and above side-by-side installation is supported by using a manifest file.

http://msdn2.microsoft.com/en-us/library/ms761394.aspx

Explore More ContentExplore courses, solutions, and other research materials related to this topic.