Какой опыт при переходе на VS10?

Question

Мы думаем об обновлении очень большого продукта до VS10.

Я слышал много хорошего о VS10 и очень рад новым возможностям C ++ 0x, когда играю сVS10 У меня был один случай, когда пример игрушечного приложения зависал (чего не было в VS8), и один случай, когда, похоже, есть ошибка компилятора в некоторых функциях C ++ 0x .

В другом случае я вижу, что unorderd_map выдает исключение bad_alloc, где это не делает в VS9 .

Наш продукт состоит из собственного C ++ и.NET и составляет несколько миллионов строк кода.У кого-нибудь есть опыт миграции аналогичного проекта на VS10?Был ли процесс болезненным?и были ли какие-либо регрессии, вызванные переездом?

Я ищу дополнительные неподтвержденные доказательства, поскольку все отзывы, которые я нашел в Интернете, были хорошими и не соответствовали моему опыту.

Answer 1

У нас также есть похожий крупный проект. У меня не было счетчика строк кода, но я бы предположил, что его легко найти миллион. Есть около 200 проектов - около 140 с ++ проектов, все с использованием 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 перед DLL-библиотекой .NET (скажем, потому что вы вызываете ее), вы не можете полагаться на работу порядка сборки! Нам пришлось вручную редактировать файл .csproj проекта .NET и вставлять в него «ссылку» на собственный проект. Это заставляет VS выдавать предупреждение компилятора, но это единственный способ заставить его строить вещи в правильном порядке

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

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

.NET:

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

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

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

• Замечательно исправить не размытый текст в WPF. Какого чёрта они годами отправляли с рендером с битым текстом, я никогда не узнаю.

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

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

Answer 2

@ Орион Эдвардс

Вы знаете, как вы щелкаете правой кнопкой мыши на выберите «Зависимости» и поставьте галочки для зависимостей? Это все еще влияет на строительство в VS2010, но MSBuild не обращает на это внимания.

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

Спасибо - Дэн / msbuild.

Answer 3

Лучшая функция в VS2010 для c ++, кроме функций c ++ 0x, заключается в том, что вы можете легче отключить intellisense.Теперь это встроенная опция.

Вы даже можете указать intellisense только для анализа и индексирования файлов, которые появляются в вашем решении.Таким образом, если вы добавляете заголовок надстройки или просто огромную базу кода, он не пытается проиндексировать его и вылетает, как в VS2008 и 2005.

Answer 4

Несмотря на то, что я перенес только небольшое собственное приложение C ++ (~ 100 000 строк) в Visual Studio 2010, мне еще не приходилось сталкиваться с ошибками компилятора.

По моему опыту (как с этим приложением, так и с другими более крупными приложениями), обновление до последней версии Visual Studio стоит времени и усилий.Visual C ++ улучшается с каждым выпуском, поэтому риск появления новых ошибок компилятора обычно компенсируется улучшениями компилятора, соответствием стандартам и средой разработки.

Answer 5

Две вещи, которые раздражали меня как часть движения:

1. Управляемые проекты c ++ вынуждены ссылаться на среду .Net 4, если вы используете инструменты VS2010 (вы можете поиграть за кулисами и оставить инструменты VS2008, чтобы ориентироваться на .Net 3.5 и т. Д.)

2. Что-то было смешно с путями вывода в моих управляемых DLL-библиотеках c ++, которые заставили их иметь путь \ путь, а не путь \ путь в файлах проекта. Это привело к тому, что VS2010 не сможет использовать библиотеки DLL в качестве ссылок на другие проекты.

Оба они не показывали мне пробок, но были неожиданны, когда я обновил свои проекты.