Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

DLL Hell?? 2

Status
Not open for further replies.

stnkyminky

Programmer
Oct 15, 2001
476
US
I'm using a dll called datatieraccess.dll. This dll is currently used by two apps. I just installed the second app on the client pc and was confronted by an automation error.
In order to make app 1 work I regsvr the dll and voila...app 1 works, but app 2 doesn't. Vice versa to get app 2 to work.

The dlls are stored in their respective application folders and not system32. I'm using binary compatability against the existing dll when re-compiling the dll.

How do I correct this problem? Scott
Programmer Analyst
<{{><
 
When you built the deployment for either app did you mark your dll as shared?
 
have you tried CreateObject? Rather then referencing them directly?
 
stnkyminky -

Welcome to DLL hell.

I know you said you have binary compatability turned on, but if you ever got a &quot;binary compatability will be broken&quot; message when compiling, that's VB telling you that you changed something in the interface, and that existing programs that make use of the DLL/OCX/whatever will no longer run.

Since it sounds like compatability is already broken, it might be too late, unless you have excellent source code control procedures and can roll back any changes, and then re-apply them to find out where the problem occurred. Otherwise, you'll need to recompile both apps against the latest version of the DLL and re-ship them.

The reason why it's broken, even though the DLL is stored in separate directories, is that when locating a COM DLL, Windows uses the Registry, and not the directory path. Whenever you register your DLL, it points the Registry to that copy, and both apps will then use it and ignore the other one.

Chip H.
 
chiph...

So one app was compiled with one version of the dll and the second app with another version. All makes sense now.

The only time compatability will be broken is if a new function/sub is add/removed or parameters have changed? Scott
Programmer Analyst
<{{><
 

Only if previously defined functions/methods/public properties have changed in name/arguments/return value.

No problem to add new ones.

=======================================================
Old Dll:
Public Sub myMethod(FirstArg As String, SecondArg As Long)

End Sub

New Dll:
Public Sub myMethod(FirstArg As String, SecondArg As Long, ThirdArg As Integer)

End Sub
=======================================================

One way you could make a change is as follows:

New Dll:
Options Explicit
Private myMethod2_ThirdArg As Integer
Public Sub myMethod2(FirstArg As String, SecondArg As Long, ThirdArg As Integer)

myMethod2_ThirdArg = ThirdArg
Call myMethod(FirstArg, SecondArg)
End Sub

Change the original proceedure:
Public Sub myMethod(FirstArg As String, SecondArg As Long)
If myMethod2_ThirdArg <> 0 Then
'Called from myMethod2 - new version
Else
'Old Version - set a default
myMethod2_ThirdArg = 1
End If
End Sub

Then, if things get to complicated, you may want to use only a completely new method with-out calling the original method.







[/b][/i][/u][sub]*******************************************************
General remarks:
If this post contains any suggestions for the use or distribution of code, components or files of any sort, it is still your responsibility to assure that you have the proper license and distribution rights to do so!
 

>Only if previously defined functions/methods/public properties have changed in name/arguments/return value.

That is:

Proceedure name
Argument variable names or types
Return variable type
[/b][/i][/u][sub]*******************************************************
General remarks:
If this post contains any suggestions for the use or distribution of code, components or files of any sort, it is still your responsibility to assure that you have the proper license and distribution rights to do so!
 
ok...Assuming I'm not confronted with a break compatability box. I can unregister the old dll and then register the new dll on the client without problems. Scott
Programmer Analyst
<{{><
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top