sanfordm
asked on
Using a VB dll in a VB project on another machine
I have a set of dll files developed on one machine. I copied them to the target machine and register them and can then run an executable that references them without any problems. However, running the application through the visual basic IDE which references the same dlls does not run correctly. I get the error object does not support property or method. I have no idea why this is happening. Any suggestions?
You probably have to deselect the reference in the project references, then re-browse for it by selecting the browse button (to the right) and re-find it and select OK. It should resync with the newer version.
welcome to what is known as 'DLL Hell'. When you created the DLL, did you set Binary Compatability ON?
When a DLL is created, VB generates a 'signature' for the DLL, which is the GUID that is actually stored in the registry when the DLL is registered. If NO compatability is set, then EVERY TIME a New version of the DLL is BUilt, that GIUD is completely DIFFERENT, which means that what is in the registry DOES NOT correspond what is in the DLL, and the code "can't find" the DLL.
If Project Compatability is set on, then the GUID is only changed if the "INTERFACE" supported by the DLL changes - the INTERFACE being the PUBLIC exposed sigantures of all of the classes and methods exposed by the DLL - the signature of a class being the EXACT list of Methods and properties). But if the signature of ANYTHING in the DLL changes, then a NEW GUID is generated, and once again, the code "can't find" the DLL.
With Binary Compatability set ON, you provide a REFERENCE DLL, which the current version MUST ABSOLUTELY MATCH, or else an error message is generated when you attempt to BUILD a new version of the DLL, to the effect that the New code DIFFERS from the OLD code. If THAT error does NOT occur, then the NEW DLL is built using the EXISTING GUID, and the running code CAN find the New version of the DLL.
Basically, BINARY Compatability enforces an IMPLIED contract between the DLL and the users of the DLL, which says that the DLL and ALL of its components, will ALWAYS APPEAR the same from the outside (this does not mean that you can't change HOW something is done inside a class, just how the class presents itself to the outside world).
AW
When a DLL is created, VB generates a 'signature' for the DLL, which is the GUID that is actually stored in the registry when the DLL is registered. If NO compatability is set, then EVERY TIME a New version of the DLL is BUilt, that GIUD is completely DIFFERENT, which means that what is in the registry DOES NOT correspond what is in the DLL, and the code "can't find" the DLL.
If Project Compatability is set on, then the GUID is only changed if the "INTERFACE" supported by the DLL changes - the INTERFACE being the PUBLIC exposed sigantures of all of the classes and methods exposed by the DLL - the signature of a class being the EXACT list of Methods and properties). But if the signature of ANYTHING in the DLL changes, then a NEW GUID is generated, and once again, the code "can't find" the DLL.
With Binary Compatability set ON, you provide a REFERENCE DLL, which the current version MUST ABSOLUTELY MATCH, or else an error message is generated when you attempt to BUILD a new version of the DLL, to the effect that the New code DIFFERS from the OLD code. If THAT error does NOT occur, then the NEW DLL is built using the EXISTING GUID, and the running code CAN find the New version of the DLL.
Basically, BINARY Compatability enforces an IMPLIED contract between the DLL and the users of the DLL, which says that the DLL and ALL of its components, will ALWAYS APPEAR the same from the outside (this does not mean that you can't change HOW something is done inside a class, just how the class presents itself to the outside world).
AW
You may have a reference that is not to the same version on both computer.
ASKER
I know about binary compatability, but at this point I only have one version of the dll. I have never recompiled at all!
and the DLL was successfully installed on the other PC, and then the necessary reference added to the the Project on the other PC?
AW
AW
ASKER
AW
Yes, I can run the executable that was created on the source PC just fine, I only have the problem withing VB.
Yes, I can run the executable that was created on the source PC just fine, I only have the problem withing VB.
do you know exactly on which line the error occurs?
ASKER
I tracked it down. Ready for this, The line that fails is
TempString = "True"
This line is inside of a sub
and the declare for TempStrig is also in that sub, which is simply.
Dim TempString As String
TempString = "True"
This line is inside of a sub
and the declare for TempStrig is also in that sub, which is simply.
Dim TempString As String
You have a BIG problem!
When you look at the references, do you have any marked as *MISSING* ?
When you look at the references, do you have any marked as *MISSING* ?
ASKER
Sorry, that was not it. The code that actual fails is this.
Private Sub Evaluate_Indicator(tempCon
If TypeOf tempControl Is SSCommand Then
tempControl.BackColor = &HFFFF&
Exit Sub
Else
BKColor = tempControl.LightOnColor 'This line fails
End If
For some reason it doesn't recognize the tempControl to be a SSCommand button and it goes to the else part and then gives the error because an SSCommand doesn't have a LightOnColor property.
I was able to process the tag, so I know that I have the proper control which is an SSCommand.
But again, why would the exe work and not VB, so I am not so sure that the code is the problem.
Private Sub Evaluate_Indicator(tempCon
If TypeOf tempControl Is SSCommand Then
tempControl.BackColor = &HFFFF&
Exit Sub
Else
BKColor = tempControl.LightOnColor 'This line fails
End If
For some reason it doesn't recognize the tempControl to be a SSCommand button and it goes to the else part and then gives the error because an SSCommand doesn't have a LightOnColor property.
I was able to process the tag, so I know that I have the proper control which is an SSCommand.
But again, why would the exe work and not VB, so I am not so sure that the code is the problem.
What does TempControl contains when it crash?
You may use this:
Else
On error Resume Next
BKColor = tempControl.LightOnColor 'This line fails
End If
You may use this:
Else
On error Resume Next
BKColor = tempControl.LightOnColor 'This line fails
End If
ASKER
I did a typeName on the TempControl and it returned "SSCommand". So that is really weird that the typeof check failed. I also checked to make sure that the SSCommand control was the same on both machines (and it is). SSCommand is a third part push button.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
What if you want to use your code in an another application and do not distribute this component?
ASKER
Yea, thats what I did (switch to typename). I have another wierd one too. I image its a very similar problem. I'll have to check. Thanks.
That component is always distributed with out apps (it is always used).
That component is always distributed with out apps (it is always used).
ASKER
Thanks for working through it with me!
so is this question over?
ASKER
Yea, unless you know why typeof didn't work. Its solved now that I am using typename. I gave you the points. If the other problem is different, I may start a new question.
Thanks again
Thanks again