我们在VC ++中开发了一组COM组件。将此类组件的引用添加到.NET项目时，Visual Studio将生成一个互操作程序集。我们现在有一套这样的组件。
在运行我们的每日构建时，我们使用数字签名对所有生成的二进制文件进行签名。 Interop程序集未签名，因为我们认为我们不是作者 - 任何人都可以使用Visual Studio并生成相同的程序集。
我们是否应该签署互操作程序集？我们是否应该使用强名称（sn.exe实用程序）对其进行签名？这样做的原因是什么？
答案 0 :(得分：8)
一段时间以来，这一直是一个棘手的平衡。问题来自于您需要使用代码和分发Interop程序集，您可能正在签署自己的程序集。如果您对程序集进行签名，则它所引用的所有程序集也必须进行签名 - 包括Interop程序集。所以你必须签名。
如果您要分发一个独立的应用程序，那么就没有风险，您应该继续签署程序集以使您的生活更轻松。
如果要分发组件库，事情可能会有点棘手，因为使用您的库的其他开发人员可能会生成自己的互操作程序集，但使用自己的密钥对其进行签名。这会导致各种命名和依赖性问题。
根据Interop程序集的复杂程度 - 您可以将代理代码生成到单独的.CS / .VB文件中，并将其直接编译到程序集中。那么您就不必担心强名称问题了。
答案 1 :(得分：3)
我们使用Sn.exe强制命名工具生成的互操作程序集作为COM对象的包装。我们需要这样做，因为加载它们的程序集是签名的，因此需要签名。
要生成我们使用的互操作程序集：
tlbimp Some_COM.dll /delaysign /publickey:"Some_PublicKey.snk" /out:Some_COM2Lib.dll"
如果你完全签名，显然会删除/ delayign。
至于没有创作这些混淆，可能就是这种情况，但你要对它们负责。您希望确保其他人不会替换（无意或无意），因此您可能应用与您的其他代码相同级别的签名/强名称。
答案 2 :(得分：0)
将“keykey”替换为“keyfile”：
tlbimp Some_COM.dll /delaysign /keyfile:"Some_PublicKey.snk" /out:Some_COM2Lib.dll"