Home All Groups Group Topic Archive Search About

very weird compilation issue.

Author
12 Oct 2005 2:26 PM
Stephanie
Some programmer here made some changes to some dlls (then went on vacation)!
Anyway, what I am seeing is very weird. I got all the code out of source
safe, and compiled a dll. Fine. I compiled a dll that the first dll
referenced. Fine. I went back into the first dll to compile again. I have
made no changes to either code. I get an error on Private Sub Test(byref
SomeVar as MyClass) where MyClass is a class within the current project. The
error is The binary compatibility dll or exe contains a parameter or return
type whose definition cannot be found.

I looked in the referenced dll. It has nothing by the same name as the
MyClass class that seems to be causing the error.

Now something I sometimes do when I have no idea what is going on is poke
the code and see what happends. I took MyClass and renamed it to MyClassTest
and replaced all code referencing MyClass. Compile then occured fine. I
changed it back, and it compiled fine. It is almost as if the vbp has lost
track of what classes are in it. But I opened the vbp in a text editor and I
can see them.

I am confused about how to understand the problem. Breaking binary
compatibility would be a total drag when I don't actually want to change
anything. Does anyone have any nudges for why VB cannot find the class
definition?

Thanks.

Author
12 Oct 2005 3:07 PM
Ken Halter
Show quote Hide quote
"Stephanie" <IwishICo***@NoWay.com> wrote in message
news:uU9lpjzzFHA.1032@TK2MSFTNGP12.phx.gbl...
> Some programmer here made some changes to some dlls (then went on
> vacation)! Anyway, what I am seeing is very weird. I got all the code out
> of source safe, and compiled a dll. Fine. I compiled a dll that the first
> dll referenced. Fine. I went back into the first dll to compile again. I
> have made no changes to either code. I get an error on Private Sub
> Test(byref SomeVar as MyClass) where MyClass is a class within the current
> project. The error is The binary compatibility dll or exe contains a
> parameter or return type whose definition cannot be found.
>
> I looked in the referenced dll. It has nothing by the same name as the
> MyClass class that seems to be causing the error.
>
> Now something I sometimes do when I have no idea what is going on is poke
> the code and see what happends. I took MyClass and renamed it to
> MyClassTest and replaced all code referencing MyClass. Compile then
> occured fine. I changed it back, and it compiled fine. It is almost as if
> the vbp has lost track of what classes are in it. But I opened the vbp in
> a text editor and I can see them.
>
> I am confused about how to understand the problem. Breaking binary
> compatibility would be a total drag when I don't actually want to change
> anything. Does anyone have any nudges for why VB cannot find the class
> definition?
>
> Thanks.

This type of thing can happen if your compatibility model is not maintained
properly...

Check the 'Now for some of the "Gotchya"s' section here....

Binary Compatibility
http://www.vbsight.com/BinaryComp.htm

Bottom line is.... VB "under the sheets" doesn't care about a class called
'MyClass'. It's looking for a class with a specific CLSID. My ComGuard tool
can compare 2 DLLs and show all differences. If the CLSID changed for any
class in the project, ComGuard will tell you. fwiw, the trial's fully
functional (for now <g>)

Now, there are other reasons you may get that "contains a parameter or
return type whose definition cannot be found" error. If your DLL has any
properties/methods/events that return a non-VB specific type (like an
instance of one of your classes or something your classes need, like a
Listview's ListItem, etc,) and that DLLs broken in some way, you'll get that
error. Start with the lowest level component in the chain and check all
references. Make sure the binary compatibility models for each component
contain >>all<< public interfaces (ComGuard'll help with that too)

'===reposted from earlier today...
When ever possible, build in reverse dependency order... if (EXEa needs
DLLb) and (DLLb needs DLLc) then build DLLc first, DLLb second and EXEa
last.
'===

--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm
Please keep all discussions in the groups..