I have developed a .NET DLL for another team who will be deploying it with
their VB6 application. This DLL must also work with .NET applications in the
near future. This team has been able to succesfully integrate my .NET DLL
with their VB6 application, but it appears that each time I give them a new
build of this DLL, they must un-register the old version, and re-register the
new version. If they don't, they get this message when starting their
application:
"The located assembly's manifest definition with the name 'BlocktimeCalc'
does not match the assembly reference."
This team is deploying the application by creating an MSI package which is
executed from a software depot that temporarily elevates the user permissions
during installation. However, after the initial installation this team wants
to deploy application updates via a custom update scheme that does not
accomodate un-registering and re-registering my DLL, and does not elevate
permissions that would allow modification of the registry.
Is there some tweak to my project that I can do that will eliminate the need
to un-register and re-register each new build?
Currently this DLL has a SNK, and is deployed in the application's directory.
Eckhard Schwabe - 01 Sep 2005 17:45 GMT
Hello Terry,
> I have developed a .NET DLL for another team who will be deploying it with
> their VB6 application. This DLL must also work with .NET applications in the
[quoted text clipped - 6 lines]
> "The located assembly's manifest definition with the name 'BlocktimeCalc'
> does not match the assembly reference."
I don't know this error message, but if you are using the
[ClassInterface(ClassInterfaceType.AutoDual)] Attribute,
every time you rebuild your .Net dll a new GUID will be created for the
COM classes and interfaces, meaning that clients with early binding will
not be able to find the class.
Did you follow the recommendations under "Introducing the Class
Interface" in the SDK ?
Regards,
Eckhard
Phil Wilson - 01 Sep 2005 23:34 GMT
A common issue is to have AssemblyVersion 1.0.* in the AssemblyInfo file, so
each build gets a new version, and the early binders that are expecting some
other version won't find the new one.

Signature
Phil Wilson [MVP Windows Installer]
----
> Hello Terry,
>
[quoted text clipped - 20 lines]
>
> Eckhard
Matt Adamson - 02 Sep 2005 16:13 GMT
This is a classic error when the referenced assemblies are the wrong
version.
Review the documentation on the assembly binding log viewer to determine
which assembly is being probed for.
>A common issue is to have AssemblyVersion 1.0.* in the AssemblyInfo file,
>so each build gets a new version, and the early binders that are expecting
[quoted text clipped - 23 lines]
>>
>> Eckhard