如果我想让 .NET 程序集可用作 COM 服务器，我必须添加一组属性，然后使用regasm它来将其注册为 COM 服务器。
如果程序集regasm在使用密钥运行时未使用强名称签名，则会/codebase显示RA0000警告，指出该程序集可能会干扰同一台计算机上的其他程序集，我应该使用强名称对其进行签名，但注册成功，它甚至可以正常工作。
AFAIK 强名称旨在防止所谓的 DLL 地狱。但 COM 也旨在防止 DLL 地狱。如果我更改任何暴露给 COM 的接口，我必须要么更改 GUID，要么至少保持二进制兼容性。所以用强名称签名似乎并没有增加任何有用的东西——没有什么能阻止我破坏 COM 接口，然后用相同的密钥对签名并拥有成熟的 DLL 地狱。
在 COM 公开的 .NET 程序集的情况下，使用强名称签名有什么用？
这是一个笨拙的警告。COM DLL Hell 有两个方面。真正糟糕的是修改公共接口而不是分配新的 GUID。未重新编译的客户端应用程序在调用完全错误的方法或使用令人讨厌的 AccessViolationException 炸弹时往往会崩溃和烧毁，根本不知道原因可能是什么。
第二个是做所有正确的事情（分配新的 GUID），然后用新版本覆盖现有的 DLL。您仍然会崩溃该陈旧的客户端应用程序，但更温和的是 E_NOINTERFACE hresult 会生成一个非常具体的异常来帮助您诊断原因。不过，用户并没有更快乐。
该场景在 .NET 中有现成的解决方案，GAC 支持并行部署具有不同版本号的程序集，以便旧版本和新版本可以共存，并且过时的客户端应用程序继续对旧版本感到满意版本。这需要一个强名称。是的，当您使用 /codebase 时，该警告肯定会被抑制，因为这清楚地表明您不会使用 GAC。尽管在使用 /codebase 时稍微调整一下你的鼻子并没有什么坏处。此外，您永远不会在测试时在您的开发机器上使用 GAC，但在部署时当然应该考虑它。
据我所知，COM 并不是为了防止 DLL 地狱，它是 Hades 本身的坑。术语“DLL Hell”来自多个库的问题，每个库都有同名的方法。在系统注册表中注册 COM 程序集对运行时的解析没有帮助。
对用作 COM 服务器的程序集进行签名可确保该程序集不会与同一台计算机上的其他 COM 注册程序集发生冲突。如果没有签名，如果两个 COM 注册程序集具有相同名称的方法，则可能会导致问题。
强命名主要用于将 Dll 放入 GAC。因此，您可以在同一台计算机上安全地拥有多个具有相同名称（！）的 Dll 版本，这与常规 COM-Dlls 经常会产生问题。不签署 Dll 会删除 GAC 的能力。因此，您没有任何直接的问题，但是您没有使用有用的功能，因此您会收到警告。