Welcome to dll's hell...
I am sorry for you because I have been there.

Something that can break compatibility is when the dll (or the 
ActiveX component in general) is not built using the right version.
Let's suppose you create a component A.dll, you add it to SourceSafe
and other people start using and/or working on it.
Now you add a new property/method and you rebuild the component
*without* checking the binary it in or distribute it to your
collegues.
Next time one of your collegues or the build process will create another
A.dll will use the 'old' one for binary compatibility instead of
the new one, so in your machine the dll wil have a different version.
Worse than that, next time the dll will be built will still use an old
version, and from now then all the dll's will have a different 
interface!

Another possibility is when you use for binary compatibility a
file that is different from the target. In this case, every time
you know that you changed the interface you have to remember to
copy the target into the binary used for compatibility, otherwise
you end up with a different version every time.

Bottom line: every time a dll is changed, it must be sure that
evereyone else (you included) will use the new interface for binary
compatibility.

Fixing a dll's hell is not easy. First, I unregister all components
from my machine, delete them from the disk and check the registry
that all references have been deleted, and run RegClean. Then I 
copy the 'official' dll (in my case from sourcesafe) on my computer
and register it. At this point I rebuild it, and check it in again,
so I am sure that sourceSafa and I have the same interface.
At this point (and this is very important if you work in a team) 
I notified all my collegues to get the latest, because if they
build their own they wil use an old (and wrong) interface for
binary compatibility. It is very useful to add the dll itself to
the VB project as a 'related document', so when you check it out
because you have to build it SourceSafe will automatically get
the latest for you.
 
Sorry if this seems confusing. MS gave to VB developers the 
possibility to maintain binary compatibility and this is great.
Unfortunatelly the method is not bullet proof...

Marco

> I have a vb dll which maintains the version/binary compatiblity, But 
still 
w> hen i recompiled the dll(with new methods added) i get and 
error "ActiveX 
c> omponent can't create object". 

> When I opened the IDL of both old and the new guy I found difference in 
t> he id of a public variable 

> old :--
[> id(0x400300d3), propget]
H> RESULT Path([out, retval] BSTR* Path);
[> id(0x400300d3), propput]
H> RESULT Path([in] BSTR Path);

> new :--
[> id(0x400300d5), propget]
H> RESULT Path([out, retval] BSTR* Path);
[> id(0x400300d5), propput]
H> RESULT Path([in] BSTR Path);

> and the declaration of path is 
p> ublic path as string in both the versions

> Any body has an idea why this is happening ??

> Pls let me know. mail me at vasav@d...