DLL Path Problem in Visual Basic

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 ?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jorge PaulinoIT Pro/DeveloperCommented:
>> 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.
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...
rajesh_khaterAuthor 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.
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.


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!


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
rajesh_khaterAuthor 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.!
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.


I use it all the time, and it is by far my fave!
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.
you mean, make them not be dlls?

Yeah, I suppose that is a fair suggestion.

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.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.