DLL Hell

[Gary Dunne]

I have a versioning problem with a .Net component.

The component (COM DLL) was originally compiled to version 1.0.x.x . The
application that calls this component is a VB 6 Exe.

Having recompiled the component to version 1.3.x.x (no code changes just
getting the version numbers to conform to company policy), uninstalled the
original version from a second dev machine and installed the new version,
the application now refuses to create an object from the DLL (Cannot create
Active X object....).

I've run regclean on the machine, installed the component via it's own
installer (originally to a C:\Program Files\Subdir.. directory and later to
the System32 dir), ensured all previous version were removed etc .... But
I'm still in the DLL Hell that .Net was supposed to eradicate.

I've added a reference to the component in a new project in VB 6.... tried
to create an object from the library and got the same result.
Checked the Assembly permissions etc (set to Unrestricted).... and now I'm
starting to have a nervous breakdown !!!!! :-|

Anyone got any hints ?

Thanks

Gary

 

[Ken Halter]

I have a versioning problem with a .Net component.

The component (COM DLL) was originally compiled to version 1.0.x.x . The
application that calls this component is a VB 6 Exe.

Are you using Binary Compatibility for that VB6 component (if the COM dll
you're talking about is a VB6 component, that is)? If not, all interface IDs
change each time you compile and any apps that require the component will
need to be recompiled. It doesn't matter if any code was changed. All that
matters is that you didn't tell VB to retain the original IIDs.

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

DLL Hell's generally caused by invalid registry entries due to subtle
compatibility "goofs".... like forgetting to update the Compatibility Model
after adding a new public interface.

 

[Gary Dunne]

The DLL was written in VB .Net and compiled as a COM component. Therefore
the only way that the IDs could change would be if I had changed them
manually ? The application that calls the DLL was written in VB6.

The effect is basically that the DLL works only on the machine that it was
compiled on. I have even tried installing the DLL on a second machine and
calling it from within the VB6 IDE. Same result.......

 

[Phill. W]

I have a versioning problem with a .Net component.

That's unusual.

The component (COM DLL) was originally compiled to
version 1.0.x.x .

OK, the "x.x" bit worries me, but I'll /assume/ these represent
some /fixed/ values ...

The application that calls this component is a VB 6 Exe.

Now; are you getting hold of this object using

Dim x as Project.Classname
Set x = New Project.Classname

or

Dim x as Object
Set x = CreateObject( "Project.Classname" )

?

Having recompiled the component to version 1.3.x.x (no code
changes just getting the version numbers to conform to company
policy)

And how did you manage that? VB "Proper" assigns the
Interface (version) numbers internally - you'd /have/ to make a
code change to get a new "version".

*Or*, have we now made the leap away from a [VB6] COM
DLL and we're talking about a .Net Assembly that wraps around
one?

, uninstalled the original version from a second dev machine and
installed the new version, the application now refuses to create
an object from the DLL (Cannot create Active X object....).

COM Reply : Which makes me think you're using Early Binding,
which relies on a [Interface] GUID in the Registry to identify the
required DLL.
This would have been the one from the 1.1 DLL, which you have
now eradicated, replacing it by a totally different one for the 1.3
DLL. Your Early bound client applications will remain "broken"
until they are recompiled against the new, 1.3 DLL.

..NET reply : Assembly versions "1.1.x.y" and "1.3.x.y" are totally
different enties and an application built to run against one [usually]
won't even acknowledge the existence of the other (I should point
I'm used to loading Assemblies into the Global Assembly Cache;
XCopy deployment may work differently).

I'm still in the DLL Hell that .Net was supposed to eradicate.

I've added a reference to the component in a new project in
VB 6.... tried to create an object from the library and got the
same result.

Which is 'InterOp'ing the "other" way around, calling a .Net
Assembly from VB6. In that caase, have you ticked the .Net
assembly option to "Register it for COM InterOp"?
Without this, COM will never see your ("new") assembly.

HTH,
Phill W.

 

[Mac]

I don't have solution to ur problem but seems like u do have solution
to my problem. I m trying to get the version number of a dll (Compiled
using VB 6.0) and then compare it with the version number of another
DLL(this also compiled using VB 6.0) and then based on the result do
some stuff. I donno how to get the Version number of the DLL, can u
help me with that?
Thanks

 

[Herfried K. Wagner [MVP]]

I donno how to get the Version number of the DLL

Take a look at the 'FileVersionInfo' class.