asked on

DLL Hell - When you register a file, will other programs use the new registration

Experts,

I am in a position where other programs are stopping my program from working because of common support DLLs not being the same.

I am told that if I put the DLLs/OCXs in my application folder, the program will use those instead of the ones in the windows/system folder. But if an OCX is registered, isn't the reference in the registry always going to point to the support file that is in my application folder? Wouldn't that mean that other applications would be using the OCXs in my application folder instead of the one that other program put into the windows/system folder? And then the minute they reinstall their other program wont it change the registry again? Maybe if the file is in the same folder as the exe, it does not even look at the registry?

Any thoughts?

Thanks

onemorecoke

Éric Moreau

DLLs written with VB needs to be registered just like OCXs. That means that simply putting them into the same folder as your application won't be enough!

onemorecoke

ASKER

If the DLLs are from C++, then you don't need to register them, it will just use the serach pattern, correct? I have heard it both ways too, that the program first seaching in the application folder first, then the windows system folder. And then I hear the other way of the windows/system folder first, then the application. Which way it is? Is it the difference between the WIN98 and WINNT environments? And since all OCX's need to be registered, this seaching pattern will not matter anyway, correct?

Thanks

onemorecoke

JR2003

If the OCXs and DLLs have different GUIDs to the ones in windows\system32 then the VB program will pick the one up with the GUID that was set in the references.

ASKER CERTIFIED SOLUTION

Éric Moreau

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

onemorecoke

ASKER

Emoreau,

So probably the only time putting DLLs into your application folder is when the are the old DLLs, which is only part of the time, and putting the DLLs in the application folder only solves things some of the time. Sounds like there is no iron clad solution except to solve things as they come up. Do you know of any books or really good articles on making "bullet-proof" installations when you are dealing with third party activex control and database components like MDAC and Jet?

Thanks for you response.

onemorecoke

Éric Moreau

it is always a surprise what will be broken by new installations.

in general, latest versions of MS components are backward compatible.

rajaloysious

The path doesnt matter for a COM Dll.
If you enforce Binary Compatability (Project-Properties dialog)
then the last one which was registered will be used by every one.

If you do not maintain Binary Compatibility (No Compatibility), then every build will have a different guid and
the programs will use the dll which compiled with it.

Use Binary Compatibility and there should be no issues - Every program will use the latest dll
Cheers

SOLUTION

dbrckovi

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

dbrckovi

If you put this in form's load event, you can use your dll for your application, and let other programs use their other dll.
'-----------------------------------------------------
Private Sub Form_Load()
Shell "regsvr32 /s e:\dlltest\Firstfile.dll" 'register first dll

Dim A As Object 'create dummy object so app remembers the reference
Set A = CreateObject("TestDll.TestClass")
Set A = Nothing

Shell "regsvr32 /s e:\dlltest\Secondfile.dll" 'register second dll for other apps to use
End Sub

Private Sub Command2_Click()
Dim A As Object
Set A = CreateObject("TestDll.TestClass")
Call A.TestSub
Set A = Nothing
End Sub
'-----------------------------------------------------

Note that after you register first dll, dummy object is created.
It is important becouse application remembers the library of the first object, and all other objects in this application are created from that first file.
After that you can register and re-register dll's as much as you want, app will continue to use classes from first dll.

If you wouldn't create dummy object, all other objects of would be created from second dll.