Should interop assemblies be signed?

Question

We have a set of COM components developed in VC++. When a reference to such component is added to a .NET project Visual Studio generates an interop assembly. We have a set of such assemblies now.

While running our daily build we sign all the produced binaries with a digital signature. Interop assemblies are not signed since we don't feel we are the authors - anyone can use Visual Studio and produce the same assemblies.

Should we sign the interop assemblies as well? Should we also sign them with a strong name (sn.exe utility)? What are the reasons to do so?

Answer 1

This has been a tricky balance for some time. The issue comes from the fact that you need to distribute your Interop assemblies with your code and you may be signing your own assemblies. If you sign your assembly then all the assemblies it references must also be signed - including the Interop assemblies. So you have to sign them.

If you are distributing a standalone application then there's no risk and you should just go ahead and sign the assemblies to make your life easier.

If you are distributing component libraries, things can be a bit trickier since another developer using your libraries might generate their own interop assemblies but sign them with their own keys. This causes all sorts of naming and dependency issues.

Depending on how complex your Interop assemblies are - you can generate the proxy code into a separate .CS/.VB file and compile it directly into your assembly. Then you won't have to worry about strong name issues.

Answer 2

We use Sn.exe to strong name our interop assemblies produced by the tools as wrappers around COM objects. We need to do this as the assemblies loading them are signed, hence they need to be signed.

To generate the interop assemblies we use:

tlbimp Some_COM.dll /delaysign /publickey:"Some_PublicKey.snk" /out:Some_COM2Lib.dll"

Obviously remove /delaysign if you are fully signing.

As for not authoring the assmeblies, this might be the case, but you are responsible for them. You want to ensure that they are not replaced (accidently or not) by anyone else, so you probably should apply the same level of signing/strong names as you apply to your other code.