签名未签名的程序集程序

2023-09-04 02:08:01 作者:傲世雄霸

NHibernate的2.1的最近的升级带来了一个大型的头痛情况 到表面。

这似乎大部分项目的建设被默认设置为签名的程序集。对于 例如fluentnhibernate引用的密钥文件fluent.snk。

Nhibernate.search建立从我可以收集签名,也不会建 签署的是,如果你引用生成的密钥文件,你的错误:

引用程序集Lucene.Net不具有强名称

这意味着,有nhibernate.search像castle.activerecord项目 当你引用的可怕错误的依赖不会建 装配nhibernate.search没有强名称:

相当多的项目中使用caslte.activerecord所以它是非常重要的 这个版本。

有没有人任何想法在这里做什么,因为我完全没了主意?

这是完全疯狂。

解决方案 获取MSIL为提供组件 从VS.NET命令提示符下,输入以下命令: C:>反汇编providedAssembly.dll /out:providedAssembly.il 在重命名/移动原装配 我只是钉在那些.orig的文件名。 创建从MSIL输出一个新的组件和程序集密钥文件 假设你已经有一个程序集的公钥文件,就从VS.NET命令提示符处键入以下: C:> ILASM providedAssembly.il / DLL /key=keypair001.snk

源代码http://www.andrewconnell.com/blog/archive/2004/12/15/772.aspx

解决 对程序集签名是出错 拒绝访问

The recent upgrade of NHibernate 2.1 has brought a mega headache situation to the surface.

It seems most of the projects build by default as signed assemblies. For example fluentnhibernate references the keyfile fluent.snk.

Nhibernate.search builds unsigned from what I can gather and will not build signed that is if you reference a generated keyfile, you get the error:

Referenced assembly 'Lucene.Net' does not have a strong name

This means projects like castle.activerecord that have nhibernate.search as a dependency will not build as you get the horrendous error referenced assembly nhibernate.search does not have a strong name:

Quite a few projects use caslte.activerecord so it is quite important that this builds.

Has anyone any idea what to do here as I am totally out of ideas?

This is complete madness.

解决方案

Obtain the MSIL for the provided assembly From a VS.NET command prompt, enter the following: c:>ildasm providedAssembly.dll /out:providedAssembly.il Rename/move the original assembly I just tack on ".orig" to the filename. Create a new assembly from the MSIL output and your assembly keyfile Assuming you already have an assembly key pair file, do the following from a VS.NET command prompt: c:>ilasm providedAssembly.il /dll /key=keypair001.snk

Source http://www.andrewconnell.com/blog/archive/2004/12/15/772.aspx