问题标签 [strongname]

我找到了Microsoft 知识库文章：

但看起来他们希望我在创建密钥对后重新编译。有什么方法可以将程序集转换为强命名程序集而无需重新编译？

我有两个程序集 A 和 B。A 是强命名的，B 不是。

根据MSDN，我不能从 A 引用 B，因为强命名程序集只能引用另一个强命名程序集。

但是为什么可以加载程序集 B，实例化它的类并使用反射从程序集 A 调用它们的方法呢？

这是否违背了不允许在已签名程序集中引用未签名程序集的目的？

例如，在阅读了 .NET here中的强名称后，我有以下问题：

我们有一个Authenticode代码签名证书，我们用它来签署我们所有的 EXE、DLL 和 MSI 文件。这样做的好处是 Windows 知道 MSI 来自受信任的来源，并且可以根据需要验证每个文件的真实性。

我们目前不使用.NET 强名称。我已经读过强命名文件本质上意味着它是使用自签名证书进行数字签名的。我对此的看法是，由受信任的证书颁发机构签名的 Authenticode 证书比自签名证书更有价值，因为自签名证书的真实性没有人可以验证，因为它们缺少根证书（我们不会将其分发给最终用户，我们是！？）。

问题：如果已经使用了 Authenticode 签名，那么其他强命名程序集是否有任何价值？

所以基本上我们有一个强名称（强签名）程序集 x.dll，它由我们的组件之一 App.exe 使用。程序集的签名密钥在我们的存储库中，并且程序集是通过书面形式签署的

该程序集应该由一些安装通用软件包的安装程序放入 GAC，我们将其命名为 common.msi。但是我们的组件本身是由 App.msi 安装的。一起部署时，一切正常。但是当对 App.msi 进行更改时，那些与 x.dll 完全无关的，并且重新部署 App.msi，App.exe 无法找到 x.dll。请注意，不会对 x.dll 进行任何更改。但是，当也部署 common.msi 时，一切正常。所以我猜肯定存在构建版本或其他东西的问题，或者我一无所知的清单。有什么明显的我做错了吗？是不是可以单独部署组件而不触摸它，除非它被更改并且每次使用它的组件发生更改时都不会重新部署它？谢谢。

编辑：将程序集放入 GAC 是一项要求（我对此无能为力）

为什么在尝试使用 .snk 文件签署托管 C++ 项目时出现此错误。“......SlimDX\build\vs2010\x86\Debug\VOS.snk' 缺少签名所需的私钥”

我试过在项目设置中设置它::

1. 密钥文件 = $(ProjectDir)x86\$(Configuration)\VOS.snk
2. 延迟标志 = 否 (/DELAYSIGN:NO)

并且我尝试在 AssemblyInfo.cpp:: 中设置它

1. [程序集：AssemblyKeyFile("VOS.snk")]
2. [程序集：AssemblyDelaySignAttribute(false)]

我有 .snk 和 .pfx 文件。我在这里想念什么？在我的 C# .NET 3.5 项目中，我只需要 .snk 文件......为什么它在我的托管 c++ 项目中也不起作用？我是否还需要以某种方式使用我的 pfx 文件？

我时不时地在网络上看到一个示例项目，其中包含一个 .snk 文件，用于使用强名称对编译结果进行签名。

AFAIK这是完全错误的——一旦 .snk 文件被披露，任何人都可以生成一个程序集，该程序集可用于替换原始代码供应商提供但现在包含恶意代码的程序集。我想运送 .snk 文件的人不会认真对待这种风险，而只是运送文件，否则该项目将无法编译现成的。

除了“方便”之外，是否有任何理由发送 .snk 文件？

使用强名称（存储在 .snk 文件中的密钥对）进行签名（除其他用途外）旨在防止伪造组件。

例如：我发送了一个用强名称签名的程序集，然后其他一些开发人员使用我的程序集，所以他的程序集现在包含对我的引用，提到我的密钥对的公钥。一些用户安装了该开发人员程序集和我的程序集，并愉快地使用了该开发人员的代码。如果其他人试图生成一个看起来像我的版本的程序集并说服用户这是一个“值得安装的更新”，那么伪造的程序集将不会加载，因为我控制着我的密钥对并且伪造的程序集没有使用相同的密钥对进行签名. 好的，酷。

但是，是什么阻止了恶意方伪造我的程序集和其他开发人员的依赖程序集并“运送”它们呢？他们抓住我的程序集和那个开发人员的程序集，篡改两者，用任何密钥对我的程序集的伪造版本进行签名，然后将对其的引用添加到依赖程序集的伪造版本中，也对其进行签名，然后将两者都发送出去。我的意思是恶意“运送”两个程序集不应该比“运送”一个程序集困难得多。

使用强名称签名如何防止伪造多个程序集？

我知道不要将强命名的程序集放入早期版本的 ASP.NET 的 bin 文件夹中。我记得这引起了问题，但我不记得具体是什么问题。有谁知道这是否仍然适用于 ASP.NET 2.0？是否有任何理由不将强命名程序集放入 ASP.NET 2.0 或更高版本的 bin 文件夹中？

我有一个使用动态代码生成来创建代理类的项目。这个代理类利用了项目的内部类（这样就不会暴露实现细节），所以我使用 InternalsVisibleTo 和我动态生成的程序集的名称。直到最近，当我的客户强制要求所有已发布的程序集都必须具有强名称时，这才正常工作。

出现问题的原因是，为了将 InternalsVisibleTo 与强名称程序集一起使用，它引用的程序集也必须是强名称的，并且您必须提供公钥。我遇到困难的地方是如何为动态生成的程序集提供一个强名称。这是我到目前为止所做的：

1. 我已经为动态程序集创建了一个新的密钥对，以便 .snk 可以随产品一起提供（显然我们不想提供 .snk 用于对项目程序集的其余部分进行签名。）
2. 我已经提取了 PublicKey 并更新了 InternalsVisibleTo 以将新的动态 PublicKey 用于动态引用的程序集。

3. 我试图像这样签署动态生成的程序集：

   /li>

不幸的是，这不起作用，我一直很难找到任何关于它应该如何工作的文档。有谁知道如何签署动态生成的程序集，以便可以通过 InternalsVisibleTo 对其进行访问？我可以将必要的类公开，但最终会泄漏最好封装的实现细节。

在调试LinkedInToolkit时，我从 git下载了DotNetOpenAuth 源代码。现在我已经添加了参考，在编译来自 LinkedInToolkit 的预建网站时出现以下错误

无法加载文件或程序集 DotNetOpenAuth 版本 3.4.7.11039。无法修改强名称签名....

考虑到 DotNetOpenAuth DLL 是延迟签名的，如何让我的网站编译和运行？

我在 web.config 和引用中搜索了任何提及强命名 DLL 的内容。还会在哪里进行强名称检查？