Какого уровня беспокойства я должен уделять развертыванию .NET framework 3.5 на производственном сервере приложений, на котором в настоящее время размещено около 20 приложений .NET framework 2.0?

Я столкнулся с сопротивлением моему запросу о развертывании .NET framework 3.5 в нашей среде. У нас нет возможности с уверенностью провести регрессионный тест, и у нас нет доступных ресурсов для уверенного тестирования каждого приложения.

Насколько я понимаю, .NET framework XX в качестве основной цели проектирования создан и доказал, что позволяет развертывать 1.0, 1.2, 2, 3, 3.5 и т. Д. На одном компьютере с высокой степенью уверенности в том, что взаимодействие между версии не сломают более легкую версию.

Я попытался найти «критические изменения», о которых сообщают в ИТ-сообществе, и до сих пор нашел очень мало примеров, и поэтому я склонен настаивать на развертывании этой среды выполнения с минимальным тестированием.

Каков уровень вашей предполагаемой озабоченности по поводу такого подхода к развертыванию .NET 3.5 в данной ситуации?

4
Karl Easterly 6 Авг 2009 в 21:47

5 ответов

Лучший ответ

Уровень моей озабоченности очень низкий. Единственный способ взаимодействия платформы 3.5 с существующими приложениями 2.0 - это использование пакета обновления для среды CLR 2.0 во время установки 3.5. А именно service pack1. Таким образом, после установки все ваши предыдущие приложения начнут работать в среде CLR 2.0SP1 по сравнению с CLR 2.0.

Так что действительно вопрос в том, насколько вы доверяете пакету обновления?

Вот ссылка на пакет обновления и список исправленных ошибок. Все исправления ошибок в некотором роде критически важны и могут повлиять на поведение приложения (иначе зачем это исправлять?).

4
JaredPar 6 Авг 2009 в 17:52

.Net 2.0 на самом деле является лишь подмножеством .Net 3.5.

Оба они построены на основе CLR 2.0.

3.0 Добавлены библиотеки Foundation (WF, WCF, WPF), а 3.5 было еще одним развертыванием дополнительных функций. В общем, у вас не должно быть абсолютно никаких проблем, если только вы не сделали что-то совершенно безумное на своих машинах.

0
Josh 6 Авг 2009 в 17:52

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

Но, при этом, основные компоненты среды выполнения .NET 3.5 такие же, как и в .NET 2.0. Версия 3.5 - это, по сути, .NET v2.0 с дополнительными библиотеками поверх.

Как вы говорите - фреймворки спроектированы так, чтобы сосуществовать довольно счастливо, так что все должно быть в порядке.

У нас, конечно, не было проблем с развертыванием в нашей живой среде.

Отказ от ответственности: все вышеперечисленное основано только на моем опыте - пожалуйста, не обвиняйте меня, если все пойдет не так! ; о)

0
Chris Roberts 6 Авг 2009 в 17:53

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

0
Tom A 6 Авг 2009 в 17:58

Несколько версий dotnet могут находиться на одном компьютере, и сборка dot net фактически содержит свою целевую платформу в своем манифесте. Следовательно, если приложение скомпилировано с версией 2.0 или более ранней, и у вас есть эта версия на вашем компьютере, тогда нет абсолютно никаких проблем. Это то, что в первую очередь нацелено на dotnet frame. Параллельное выполнение и устранение проблемы с DLL адом.

Однако восходящая совместимость никогда не была проблемой ... если сборка скомпилирована с версией 2.0, она будет отлично работать в более поздних версиях ... Однако, если что-то все же пойдет не так, вам нужно винить MS: P ..

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

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

0
S M Kamran 6 Авг 2009 в 18:06