Подводные камни при обновлении с Visual Studio 2005 до Visual Studio 2008

Проблема Только, с которой я столкнулся с Visual Studio 2008, заключалась в том, что она была довольно медленной, пока я немного ее не настроил. У меня была задержка при выходе из режима отладки порядка 8-10 секунд или около того - довольно раздражал. Выручил SP1 и внесение изменений в некоторые настройки IE.

Но в остальном я был доволен этим.

Если вы используете какие-либо плагины Visual Studio, у вас могут возникнуть проблемы с совместимостью - когда мы впервые перешли на него, еще не было версии Resharper, которая поддерживала бы 2008, так что в то время это была незначительная проблема. Кроме того, у нас действительно не было никаких проблем с самой IDE. При этом мы мало занимаемся C++, поэтому я не уверен, насколько может отличаться ваша ситуация.

Если подумать, единственная другая проблема, с которой мы столкнулись с коммутатором, заключалась в создании приложений .Net 3.5 с помощью nant. Вы не сказали, какие инструменты сборки вы используете или делаете ли вы какой-либо управляемый код, поэтому я не уверен, будет ли это проблемой для вас. Если это так, в сети есть несколько обходных путей, позволяющих заставить nant работать с приложениями 3.5, которые включают настройку файлов конфигурации nant. Дайте мне знать, если вы хотите, чтобы я опубликовал это.

Мы только что закончили обновление в прошлом месяце. Я не заметил замедления - но мы с самого начала запускали SP1. Мы допустили ошибку, установив бета-версию SP1 (бета для пакета обновления?!?!), И нам пришлось загрузить и запустить специальный инструмент для его удаления перед установкой RTM SP1, но это не должно повлиять на вас. Самая большая проблема заключалась в создании всех наших сторонних библиотек на 2008 год и получении пакетного процесса для обратного преобразования наших проектов и решений в версии 2005 года для одного из наших клиентов. О библиотеках - Microsoft говорит, что если у нее есть какой-либо C++ в общедоступном интерфейсе, ИЛИ использует STL внутри, то его необходимо перестроить с помощью нового компилятора. Я написал небольшой синопсис по мой блог.

Обновлено: вот конвертер проекта, который мы использовали. Я преобразовал его в приложение командной строки для нашего пакетного процесса, и оно работает очень хорошо.

Опыт обновления моей предыдущей компании был следующим:

• Мы испытали большую надежность, особенно с учетом того, что у нас были приложения, которые были сильно многопоточными и которые было сложно отлаживать.
• VS2008 был значительно быстрее и потреблял меньше оперативной памяти (по крайней мере, с решением с 50 проектами).
• Часть нашего кода C++ больше не будет работать в системах NT. Это можно решить, используя старый исполняемый файл editbin (например, из VS2003) для изменения двоичного файла как части события публикации.
• После обновления до VS2008 файл проекта также обновляется для этого. Поэтому, если вам нужно переключаться между двумя IDE (например, не все разработчики перешли), могут возникнуть проблемы.

Мы обнаружили, что это не совсем надежно; в большинстве случаев это нормально, но у некоторых из нас бывали дни, когда казалось, что он вылетает каждые пять минут. Честно говоря, это тоже немного глючит, например. есть странствующая ошибка с ресурсами, которую SP1 не исправил для нас.

Некоторая «генерация кода времени компоновки» включалась, по-видимому, автоматически во время миграции, и ИМО это слишком медленно. Время ссылки, увеличившееся с 30 секунд до 7 минут, было довольно сложно проглотить. Снова выключил ...

С другой стороны, отладка выполняется значительно быстрее, что является большим плюсом, когда у вас есть ошибка в некотором трудоемком коде. Однако мы не уверены в скорости сборки релизов.

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

Значительно повысилась надежность. Набор повседневных функций неизменен (как и должно быть).

Одна проблема, с которой я столкнулся, не подозревая об изменении (у меня тоже есть вопрос по нему) Установщики могут вести себя по-другому. Старое обновление было скорее удалением и переустановкой. Новый выполняет обновление на месте. Это может привести к проблемам:

1. необходимо поместить информацию о версии в библиотеки DLL - неплохо, но, возможно, это не шаг, который вы автоматизировали

2. из коробки служба не может автоматически обновляться, вам нужно заставить пользователя удалить старую, а затем установить новую (TODO: цитата для моего сообщения с вопросом, которое будет добавлено здесь)

Я столкнулся только с двумя проблемами.

1. Несколько сторонних надстроек не работали, когда мы впервые перешли на 2008 год с RTM. Я не помню, какие именно, но я не сталкивался с этим ни с одной из надстроек, которые мы сейчас используем.

2. Если вы используете Team Edition или Team Suite, существуют некоторые сторонние политики регистрации, которые не работают, поскольку они ссылаются на 2005 TFS API. Мы смогли обойти это, либо перекомпилировав с соответствующими ссылками на вещи, для которых у нас был код (например, вещи, извлеченные из CodePlex), либо переписав политики, поскольку они довольно просты.

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