“Плохая двоичная подпись” в ASP.NET приложение MVC
Мы получаем ошибку выше на некоторых страницах приложения MVC ASP.NET, когда она развертывается на поле сервера Windows 2008 на 64 бита. Это хорошо работает на наших машинах разработки, хотя это XP на 32 бита. Просто задался вопросом, встретился ли кто-либо с этим прежде и имеет какие-либо предложения? Детали следующим образом:
Плохая двоичная подпись. (Исключение из HRESULT: 0x80131192)
Описание: необработанное исключение произошло во время выполнения текущего веб-запроса. Рассмотрите отслеживание стека для получения дополнительной информации об ошибке и где это произошло в коде.
Детали исключения: Система. Время выполнения. InteropServices. COMException: Плохая двоичная подпись. (Исключение из HRESULT: 0x80131192)
Все проекты установлены скомпилировать для Любого ЦП и компилируются в режиме Release. Сайт ASP.NET предварительно компилируется, и предварительно скомпилированная сборка находится на агенте сборки Windows 2008 TeamCity на 64 бита.Заранее спасибо.
Править
Мы все еще заполоняемся этим. Я посмотрел на все двоичные файлы в каталоге bin веб-сайта с помощью corflags.exe. Ни одному не установили флаг 32BIT, и у всех есть значение CorFlags 9 за исключением Antlr3.Runtime.dll, который имеет значение 1. Проблема только влияет на определенные страницы, и это, кажется, те, которые используют FluentValidation (включая FluentValidation. Mvc и блоки FluentValidation.xValIntegration). Ни одно из этих шоу что-либо необычное при осмотре с corflags.exe, и нет никаких нечетно выглядящих зависимостей, показанных ildasm.
При локальном создании (Windows XP на 32 бита), сайт развертывается и хорошо работает. При построении на агентах сборки (Windows 2008 Server на 64 бита), сайт отображает эти ошибки. Сайт работает в режиме Integrated Pipeline и не установлен на 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
4 ответа
Я только что видел похожую проблему где некоторые лямбда-выражения используются в представлениях, что приводит к повреждению библиотеки DLL .Net при компиляции в 64-битной системе. Это приводит к тому же исключению, которое вы видите, и, безусловно, звучит как вероятный кандидат.
Приносим извинения, если это кажется немного расплывчатым, так как мы не полностью решили эту проблему и все еще изучаем ее, хотя я обязательно обновлю здесь, когда у нас будет решение.
След, который заставляет нас поверить, что это действительно поврежденная dll, заключается в том, что если вы просмотрите свою скомпилированную dll представления в ildasm.exe и исследуете фактический вызов метода с использованием lamda, вы получите сообщение «[ПОДПИСЬ ЗАКОНЧИЛАСЬ ПРЕДВАРИТЕЛЬНО]» ошибка отображается в ildasm. Однако рефлектор RedGate дает сбой при попытке расширить метод.
В нашем случае 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. Я обновлю здесь, когда мы узнаем.
Мы также находимся в процессе проверки, не была ли эта ошибка связана с Microsoft. Опять же, я обновлю здесь, когда мы узнаем.
[РЕДАКТИРОВАТЬ: теперь выяснив основную причину проблемы]
Я подумал, что вернусь и обновлю этот ответ.
Для нас оказалось, что это вовсе не проблема компилятора, а проблема с aspnet_merge. Короче говоря, в наших 64-битных сборочных коробках мы использовали старую устаревшую копию aspnet_merge (случайно), которая, казалось, работала, но приводила к этим поврежденным dll (точно так, как вы описываете). Путь был изменен, поэтому в нашем проекте веб-развертывания использовалась неправильная версия.
При обновлении пути к aspnet_merge версии 3.5 или выше проблема была устранена.
Изначально мы думали, что это 64-битная проблема, потому что наши сборки были единственной 64-битной средой, в которой мы скомпилировали (все наши рабочие станции разработчика 32-битные), и единственной, где возникла эта проблема. Однако «резкость» была отвлекающим маневром!
Надеюсь, это поможет вам решить вашу проблему.
Похоже, вы вызываете 32-битный COM-компонент. Вероятно, вам нужно либо запустить приложение в 32-битном режиме, либо изменить свою зависимость.
Смотрите пост Скотта Хэнселмана для дополнительной информации.
BadgerB в эта ветка может быть о чем-то:
Я ошибаюсь или это ошибка должно быть вызвано, когда DLL существенно изменились ( подпись вызова метода изменена) без перекомпиляции кода, который использует DLL, в которую будет помещена новая подпись учетная запись.
Похоже, что разница между рабочим и неработающим сценариями заключается в том, какая машина / среда используются для сборки двоичных файлов. Может ли быть так, что при сборке с TeamCity на 64-битной машине интерфейс или сигнатура какого-либо метода изменяется, что затем вызывает эту ошибку?
Можете ли вы опубликовать полный стек вызовов при возникновении этого исключения? Существуют ли какие-либо COM-объекты или вызовы P / Invoke в машинный код? Вы используете собственный код?
Можно ли исключить серьезную проблему с сервером или его программным обеспечением?
Судя по трассировке и вашему комментарию о строке 53, я серьезно рассмотрел бы что-то поврежденное, не связанное с вашим кодом, т.е. любой связанный код .net, запускаемый для изменения стека при ошибке.