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
LVL 3
onemorecokeAsked:
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.

Éric MoreauSenior .Net ConsultantCommented:
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!
0
onemorecokeAuthor Commented:
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
0
JR2003Commented:
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.
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Éric MoreauSenior .Net ConsultantCommented:
There are 2 kinds of DLLs
-those that needs to be registered that are compatible to the COM platform (like those of VB)
-those that are only good old dynamic link librairies that must be somewhere in your path (and that gives you a no-entry point error when you are trying to register them)
0

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
onemorecokeAuthor Commented:
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
0
Éric MoreauSenior .Net ConsultantCommented:
it is always a surprise what will be broken by new installations.

in general, latest versions of MS components are backward compatible.
0
rajaloysiousCommented:
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
0
dbrckoviCommented:
>> 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.
This is not true.
It will use them only if they are registered, but then all other applications will use them as well.

At the moment I can think of two possible sollutions:
1.) Modify your application so it can use both versions of dll's
2.) Use late binding and register your own dll before using it.
     Before exitting, re-register the original dll.

I'll post an example for second sollution:
 first create 2 simple dll's:
 - Start new ActiveX Dll project
 - change project name to TestDll
 - change class name to TestClass
 - paste this:
'-----------------------------------------------
Public Sub TestSub()
    MsgBox "First dll"
End Sub
'-----------------------------------------------
 - File -> Make:   C:\DllTest\FirstFile.dll

 - paste this:
'---------------------------------------------
Public Sub TestSub()
    MsgBox "Second dll"
End Sub
'----------------------------------------------
 - File -> Make:    C:\DllTest\SecondFile.dll


'************************************
 - start new Standard EXE
 - create three command buttons and paste this:
'--------------------------------------------------------
Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)

Private Sub Command1_Click()
    Shell "regsvr32 /s e:\dlltest\Firstfile.dll"
End Sub

Private Sub Command2_Click()
    Shell "regsvr32 /s e:\dlltest\Secondfile.dll"
End Sub

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

Private Sub Form_Load()
    Command1.Caption = "Register first"
    Command2.Caption = "Register second"
    Command3.Caption = "Use registered"
End Sub
'------------------------------------------------
0
dbrckoviCommented:
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.
0
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.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.