代码之家 › 专栏 › 技术社区 › David M

ASP.NET MVC应用程序中的“错误二进制签名”

64bit interop asp.net-mvc

David M · 技术社区 · 14 年前

在将ASP.NET MVC应用程序部署到64位Windows2008服务器盒时,在该应用程序的某些页上会出现上述错误。它在我们的开发机器上工作得很好,尽管它们是32位的XP。只是想知道是否有人以前遇到过这种情况,有什么建议吗?详情如下:

错误的二进制签名。(来自hresult的异常:0x80131192)

描述:执行当前Web请求期间发生未处理的异常。请查看堆栈跟踪以获取有关错误及其在代码中的来源的更多信息。

异常详细信息:System.Runtime.InteropServices.ComException:错误的二进制签名。(来自hresult的异常:0x80131192)

所有项目都设置为针对任何CPU进行编译,并以发布模式进行编译。ASP.NET站点是预编译的,预编译的生成是在64位Windows 2008 TeamCity生成代理上进行的。事先谢谢。

编辑

我们仍然为此苦恼。我已经使用corflags.exe查看了网站bin目录中的所有二进制文件。没有一个设置了32位标志,所有的corflags值都为9,除了值为1的antlr3.runtime.dll。问题只影响某些页面,似乎是那些使用FluentValidation(包括FluentValidation.mvc和FluentValidation.xvalintegration程序集)的页面。当使用corflags.exe进行检查时,所有这些都没有显示出异常的内容,并且ildasm没有显示出奇怪的依赖项。

当在本地构建(32位Windows XP)时,站点部署并运行良好。当构建在生成代理(64位Windows 2008服务器)上时,站点将显示这些错误。站点以集成管道模式运行,未设置为32位。

堆栈跟踪是:

[COMException (0x80131192): Bad binary signature. (Exception from HRESULT: 0x80131192)]
   ASP.views_user_newinternal_aspx.__RenderContent2(HtmlTextWriter __w, Control parameterContainer) in e:\TeamCity\buildAgent\work\605ee6b4a5d1dd36\...Admin.Mvc\Views\User\NewInternal.aspx:53
   System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children) +115
   ASP.views_shared_site_master.__Render__control1(HtmlTextWriter __w, Control parameterContainer) in e:\TeamCity\buildAgent\work\605ee6b4a5d1dd36\...Admin.Mvc\Views\Shared\Site.Master:26
   System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children) +115
   System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children) +240
   System.Web.UI.Page.Render(HtmlTextWriter writer) +38
   System.Web.Mvc.ViewPage.Render(HtmlTextWriter writer) +94
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +4240

6 回复 | 直到 11 年前

Rob Levine 14 年前

我刚刚看到一个类似的问题,在视图中使用一些lambda表达式,这会导致在64位系统上编译时.NET dll损坏。这导致了你看到的同样的例外,当然听起来像是一个可能的候选人。

抱歉,如果这看起来有点含糊,因为我们还没有完全解决这个问题,并且仍在调查它,尽管我会确保在我们有解决方案时更新这里。

让我们相信这是一个实际损坏的dll的线索是,如果您在ildasm.exe中查看编译的视图dll,并检查涉及lamda的实际方法调用,您会得到一个在ildasm中显示的“[签名过早结束]”错误。然而,Redgate的Reflector在尝试扩展该方法时崩溃。

在我们的例子中,ildasm如下所示:

IL_029f:  call class [System.Core]System.Linq.Expressions.Expression`1<!!0> [System.Core]System.Linq.Expressions.Expression::Lambda<class [System.Core]System.Func`2<class [MyCode.Authentication.Admin.Mvc]MyCode.Authentication.Admin.Mvc.Dto.InternalUserDto,object>>(class [System.Core]System.Linq.Expressions.Expression, class [System.Core]System.Linq.Expressions.ParameterExpression[])
IL_02a4:  call class [System.Web.Mvc]System.Web.Mvc.HtmlHelper [MyCode.Extensions]MyCode.Extensions.System.Web.Mvc.HtmlHelperInputExtensions::CheckBox<[2]>(class [System.Core]System.Linq.Expressions.Expression`1<class [System.Core]System.Func`2<class [MyCode.Extensions]'type parameter'.T,object>> [SIGNATURE ENDED PREMATURELY])

