.net - Should interop assemblies be signed? -
We have a set of COM components developed in VC ++ when a reference to such component is added to a .NET project , Then the Visual Studio Interp assembly creates. We have a set of such assemblies.
While running our daily construction, we sign all produced binarys with a digital signature. The Interp assembly is not signed because we do not think we are writers - any viewer can use the studio and produce the same assembly.
Should we also sign interop assemblies? Should we also sign them with a strong name (sn.exe utility)? What are the reasons for doing this?
This has been a difficult balance for some time. This issue comes from the fact that you need to distribute your interop assembly with your code and you can sign your own assemblies. If you sign your assembly, the references to all denominations should also be signed - including the interop assembly. So you have to sign them.
If you are distributing a standalone application then there is no danger and you should sign the assemblies to move forward and make your life easier.
If you are distributing component libraries, things can be a bit complicated because another developer can create your own interop assembly using your library, but you can sign them with your key. It causes all kinds of issues of nomenclature and dependence.
Depending on how complex your interop assembly is - you can generate the proxy code in a separate .cs / .vb file and can be compiled directly into your assembly. Then you will not have to worry about issues of strong names.
Comments
Post a Comment