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

Вы должны стрелять по-крупному и ставить 3,5. Вода здесь niiiiiiice.

Вероятно, у вас не будет проблем с ломка, хотя вы можете получить некоторые предупреждения об устаревших методах. Компилятор обычно должен сказать вам, что это за замена. Я знаю, что кое-что из System.Configuration было обновлено.

Больше всего предупреждений о компиляции вы увидите, если вы используете app.config для хранения настроек программы. Класс конфигурации 1.1 объявлен устаревшим для System.Configuration.ConfigurationManager.

Другие предупреждения, которые вы можете увидеть от компилятора, будут относиться к неинициализированным переменным (установите для них значение «= ничего» или «= null;» в объявлении переменной, чтобы они исчезли) и неиспользуемым переменным (компилятор уверен, что они безопасно удалить).

Взгляните на этот белая бумага по развитию приложения .NET 2.0 до 3.5. Я считаю, что изменения с 1.1 на 2.0 более значительны, но процесс должен быть аналогичным.

Большая часть кода все еще должна компилироваться, за исключением нескольких предупреждений о том, что что-то устарело.

Но есть несколько вещей, на которые вы должны обратить внимание в отношении кода, сгенерированного Visual Studio.

Если вы создали строго типизированные наборы данных в Visual Studio 2003, вы можете забыть о редактировании их в новых версиях Visual Studio. Вам придется перестроить их или лучше просто заменить их чем-то вроде nHibernate для окончательного OR-mapper-bliss

Дизайнер форм по-прежнему должен работать со старыми формами. Вы можете получить некоторую путаницу, потому что 2005 и 2008 здесь используют частичные классы. Поэтому, если вы создаете новые формы, код будет отличаться от старых. Я никогда не обновлял приложение ASP.Net, поэтому я не знаю о веб-формах, но думаю, что они будут работать так же, как файлы winforms. В основном это сработает, но ожидайте некоторых дизайнерских странностей.

Мы планируем провести такую ​​же миграцию прямо сейчас, Тоби. Во-первых, вы можете получить хорошее представление о том, чего ожидать, сделав копию своего проекта (или его части) и выполнив «пробный запуск» через компилятор .NET 2.0. По моему опыту, компилятор 2.0 выдает больше предупреждений о плохих методах программирования, которые компилятор 1.1 не допускает. Компилятор предупредит вас о неявном приведении типов, «неоднозначных» путях возврата (путь кода, в котором функция не возвращает значение) и некоторых других незначительных вещах.

Вот несколько ссылок, которые могут быть вам полезны: Совместимость с .NET Framework

Документ Word о критических изменениях в .NET Framework 2.0

В дополнение к упомянутым выше настройкам приложения, если вы используете какую-либо проверку XSD, вам нужно будет заменить некоторый код, связанный с загрузкой и проверкой XML.

.NET 1.1 и .NET 2.0-3.5 - это совершенно разные фреймворки, и, что более важно, .NET 3.5 - это просто набор дополнительных сборок, которые вы можете добавить в свой проект .NET 2.0 - ни одна из основных сборок фактически не изменилась, поскольку Я знаю - и обновленный компилятор, который знает о синтаксическом сахаре под названием LINQ, методах расширения и т. д.

Другими словами, я не думаю, что обновление .NET 2.0-3.5 очень похоже на обновление .NET 1.1-2.0.

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

В этой статье все об этом говорится: http://odetocode.com/blogs/scott/archive/2005/12/14/2618.aspx

Скорее всего, все будет скомпилировано, но у нас было несколько неприятных проблем во время выполнения с приложением, которое мы обновили в начале года.

Во-первых, у нас был ряд проблем с обработкой часовых поясов в объектах DateTime при вызове веб-сервисов 1.1 из приложения 2.0, поскольку преобразования в и из UTC при сериализации в сеть, по-видимому, работали по-разному в разных версиях платформы.

Кроме того, асинхронные веб-службы 2.0 используют неуклюжий механизм на основе событий вместо шаблона IAsyncResult, что очень неприятно, если вы группируете свои запросы.

Наконец, у нас был устаревший код, в котором размещался встроенный браузер с использованием Microsoft.mshtml.dll. Обновление до 2.0 привело к тому, что приложение автоматически переключилось на более новую версию этой dll, в которой было несколько изменено поведение, связанное с взаимодействием с javascript. Последний случай немного неясен, но показывает, что переход на более новую среду выполнения может иметь последствия для любого взаимодействия с COM, которое может у вас возникнуть.

Надеюсь это поможет!

То, как мы работали с электронной почтой, пришлось изменить. Версия 1.1 использовала system.WEB.mail, с

    Imports System.Web.Mail
    '
    Dim message As New MailMessage' this is a web.mail msg, not a net.mail msg
    Dim objConn As SmtpMail
    Dim objAttach As MailAttachment
        '
    message .From = "[email protected]"
       ' more properties assigned to objMail
    objAttach = New MailAttachment(ExportName)
    message.Attachments.Add(objAttach)
       ' Here's where we actually send the thing
    SmtpMail.SmtpServer.Insert(0, "127.0.0.1")
    objConn.Send(objMail)

а в новой есть system.NET.mail

         Imports System.Net.Mail
        '
         Dim message as MailMessage ' this is a net.mail msg, not a web.mail msg
         Dim data As Attachment
        Dim client As New SmtpClient("127.0.0.1")
    '
        data = New Attachment(ExportName)
    ' Create the message and add the attachment
        message = New MailMessage(EmailFrom, EmailTo, reportDescription)
        message.Attachments.Add(data)
' Send the message
        client.Send(message)

Проблемы с обновлением файлов RESX

Остерегайтесь интернационализированных файлов RESX.

Когда вы повторно открываете форму net 1.1 в .net 2.0, файл RESX обновляется до новой версии. В .net 1.1 файл .resx на иностранном языке содержал только изменения. В .net 2.0 ВСЕ поля в файле .resx по умолчанию теперь перемещаются в файл resx на иностранном языке. (например, .fr.resx). Если вы уже интернационализировали форму, необходимо просмотреть все файлы resx на иностранном языке.

Инструменты интернационализации

Некоторые инструменты, которые вы, возможно, использовали / написали сами для массовой интернационализации, могут больше не работать, поскольку они могли использовать нумерованные ресурсы. (Multi Lang & Infragistics)

Элементы управления Infragistics Winforms изменяют InitializeForm () в .net 1.1 и получают доступ к ресурсам с помощью системы нумерации ресурсов. При миграции на .net 2.0 нумерация ресурсов Infragistics завершится ошибкой, так как файл resx будет регенерирован. Вам нужно будет обновить свои библиотеки Infragistics.

Не должно быть особых проблем, поскольку теоретически он обратно совместим (я обращаю внимание на комментарий Майка Майка об исключениях потоков). После переезда, вы в порядке, есть немало приятных вещей, например, дженериков. Хотя вы не хотите переносить все свои коллекции в дженерики одним махом, как только вы это сделаете, ваш код станет более надежным из-за меньшего количества приведений - и, вероятно, быстрее (хотя в этом аспекте пробег может отличаться) . В настоящий момент я собираюсь начать преобразование трех моих продуктов из .NET 2 в .NET 4. Основным преимуществом будет дальнейшее улучшение многопоточной поддержки (параллельные циклы foreach и т. д.).