7

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?

sharptooth
  • 167,383
  • 100
  • 513
  • 979

3 Answers3

7

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.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
2

To my knowledge, COM was not meant to prevent DLL hell, it was the pit of Hades itself. The term "DLL Hell" comes from the problem of multiple libraries each with same-named methods. The registration of COM assemblies in the system registry does not help with resolution at runtime.

Signing an assembly that is meant to act as a COM server ensures that the assembly doesn't collide with other COM-registered assemblies on the same computer. Without the signing, if two COM-registered assemblies had methods of the same name, it could cause problems.

Dave Swersky
  • 34,502
  • 9
  • 78
  • 118
1

Strong naming is mainly used to put the Dlls into the GAC. So you can have several versions of the Dll with the same name(!) safely on the same computer, which with regular COM-Dlls often produced issues. Not signing the Dlls removes the ability to GAC it. You don't have any immediate problems because of that but you don't use a useful feature, so you get a warning.

TToni
  • 9,145
  • 1
  • 28
  • 42