Какие проблемы возникают при ретаргетинге .net 2.0 на 3.5?
В настоящее время я работаю над проектом, который повсеместно переходит с .NET 2.0 на 3.5.
Мне хорошо известно, что 3.5 - это в основном набор дополнительных функций (библиотек, если хотите) поверх того, что предлагает 2.0.
Есть ли какие-то ошибки, которые я мог бы решить, просто перенастроив компилятор на 3.5?
Ответы 5
Неа
3.5 полностью совместим с 2.0, а не наоборот
Недавно я перенес небольшой проект с 2.0 на 3.5 и особых проблем не обнаружил, так как версия фреймворка обратно совместимы. Тем не менее, существует множество оптимизаций и улучшений, которые можно сделать, воспользовавшись преимуществами доступных функций в более поздних версиях фреймворка. Вы можете получить некоторые предупреждения об устаревших функциях, но ничего, что остановит компиляцию вашего проекта.
Помимо этого, некоторым пользователям приложения придется загрузить новую среду выполнения, о которой я не знаю.
Это не ошибка, это скорее предупреждение. .NET v3.0 и v3.5 - это не новые среды CLR, а просто добавленные сборки, компиляторы, ресурсы и т. д.
Как .NET v3.0, так и v3.5 используют среду CLR v2.0. Из-за этого вы не сможете сказать, установить пул приложений IIS для использования CLR v3.5 ... потому что он не существует.
Обсуждается более подробно здесь: http://www.hanselman.com/blog/HowToSetAnIISApplicationOrAppPoolToUseASPNET35RatherThan20.aspx
Единственная проблема, которую я видел, - это конфликты имен. Вам нужно будет устранить двусмысленность любых имен классов или методов в вашем коде, которые имеют общие имена с теми, которые добавлены в структуру .net между .net 2.0 и 3.5.
Вопрос ... Значит, я мог технически использовать Telerik Rad Controls для ASP.NET AJAX и запускать это поверх приложения ASP.NET 2.0?