Question

We have a .NET exe (.NET 3.5, VS 2010 SP1, VB.NET) project that is COM visible. A VB6 application uses CreateObject to create an object from this assembly.
This works without any problem if we do not sign the assembly. If we sign the assembly (with a pfx-certificate), CreateObject fails with the message

Can't create Object "Our.ClassName"

Unfortunately, there is no entry in the event log. The .NET exe can be started without any problem so all dependencies should be in place. We've also enabled .NET binding logging, but it does not write anything when CreateObject is called (so we suspect that the creation fails before the assembly is loaded).
We've tracked down all changes, the only difference that matters is whether the assembly is signed or not. Also we've tried different certificates, but the behavior doesn't change.

Has anyone experienced this behavior before and can provide a solution? Are there any ways that can give us more information about the failure?

Was it helpful?

Solution 2

Another close look into the registry revealed, that the reason was a change in the version number of the assembly. Some time ago, version 3.0.0.0 was registered - obviously in a version without a strong name. After some changes in the build process, the version was reset to 1.0.0.0.

REGASM registered version 1.0.0.0 in the registry, but (of course) failed to remove version 3.0.0.0 under the key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\{00000000-0000-0000-0000-000000000000}\InprocServer32 in the registry when we tried to re-register the assembly.

CreateObject uses the highest version when resolving the assembly and thus acquired the assembly reference without a strong name. This reference was bound to the assembly with version 1.0.0.0 (as it was not strong named, the difference in version was not respected) so that it worked correctly for a assembly without a strong name.
We will reset the version to its old value in order to maintain consistency.

OTHER TIPS

Strong naming an assembly changes its PublicKeyToken. Which is part of the assembly's fully qualified name, it is recorded in the registry when the assembly is registered. As an example, run Regedit.exe and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\{00000100-0000-0010-8000-00AA006D2EA4}\InprocServer32, Assembly value. You'll see:

dao, Version=10.0.4504.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

So registering the assembly again after you sign it is a hard requirement. Run Regasm.exe again.

And don't forget that, if you don't use the /codebase option, then you have to put the assembly in the GAC. Which is the usual reason to give the assembly a strong name in the first place.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top