.netcomassembliesregasmsnk

Why exactly does regasm warn me about signing with a strong name?


If I want to make a .NET assembly usable as a COM server I have to add a set of attributes and then use regasm to register it as a COM server.

If the assembly is not signed with a strong name regasm when run with /codebase key shows a RA0000 warning saying that the assembly could interfere with other assemblies on the same computer and I should sign it with a strong name, but registration succeeds and it even works just fine.

AFAIK strong names are intended to prevent so-called DLL hell. But COM was also meant to prevent DLL hell. If I change any interface exposed to COM I must either change the GUID or at least maintain binary compatibility. So signing with a strong name doesn't seem to add anything useful - nothing prevents me from breaking COM interfaces, then signing with the same keypair and having full-blown DLL hell.

What's the use of signing with as strong name in case of COM-exposed .NET assemblies?


Solution

  • It is a clumsy warning. There are two aspects to COM DLL Hell. The really bad one is modifying the public interfaces and not assigning new GUIDs. A client app that wasn't recompiled tends to crash and burn when it calls an entirely wrong method or bombs with a nasty AccessViolationException that gives no clue at all what the cause might be.

    The second one is doing everything right (assigning new GUIDs) but then overwriting the existing DLL with the new version. You'll still crash that stale client app but more mildly with an E_NOINTERFACE hresult that generates a pretty specific exception that helps you diagnose the cause. The user isn't any happier though.

    That scenario has a ready solution in .NET, the GAC supports side-by-side deployment of assemblies with different version numbers so that both the old and the new version can co-exist and the stale client app continues to be happy with the old version. Which requires a strong name. Yes, that warning could certainly have been suppressed when you use /codebase since that makes it quite clear you are not going to use the GAC. Although it doesn't hurt to tweak your nose a bit at using /codebase. Also, you never use the GAC on your dev machine while testing but certainly should consider it when deploying.