"Плохая двоичная подпись" в приложении ASP.NET MVC

Мы получаем ошибку выше на некоторых страницах приложения ASP.NET MVC, когда оно развертывается в 64-битном окне сервера Windows 2008. Он отлично работает на наших машинах разработки, хотя это 32-битные XP. Просто задавался вопросом, встречался ли кто-нибудь с этим раньше, и есть ли какие-нибудь предложения? Подробности:

Плохая двоичная подпись. (Исключение из HRESULT: 0x80131192)

Описание: Необработанное исключение возникло во время выполнения текущего веб-запроса. Просмотрите трассировку стека для получения дополнительной информации об ошибке и ее возникновении в коде.

Сведения об исключении: System.Runtime.InteropServices.COMException: Плохая двоичная подпись. (Исключение из HRESULT: 0x80131192)

Все проекты настроены для компиляции для любого процессора и скомпилированы в режиме Release. Сайт ASP.NET предварительно скомпилирован, а предварительно скомпилированная сборка находится в 64-битном агенте сборки TeamCity Windows 2008. Спасибо заранее.

ИЗМЕНИТЬ

Мы по-прежнему страдают от этого. Я просмотрел все двоичные файлы в каталоге bin сайта, используя corflags.exe. Ни один из них не имеет установленный флаг 32BIT, и все имеют значение CorFlags 9, за исключением Antlr3.Runtime.dll, которое имеет значение 1. Проблема затрагивает только определенные страницы, и, похоже, это те, которые используют FluentValidation (включая FluentValidation.Mvc и FluentValidation.xValIntegration). Ни один из них не показывает ничего необычного при проверке с помощью corflags.exe, и нет никаких странных зависимостей, обнаруженных ildasm.

При создании локально (32-разрядная Windows XP) сайт развертывается и работает нормально. При построении агентов сборки (64-битный Windows 2008 Server) сайт отображает эти ошибки. Сайт работает в режиме 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

ОТВЕТЫ

Ответ 1

Я только что видел подобную проблему, когда некоторые лямбда-выражения используются в представлениях, что приводит к повреждению dll.Net при компиляции в 64-разрядной системе. Это приводит к тому же исключению, которое вы видите, и, безусловно, похоже на вероятного кандидата.

Извините, если это кажется немного расплывчатым, поскольку мы не полностью решили это и все еще изучаем его, хотя я обязательно буду обновляться здесь, когда у нас будет разрешение.

След, который заставляет нас полагать, что это настоящая поврежденная 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 бит), и единственная, у кого есть эта проблема. Однако "битти" была красной селедкой!

Надеюсь, это поможет вам решить вашу проблему.

Ответ 3

BadgerB в этот поток может быть что-то сказать:

Я ошибаюсь или эта ошибка должно быть вызвано, когда dll значительно изменилось ( подпись вызова метода изменяется) без перекомпиляции кода, который использует dll принять новую подпись в счет.

Похоже, разница между рабочими и нерабочими сценариями - это машина/среда, используемая для создания двоичных файлов. Может быть, при создании с TeamCity на 64-битной машине изменяется интерфейс или подпись какого-либо метода, который вызывает эту ошибку?

Можете ли вы опубликовать полный стек вызовов, когда возникает это исключение? Существуют ли какие-либо COM-объекты или вызовы P/Invoke для собственного кода? Вы используете какой-либо собственный код?

Ответ 4

Возможно ли исключить серьезную проблему с сервером или его программным обеспечением?

По следам и вашим комментариям о строке 53, я бы серьезно подумал о некотором повреждении, не связанном с вашим кодом, то есть я ожидаю, что какой-либо связанный код .net будет запущен для изменения стека в ошибке.

Ответ 5

Просто поместите это там, в случае, если другие найдут этот вопрос.

У меня была аналогичная проблема, хотя сообщение об ошибке несколько отличалось: System.BadImageFormatException: Bad binary signature. (Exception from HRESULT: 0x80131192)

Я проследил проблему до того, как lambda передается между проектом веб-сайта .NET 4.0 и библиотекой классов 3.5 после предварительной компиляции с помощью aspnet_merge.

Проблема возникает только после установки VS2012 (а также ее обновления .NET 4.0 до 4.5).

Связанный с этим вопрос "Плохая бинарная подпись" в приложении ASP.NET MVC показался более специфичным для проблемы, которую я нашел, поэтому я дал более подробную информацию ответьте там.

Надеюсь, что это поможет.

Ответ 6

Поскольку это был мой самый важный источник за последние три дня расследования, я опубликую здесь свое решение.

Подобно другим, сообщающим об этой проблеме, у нас была успешная 32-разрядная среда развертывания, работающая с TeamCity, но переходила на 64-разрядную, что является единственным местом, где это происходит. Он также отображается только на определенных страницах, а не "intermittenly" или "randomly", как сообщают некоторые.

После методического извлечения целого ряда вещей (преимущественно aspnet_merge.exe версии и среды) и нахождения страницы MVC, где я мог бы воспроизвести проблему, я решил, что это проблема с кодом. Другие места также указывают на лямбда-выражения, являющиеся причиной, которая для нас верна. Следующий код относится только к коду только в представлениях.

Чтобы добраться до точки, неправильный код или нет, это будет работать на aspnet_merge.exe версии 4.x, запущенной на 32-битной:

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

Где, как и на aspnet_merge.exe версии 4.x на 64-битной, она HAS будет записана как:

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

Я знаю, что подсказка в имени IEquality * Comparer *, которая логически должна принимать два аргумента, но первая версия будет компилироваться и работать в 32-битной среде.

Я просто надеюсь, что этот пост поможет другим в той же ситуации. Тогда я уверен, что кто-то сможет расшифровать это и переманить его до 32-бит-64-битной версии IntPtr какого-то странного сорта.