如何对外部 DLL 进行强签名,同时保留其程序集元数据?

发布于 2024-09-14 22:46:03 字数 657 浏览 1 评论 0原文

我在项目中使用了一些未签名的库。因为我的应用程序经过强签名,所以库也必须经过强签名。

我使用以下方法对这些库进行签名:

"%PROGRAMFILES%\Microsoft SDKs\Windows\v7.1\Bin\ildasm.exe" /nobar /all /out=library.il library.dll
"%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\ilasm.exe" /dll /key=MyKey.snk library.il

问题是任何元数据(例如版本号)都会在现在签名的 DLL 中丢失。这是一个问题,因为现在库之间的一些依赖关系被破坏了。如何在不实际编译这些库的源代码的情况下保留版本号?

更新

它实际上是一个特定的 DLL 显示了这个问题,我发现它是使用 ILMerge 构建的。也许这就是造成问题的原因。需要明确的是:ILMerge 生成的 DLL 确实具有正确的元数据,只有在反汇编和重新组装它之后,元数据才会消失。

更新2

我在Reflector中打开了DLL,看起来至少版本号仍然存在。我一直在使用 Windows 资源管理器中的文件属性对话框/详细信息选项卡进行检查。所以我认为缺少的是清单。

I have a few libraries I use in my project that are unsigned. Because my application is strongly signed, the libraries must be as well.

I sign these libraries using:

"%PROGRAMFILES%\Microsoft SDKs\Windows\v7.1\Bin\ildasm.exe" /nobar /all /out=library.il library.dll
"%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\ilasm.exe" /dll /key=MyKey.snk library.il

The problem is that any metadata, such as version numbers, get lost in the now-signed DLL. This is a problem because now some dependencies between the libraries are broken. How do I retain the version numbers without resorting to actually compiling the source code of those libraries?

UPDATE

It's actually a particular DLL that shows this problem and I've found out that is built using ILMerge. Perhaps this is causing the problem. Just to be clear: the DLL that is produced by ILMerge does have the proper metadata, only after disassembling and reassembling it, the metadata disappears.

UPDATE 2

I opened the DLL in Reflector and it appears that at least the version number is still there. I was checking using the file properties dialog/details tab in Windows Explorer all the time. So I figure it is the manifest that is missing instead.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

疯了 2024-09-21 22:46:03

我想知道为什么会发生这种情况。我在使用 ilasm 和 ildasm 对未签名和签名程序集进行往返编译方面也有很好的经验。您能否验证 ILasm 输出的元数据是否仍然包含版本信息(程序集范围的底部):

.assembly ConsoleApplication1
{
  //...
  .hash algorithm 0x00008004
  .ver 1:0:0:0
} 

刚刚再次检查,它“在我的机器上运行”(使用与您完全相同的命令行开关)。

实际上会丢失的是 FileVersion 属性(将鼠标悬停在程序集上时在 Windows 资源管理器中看到的属性。AssemblyVersion 属性仍然存在且正确)您是否混淆了两者?只有 AssemblyVersion 对于绑定信息很重要。请参阅此 SO post 了解更多信息。

希望我能提供帮助,否则您需要提供更多上下文。

I'm wondering why this happens. I have quite good experience in round-trip compiling using ilasm and ildasm on unsigned and signed assemblies likewise. Can you verify the metadata output by ILasm still contains the version information (bottom of the assembly scope):

.assembly ConsoleApplication1
{
  //...
  .hash algorithm 0x00008004
  .ver 1:0:0:0
} 

Just checked again, it "works on my machine" (using the exact same commandline switches as you did).

What will actually be lost is the FileVersion attribute (the one you see in windows explorer when hovering over the assembly. The AssemblyVersion attribute is still present and correct. Could it be you're confusing the two? Only the AssemblyVersion is important for binding information. See this SO post for more info.

Hope I could help, otherwise you'd need to provide more context.

请止步禁区 2024-09-21 22:46:03

如果你有源代码,那么只需用强名称重新编译库 - 反汇编和重新汇编通常效果很好,但它仍然是一种黑客行为。

为了保持库之间的依赖关系正常工作,您需要更新 .il 代码中的引用以使用它们所引用的程序集的公钥,否则它们将尝试引用程序集的未签名版本,从而无法加载它在运行时。

您可以手动完成此操作,但组装 2 或 3 次后就会变得非常乏味。一个快速解决此问题的方法是 signer,它可以为您解决许多涉及的困难,并执行以下操作:干得好——通常很快而且很干净。

(请注意,目前它是针对旧的 .NET 版本构建的。如果您使用 C# 4/.NET 4 程序集,则需要下载源代码,将其更改为目标 .NET 4 并重建它以获得 Signer.exe将正确处理 .NET 4 程序集)。

If you have the source code, then just recompile the libraries with strong names - disassembling and reassembling usually works pretty well, but it's still a hack.

To keep dependencies between the libraries working, you need to update the references in the .il code to use the public key of the assembly they are referencing, otherwise they will try to reference an unsigned version of the assembly, and thus fail to load it at runtime.

You can do this by hand, but it gets very tedious after 2 or 3 assemblies. A quick fix for this is signer, which deals with a lot of the difficulties involved for you, and does a great job - it's usually pretty quick and clean.

(Note that at present it's been built against an old .NET version. If you use C# 4/.NET 4 assemblies you'll need to download the source, change it to target .NET 4 and rebuild it to get a signer.exe that will correctly handle .NET 4 assemblies).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文