Каков опыт при перемещении в VS10?

У нас тоже есть похожий большой проект. Я не запускал счетчик строк кода, но думаю, что легко миллион. Существует около 200 проектов - около 140 проектов на C ++, все с использованием COM / DCOM и 60 с лишним .NET с различными комбинациями Winforms / WPF / и т. Д. У нас много COM-взаимодействия и PInvoke

. Ранее мы использовали VS2008 для C ++ / C # и ориентировались на .NET framework 3.5SP1, а теперь перешли на VS2010 для C ++ и нацелены на .NET 4.

Общие впечатления:

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

• Лично я считаю VS2010 лучше, чем 2008, но это не такое серьезное обновление. Преимущества проистекают из улучшений языка (C ++ 0x и .NET / C # 4)

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

• Это исправляет несколько досадных вещей, таких как диалог добавления ссылки, и глупо долгое время, которое он использовал для отображения контекстных меню в проектах.

• IDE вылетает намного реже, чем в 2008 году, но все же вылетает каждые пару дней.

• Новые надстройки VS2010 довольно удобны

• «Поддержка нескольких мониторов» - это не такая уж большая «поддержка». Вы можете разместить множество окон с одним кодом за пределами IDE, но вы не можете стыковать их вместе. В основном вы получаете вкладки на основном экране и множество плавающих окон на дополнительном экране, что бесполезно.

• ClickOnce все еще отстой!

• Вам не нужно обновлять свой сборочный компьютер. Просто установите на него VS2010 и настройте конфигурацию TFSBuildService, чтобы он знал о .NET 4

C ++

• . НЕ устанавливайте надстройку «Power Commands». Он портит IDE при работе с проектами на C ++. (в основном это заставляет среду IDE терять и получать фокус примерно 100 раз в секунду, что означает, что вы не можете правильно выбирать текст или использовать сочетания клавиш)

• Формат проекта C ++ изменился с .vcproj на .vcxproj. Мастер обновления проекта Visual Studio позаботится о большинстве вещей, но он потерял несколько шагов до и после сборки, которые нам пришлось вручную вернуть на место.

• Вы можете использовать VS2010 и по-прежнему использовать компилятор VS2008 C ++. Изначально мы сделали это после переноса проектов, поскольку были осторожны. Переход на компилятор VS2010 не представлял большого труда, поэтому мы сделали это через день или два - он выдал нам несколько утверждений из STL, но это все равно было технически некорректно, поэтому мы просто исправили их.

• Основная проблема, с которой мы столкнулись при обновлении проектов C ++, заключается в том, что зависимости проектов теперь хранятся в файлах .vcxproj, а НЕ в решении.Вы знаете, как вы щелкаете правой кнопкой мыши по проекту, выбираете «Зависимости» и устанавливаете флажки для зависимостей? Это по-прежнему влияет на сборку в VS2010, но MSBuild не обращает на это внимания . Это означает, что ваши сборки машины почти наверняка сломаются, потому что порядок сборки будет неправильным. Вы должны открыть страницу свойств проекта,выберите «Framework and References» и вместо этого поместите туда зависимости.

• Это также означает, что если вам нужно создать чистую родную DLL перед .NET dll (скажем, потому что вы ее вызываете с помощью PInvoke), вы не можете полагаться на работающий порядок сборки! Нам пришлось вручную отредактировать файл .csproj проекта .NET и вставить «ссылку» на собственный проект. Это заставляет VS вывести предупреждение компилятора, но это единственный способ заставить его строить вещи в правильном порядке

• auto в C ++ 0x - это колени пчелы.

• Компилятору VS2010 C ++ для компиляции нашего кода требуется почти столько же времени, что и компилятору 2008 года.

.NET:

• Обновление проектов C # не является событием. Большинство проблем, которые у нас были, были связаны с конфликтами, когда мы сами вручную перенесли некоторые классы (например, Tuple) и должны были удалить обратные порты.

• .NET 4 удивительно рад загружать старый код .NET 3.5. Один из наших разработчиков сделал кастомный форк всего кодового комплекса WPFToolkit (не спрашивайте, вздох). Microsoft включила этот инструментарий в ядро ​​.NET в версии 4.0. Я думал, что у нас будет тонна конфликтов из-за этого, но мы только что загрузили разветвленную dll инструментария, и все заработало без проблем.

• Досадным исключением из этого правила являются модульные тесты. Вы можете создавать приложения .NET в 2010 году, которые будут нацелены на v2,3 или 3.5 платформы .NET, но Visual Studio может только загружать проекты модульных тестов, ориентированные на .NET 4. Если вы используете Благодаря встроенному модульному тестированию Visual Studio это означает, что вам не нужно использовать множественный таргетинг.

• Отлично исправить нечеткий текст в WPF. Я никогда не узнаю, какого черта они годами поставляли с неработающим средством визуализации текста.

• Они ужесточили некоторые аспекты взаимодействия с COM. У нас было несколько проблем, когда .NET выдавал ошибку, потому что соглашение о вызовах в наших сигнатурах pinvoke было неправильным - 3.5 незаметно исправит это за вас. Однако это легко исправить

Если у вас есть еще вопросы, не стесняйтесь спрашивать: -)