问题标签 [strongname]

我的一位同事非常热衷于签署大会。他真的试图签署任何东西。即使我们使用来自 Microsoft 的未签名程序集，他也会获取源代码，对其进行签名，然后要求其他开发人员使用他的副本。

我可以理解签署程序集背后的基本思想：确保特定程序集不会被一些狡猾的黑客破坏。因此，如果我们是一家软件开发公司，我们应该在向我们的客户发布一些 .NET 库之前签署我们的程序集。

但是，我们在这里主要开发自己使用的 Web 应用程序，我只是看不出对我们使用的每个程序集进行签名的意义。

我在这里错过了什么吗？

好的，我一定很笨，因为我已经读过这个： http ://www.csharp411.com/net-assembly-faq-part-3-strong-names-and-signing/

而且我还是不明白...

假设我打开项目的属性并转到“签名”选项卡，然后选中“签署程序集”并使用密码生成一个新程序集。创建了一个带有 .pfx 扩展名的强名称密钥文件，包括公钥和私钥，VS 将在编译时对我的程序集进行数字签名，对吗？

私钥呢？不应该是私有的，而我，开发者，是唯一拥有它的人吗？程序集不应该只用公钥签名吗？

谁能给我解释一下？基本上，我想签署我的项目程序集并允许我的用户检查程序集是否真的由我开发，而我是唯一保留私钥的人（我认为我应该这样做）。

我有一个产品，它有大约 10 多个组件。我们过去常常在没有强烈命名程序集的情况下发布它。但是在阅读了强命名之后，我认为强命名程序集是一个明智的想法。只是想知道强命名程序使用的所有程序集的最佳实践是什么？

有什么想法吗？

我想实现一个自定义的程序集签名机制，就像Strong Name一样，然后开发一个程序在程序集元数据中写入签名信息，在程序集内部读取并验证签名是否正确。有可能做到这一点吗？

我在这里有我签名的程序集，其中一个我在资源中有一张图片。另一个被授予使用它作为它自己的，所以我的另一个程序集可以引用图片，并且一切正常。

仅当它不适用于 VS2008 中的表单设计器时。它看不到图像。（可能没问题，因为它是在编译时链接的。有人会想！！！）

但是，如果手动将图片从 修改为 ，它确实会看到这些internal图片public。资源类仍然是内部的。然后它工作。（因为它是同一个命名空间。）资源类不是部分的，因为部分只在同一个程序集中工作，因此它没有帮助。

问题是：这些资源是内部的，我不想从未签名的程序集中重用它们，更不希望团队外的其他人这样做。

有什么建议么？

提前谢谢

我有一个与 Active Directory 对话以检索用户信息的服务器可执行文件。除了 AD，此 exe 还允许客户编写自己的插件来与自定义用户目录对话。

这个可执行文件是强命名的。

以下陈述是否属实：

为了让强命名程序集加载另一个程序集，加载的程序集也必须使用相同的密钥进行签名。

如果程序集没有经过强签名，则以下代码返回 null，并且没有错误表明程序集未正确签名。请注意，如果我签署程序集，我会得到一个 IService 实例。这让我相信加载的程序集必须是强签名的。

那么，这是否意味着如果你有一个强签名的程序集，并且支持程序集插件，它们也必须被签名——插件编写者必须用相同的密钥对它们进行签名？这听起来不对。

最后，假设我有一个实现 IService 接口的程序集，但也引用了一个程序集，该程序集引用了另一个程序集，每个程序集都使用不同的密钥签名。当我尝试加载时会发生什么？它们都应该由同一个密钥签名吗？

我在 Visual Studio 2005 中有一个 C# 项目，它引用了一些 COM 库。当我构建它时，会抛出这样的错误：

引用的程序集“assemblyName”没有强名称。

现在，我曾经在 Visual Studio 2003 中引用 COM 程序集，它会自动对 Interop 包装器进行签名。我所要做的就是设置“包装程序集密钥文件”。

我尝试在 Visual Studio 2005 中找到类似的设置，但找不到。所以我想知道是否有任何等效的方法可以在 Visual Studio 2005 中强命名 COM 互操作并摆脱上述错误。

好的，这真的很烦人，我之前注意到 WPF 生成的用于加载 XAML 资源的代码似乎没有使用强名称，因此对于需要支持并行版本的 WPF 程序集的场景可能会出现问题。

事实证明是这样，现在它给我带来了问题 - 我有一个插件系统，它应该支持并排安装插件，这些插件的不同之处仅在于它们的版本号（它们的程序集版本）。这当然可以由 .NET 支持，因为即使它们具有相同的 DLL 文件名，程序集也被确定具有不同的身份，前提是它们具有强命名并且具有不同的公钥/私钥或具有不同的程序集版本号。

现在，如果我们查看 Visual Studio 为 windows 和 usercontrols 生成的代码，我们会在自动生成的文件中看到以下内容：

请注意创建资源定位器的行 - 它使用的是相对 URI，它没有指定强名称或包含 xaml 资源的程序集的版本。

我想也许 LoadComponent 会检查调用程序集的身份并使用它的公钥和版本详细信息，或者可能检查包含“this”参数类型的程序集的身份。

看起来情况并非如此 - 如果您有两个版本号不同（但文件名相同）的程序集，那么您可以获得 IOException 并显示消息“无法定位资源 X”（例如上面的示例“无法定位资源 'views/servicepanelui .xaml'。

更糟糕的是，我很确定这也意味着具有相同文件名但不同公钥/私钥的程序集（即来自不同发布者）也会导致此错误。

那么，有谁知道如何解决这个问题？如何使 WPF 强名称兼容。

请注意，就我而言，这是一个 WPF 错误。您不必为了避免这种情况而使用 Appdomain 隔离。

我从知名供应商处购买了验证码证书。

现在我想强命名一个程序集，然后对其进行数字签名。

这是我到目前为止所做的：

• 通过运行 sn.exe -p keypair.pfx key.snk 从 pfx 中提取公钥
• 选中项目属性签名选项卡上的“签署程序集”和“仅延迟签署”复选框
• 提供 key.snk 作为密钥文件进行签名
• 通过运行 sn.exe -tP key.snk 提取公钥令牌
• 通过运行 sn -Vr * 在我的 devbox 上禁用强名称验证，

这个想法是在团队构建中禁用延迟签名并在那里提供 keypair.pfx 文件。这样，我可以在访问受限的团队构建服务器上完全签署程序集，同时出于安全原因不在开发盒上提供私钥。

但是，当尝试在本地构建程序集时，出现以下错误：

签署程序集 '.dll' 时加密失败 - '提供程序的错误版本'

有人对此有解决方案吗？

我们生产了许多共享程序集的应用程序。由于内存或磁盘空间不是问题，我们通过将共享程序集复制到每个应用程序的本地文件夹中来使用私有程序集。这避免了将它们放入 GAC 所引起的问题。我听说如果我们在 GAC 中共享程序集，那么强大的名称是一件非常好的事情。

是否有充分的理由为私有程序集使用强名称？

顺便说一句：这是关于程序集的极好参考：链接文本