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?
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.