Как обработать переход с ASP MVC версии 4.0.0.0 на 4.0.0.1

Question

Это продолжение обновления Windows привело к тому, что MVC3 и MVC4 перестали работать

У меня также была проблема, когда обновление Windows на моей машине разработки приводило к прекращению работы моего проекта MVC 4. Я изменил ссылку на сборку на целевую версию 4.0.0.1, и она начала работать. Для меня.

Моя проблема заключается в том, что приложение затем развертывается на нескольких веб-серверах. На самом деле у нас есть сервер сборки, на котором создаются версии клиента, а затем несколько веб-серверов.

Первый вопрос: когда мы запускаем обновление Windows на производственных серверах, старые версии приложения перестают работать? Я предполагаю, что ответ "да". Мы еще не запустили обновление Windows ни на сборочных, ни на производственных машинах.

Изменение ссылки означало, что она больше не может быть собрана на сборочной машине. Я могу обойти это, установив флаг Specific Version в false и Copy Local в true. Затем он опирается как на мою среду разработки, так и на сервер сборки.

Вопрос: Насколько слабой является проверка, если у меня есть Ложная конкретная версия? Это позволяет 4.0.0.x? 4.0.xx? 4.xxx? или хххх?

Однако, даже несмотря на то, что он встроен в эту конфигурацию, он затем не запускается (не может найти сборку) на тестовом веб-сервере. Проблема здесь в том, что у меня есть следующее в моем файле web.config (согласно инструкциям Microsoft при обновлении с MVC 2 до MVC 4):

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity culture="neutral" name="System.Web.Mvc" publicKeyToken="31BF3856AD364E35"/>
    <bindingRedirect newVersion="4.0.0.1" oldVersion="0.0.0.0-4.0.0.1"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35"/>
    <bindingRedirect newVersion="2.0.0.0" oldVersion="1.0.0.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35"/>
    <bindingRedirect newVersion="4.0.0.0" oldVersion="1.0.0.0-3.0.0.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35"/>
    <bindingRedirect newVersion="2.0.0.0" oldVersion="1.0.0.0"/>
  </dependentAssembly>
</assemblyBinding>

Проблема в линии

<bindingRedirect newVersion="4.0.0.1" oldVersion="0.0.0.0-4.0.0.1"/>

для сборки System.Web.Mvc. (Раньше говорили 4.0.0.0 не 4.0.0.1 в этом ряду, конечно.) Если я вернусь к 4.0.0.0 на тестовом сервере тогда все работает.

Моя проблема двоякая. Отчасти это просто то, что я хочу иметь возможность собирать и запускать как локально, так и на наших сборочных / производственных серверах. Однако у нас есть ситуация, когда мы размещаем несколько клиентов, работающих с разными версиями нашего приложения, на одном сервере. Мы не можем заставить всех наших клиентов обновиться до последней версии сразу только из-за этого исправления обновления Windows - кроме всего прочего, веб-приложение является лишь частью более широкого набора приложений, поэтому нам придется заставить их обновить пакет!

Я полагаю, что одним из вариантов является проверка каждой старой версии, которая все еще используется, обновление номера версии MVC и создание новой версии. Затем, когда мы обновляем веб-сервер, мы должны обновить всех клиентов на этом сервере до новой (совместимой с 4.0.0.1) версии их текущей версии. Я действительно хотел бы избежать необходимости обновлять, фиксировать и перестраивать столько версий, если это возможно.

Другой вариант - не запускать обновление Windows на веб-сервере и попытаться установить на компьютере сборки библиотеки 4.0.0.0 и 4.0.0.1. Тогда мы могли бы собрать как старую, так и новую версию. Поскольку любые новые версии (использующие 4.0.0.1) имеют значение CopyLocal, установленное в true на сборке MVC (старые нет), они должны иметь возможность развертывания на веб-серверах без обновления самих веб-серверов.

Вопросы:

• Кто-нибудь знает, возможно ли установить обе версии одновременно? Я надеюсь, что я мог бы просто сохранить dll 4.0.0.0, запустить обновление Windows, а затем скопировать в старый dll обратно в GAC вместе с новым.
• Насколько серьезен риск безопасности, исправленный этим патчем? Является ли проблемой позволить людям запускать старые версии еще дольше? Является ли наличие старого.dll на веб-сервере угрозой безопасности или только для приложений, которые его используют?
• Есть ли способ сделать bindingRedirect до 4.0.0.х? или можно вообще убрать перенаправление привязки?

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

Answer 1

Я был членом команды, которая столкнулась с той же проблемой с несколько иной точки зрения. Сообщение об ошибке, которое отправляется при неправильном обновлении системы безопасности, может вводить в заблуждение и его трудно интерпретировать. Мы столкнулись с ошибками развертывания и сборки, когда пытались опубликовать наши приложения в разных средах. Основной причиной было то, что этот патч был применен через обновление Windows в некоторых тестовых средах, но не на других серверах. Любой сервер, на котором не было патча, вылетел бы, когда мы развернули наше приложение. Я бы порекомендовал вашей системной команде применить исправление и обновить все ваши приложения для ссылки на эту DLL. Обновления безопасности Поскольку указанная библиотека игнорируется в системе контроля версий, но все же подробно изложена в веб-конфигурациях, ее необходимо быстро решить. Некоторые среды позволят вам щелкнуть правой кнопкой мыши и выбрать, какую версию MVC dll использовать локально, и при этом развертывать приложение без проблем. Если вы используете веб-развертывание и ДОЛЖНЫ иметь возможность переключения, вы можете написать преобразования веб-конфигурации для каждой веб-конфигурации Transforms. Одна вещь, которую я заметил при исправлении этой проблемы (обновление до 4.0.0.1), это то, что обновление до последней версии MVC.dll в моем проекте позволило мне получить последние версии пакетов nuget. Если вы не обновите и останетесь со старыми версиями, вы застрянете со старыми версиями javascript, jquery и других библиотек MVC.