我们注意到这只是一个64位的问题。我们将调查.NET 4.0上是否仍存在此问题。我们知道后我会在这里更新。

我们也在研究微软是否将此作为一个缺陷提出。再次提醒,我们知道后我会在这里更新。

[编辑:现在已经找到问题的根本原因]

我想我会回来更新这个答案。

对我们来说,这根本不是编译器的问题,而是aspnet合并的问题。简而言之,在我们的64位构建框中,我们使用了一个旧的、过时的aspnet合并副本(意外),它看起来工作正常,但导致了这些损坏的dll(与您描述的完全相同)。路径已更改,因此我们的Web部署项目使用了错误的版本。

更新到aspnet合并3.5版或更高版本的路径,修复了问题。

我们原以为这是一个64位的问题,因为我们的构建盒是我们编译的唯一64位环境(我们所有的开发人员工作站都是32位的),而且是唯一有这个问题的环境。然而,“咬”是一条红鲱鱼!

希望这能帮助你解决你的问题。

Colin Newell 14 年前

听起来像是在调用一个32位的COM组件。您可能需要以32位模式运行应用程序,或者更改您的依赖关系。

更多信息请参见斯科特·汉瑟曼的帖子。

http://www.hanselman.com/blog/32bitnessAnd64bitnessAndMigratingDasBlogOnIIS7AndASPNETUnderVista64.aspx

Chris Schmich 14 年前

BadgerB在 this thread 可能是关于某件事:

我是错了还是这个错误当一个动态链接库以显著的方式改变方法调用的签名已更改) 不重新编译使用要接受新签名的dll 帐户。

听起来工作场景和非工作场景之间的区别在于用于构建二进制文件的机器/环境。在64位机器上与TeamCity一起构建时,某个方法的接口或签名是否正在更改,从而导致此错误?

当发生此异常时,是否可以发布完整的调用堆栈?是否有对本机代码的COM对象或P/Invoke调用?您是否使用任何本机代码?

eglasius 14 年前

您是否可以排除服务器或其软件的严重问题?

通过跟踪和您对第53行的评论,我会认真考虑一些与您的代码无关的损坏情况,即,我希望触发任何相关的.NET代码来改变错误中的堆栈。

Community SushiHangover 7 年前

把这个放在外面,以防别人发现这个问题。

我有一个类似的问题,尽管错误消息略有不同: System.BadImageFormatException: Bad binary signature. (Exception from HRESULT: 0x80131192)

我跟踪了这个问题,直到一个lambda在.NET 4.0网站项目和一个3.5类库之间传递,然后使用 aspnet_merge .

该问题仅在安装了VS2012(及其.NET 4.0到4.5的就地升级)之后出现。

相关问题 âBad binary signatureâ in ASP.NET MVC application 似乎对我发现的问题更为具体,所以我在那里给出了一个更详细的答案。

希望有帮助。

Chrace 11 年前

由于这是我过去三天调查中最重要的来源,我将把我的解决方案张贴在这里。

与报告此问题的其他人类似,我们有一个成功的32位部署环境,运行TeamCity,但正在迁移到64位,这是唯一发生这种情况的地方。它也只出现在特定的页面上,而不是像某些人报告的那样“间歇”或“随机”。

在系统地排除了所有的问题(主要是aspnet_merge.exe版本和环境)并找到了一个可以重现问题的MVC页面之后,我把它归结为一个代码问题。其他地方也指出lambda表达式是我们的原因。以下代码仅与视图中的代码相关。

为了达到目的,不管代码是否错误, 将使用在32位上运行的aspnet_merge.exe 4.x版:

Model.MyEvents.Distinct(x => x.CategoryName).Many()

其中,与64位的aspnet_merge.exe版本4.x相同有写为:

Model.MyEvents.Distinct((x, y) => x.CategoryName == y.CategoryName).Many()

我知道这个提示的名称是iequality*comparer*,它在逻辑上应该接受两个参数,但是第一个版本将在32位环境中编译和工作。

我只希望这篇文章能帮助处于同样情况下的其他人。然后我确信有人能够破译出这个问题,并将其分解成某种奇怪的32-vs-64位intptr问题。