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

Это продолжение Обновление Windows, вызвавшее работу MVC3 и MVC4

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

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

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

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

Вопрос: Насколько слабый чек, если у меня есть конкретная версия false? Разрешает ли он 4.0.0.x? 4.0.x.x? 4.x.x.x? или x.x.x.x?

Однако, даже несмотря на то, что он строит в конфигурации thsi, он не запускается (не может найти сборку) на тестовом веб-сервере. Проблема здесь в том, что у меня есть следующее в моем 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 not 4.0.0.1.) Если я вернусь к 4.0.0.0 на тестовом сервере, тогда он будет работать.

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

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

Другой вариант - не запускать обновление Windows на веб-сервере и пытаться установить и dll 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 to 4.0.0.x? или можно просто удалить перенаправление привязки вообще?

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

Ответ 1

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