Я начал использовать Visual Studio 2008, и он продолжает просить меня обновить проект веб-сайта 2.0 до 3.5 каждый раз.
(Как уже упоминалось в других ответах, а также некоторые дополнительные функции:)
Преобразование решения VS 2005 в VS 2008 будет означать, что вам нужно будет поддерживать дубликаты, или другие должны также использовать Visual Studio 2008 (в то время как формат файла проекта (который из вашего вопроса, который вы не используете в любом случае) теоретически не меняется в период с 2005 по 2008 год, файлы решений несовместимы...)
Преобразование веб-сайта в 3.5 в основном влияет на web.config. Некоторые ссылки добавляются к нескольким сборкам по умолчанию 3.5, таким как System.Core.dll. И он добавит разделы IIS 7 (которые игнорируются, если сайт опубликован в ящике IIS6).
Как правило, не вижу новых ошибок компиляции во время обновления (и если да, то не ожидали бы многих). Обе команды С# и VB приложили усилия для обеспечения обратной совместимости во всех новых ключевых словах LINQ... так что вы можете иметь локальное имя "var" в методе "where" в классе с именем "from", и все компилируется просто отлично... (улучшение для тех, у кого были символы с именем "operator" в кодовой базе VB 2003 при обновлении до 2005 года: -)
Очевидно, что после переключения вы будете использовать .NET 3.5 на любом сервере, на котором вы развертываете. В отличие от .NET 1.1 vs .NET 2.0, нет проблем с CLR-версией/AppPool, о которых нужно беспокоиться, все это работает в .NET 2.0. Читайте ниже...
Если вы беспокоитесь о регрессии во время выполнения для любого существующего кода .NET 2.0, есть хорошие новости и плохие новости.
Хорошие новости: регресс практически не слышен.
Плохая (или другая хорошая) новость: если вы установили .NET 3.5 на сервер с 2.0 сайтами, вы уже опробовали регрессии:)
Как уже упоминалось выше,.NET 3.5 - это просто CLR.NET 2.0 с некоторыми дополнительными сборками и новыми возможностями компилятора.
И когда вы устанавливаете .NET 3.5, он также устанавливает пакет обновления для .NET 2.0 и 3.0. Таким образом, любое изменение изменения уже повлияет на веб-сайты .NET 2.0 без какого-либо явного шага обновления.
Скотт Ханзельман опубликовал хорошее объяснение разницы между версией CLR и версией .NET Runtime здесь некоторое время назад.Один заключительный комментарий - вы должны знать, что при использовании VS 2008 для целевой .NET 2.0 вы фактически компилируете против обновленного .NET 2.0. Поэтому, если вы используете один из (очень немногих и редко используемых) методов, который тихо добавляется к обновленной версии .NET 2.0, например GCSettings.LatencyMode, при развертывании на машине с исходным RTM.NET 2.0 она будет не работает. Читайте об этом более подробно здесь, а Скотт также опубликовал полный список API меняется здесь)
В то время как на самом деле проблема с подобной ситуацией довольно маловероятна, в некотором роде (даже исключая преимущества новых функций 3.5) вам лучше работать на 3.5:-)
Он обновляет ваш web.config, чтобы использовать несколько новых DLL. Я еще не испытал никаких изменений.
Как я понимаю,.NET 3.5 представляет собой .NET 2.0 с некоторыми дополнительными библиотеками для новых функций, таких как LINQ. Таким образом, вы должны иметь возможность плавного обновления.
Есть ли потенциал для любых 2.0 методов/настроек для BREAK при обновлении до 3.5?
Там всегда есть потенциал для поломки, но я предлагаю вам вернуться ко всему и отложить его раньше, чем позже. Если вы продолжаете откладывать это, вы обнаружите, что это намного более болезненно, когда у вас есть несколько версий изменений API каркаса, чтобы компенсировать это.
Если вы обновляете тип проекта, он просто обновляет файлы .csproj/.vbproj для работы с новой версией. Вы можете установить целевую базу кода внутри параметров проекта, чтобы сохранить функциональность в старых версиях рамок.
Если в мастере обновления вы решили не нацелить свой код на 3.5, ничто из вашего приложения не изменится. Основное различие заключается в том, что он будет "визуально-изучать" ваши файлы решений и проектов, чтобы они потенциально не могли быть открыты с помощью более старой среды разработки.
Все изменения будут внесены в файл web.config. Он становится ОГРОМНЫМ с новыми настройками для сборщиков .NET 3.5, обработчиками AJAX и настройками конфигурации IIS7. Но в Интернете есть множество документов, описывающих различия.
Я обновил несколько проектов таким образом и не имел никаких изменений. В качестве эксперимента я сделал это в проекте, который остальная часть моей команды использовала на VS2005, а также не испытывала никаких проблем, хотя я не стал проверять файл решения (который мы сохраняем локально как вопрос политики).
Результаты были прозрачными для всех, с добавленным бонусом к возможности использовать различные версии .Net.