?
Solved

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

Posted on 2004-11-09
9
Medium Priority
?
239 Views
Last Modified: 2013-12-25
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
0
Comment
Question by:onemorecoke
  • 3
  • 2
  • 2
  • +2
9 Comments
 
LVL 70

Expert Comment

by:Éric Moreau
ID: 12540185
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
 
LVL 3

Author Comment

by:onemorecoke
ID: 12540281
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
 
LVL 18

Expert Comment

by:JR2003
ID: 12540348
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
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
LVL 70

Accepted Solution

by:
Éric Moreau earned 600 total points
ID: 12540562
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
 
LVL 3

Author Comment

by:onemorecoke
ID: 12541072
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
 
LVL 70

Expert Comment

by:Éric Moreau
ID: 12541160
it is always a surprise what will be broken by new installations.

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

Expert Comment

by:rajaloysious
ID: 12543001
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
 
LVL 11

Assisted Solution

by:dbrckovi
dbrckovi earned 150 total points
ID: 12543028
>> 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
 
LVL 11

Expert Comment

by:dbrckovi
ID: 12543077
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

Featured Post

New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

If you have ever used Microsoft Word then you know that it has a good spell checker and it may have occurred to you that the ability to check spelling might be a nice piece of functionality to add to certain applications of yours. Well the code that…
Most everyone who has done any programming in VB6 knows that you can do something in code like Debug.Print MyVar and that when the program runs from the IDE, the value of MyVar will be displayed in the Immediate Window. Less well known is Debug.Asse…
Get people started with the process of using Access VBA to control Excel using automation, Microsoft Access can control other applications. An example is the ability to programmatically talk to Excel. Using automation, an Access application can laun…
This lesson covers basic error handling code in Microsoft Excel using VBA. This is the first lesson in a 3-part series that uses code to loop through an Excel spreadsheet in VBA and then fix errors, taking advantage of error handling code. This l…
Suggested Courses

839 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question