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

Question

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

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

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

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

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

EDIT

Мы все еще страдаем от этого. Я просмотрел все двоичные файлы в каталоге 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) сайт отображает эти ошибки. Сайт работает в режиме интегрированного конвейера и не настроен на 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

Answer 1

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

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

След, который заставляет нас поверить, что это действительно поврежденная dll, заключается в том, что если вы просматриваете свой dll скомпилированного представления в ildasm.exe и изучаете фактический вызов метода с использованием lamda, вы получаете «[SIGNATURE ENDED PREMATURELY]» ошибка, показанная в 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-битные), и единственной, которая имела эту проблему. Тем не менее, «битность» была красной селедкой!

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

Звучит так, будто вы вызываете 32-битный компонент COM. Вам, вероятно, нужно либо запустить приложение в 32-битном режиме, либо изменить свою зависимость.

См. Сообщение Скотта Хансельмана для получения дополнительной информации.

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

Answer 5

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

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

После методического исключения целого множества вещей (преимущественно версии 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 некоторого причудливого вида.

Answer 6

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

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

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

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

Соответствующий вопрос «Недопустимая двоичная подпись» в приложении ASP.NET MVC , похоже, более конкретно относится к обнаруженной мной проблеме, поэтому я дал более подробный ответ там.

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