Should interop assemblies be signed?

让人想犯罪 __ 提交于 2019-12-01 16:04:24

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.

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.

Replace "publickey" by "keyfile":

tlbimp Some_COM.dll /delaysign /keyfile:"Some_PublicKey.snk" /out:Some_COM2Lib.dll"
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!