Расследование ошибки установки Visual Studio 2015

Решили мы как-то перевести свой проект на Visual Studio 2015 — там ведь столько захватывающих фич! Вчера вот только решили, а уже сегодня утром я запустил её инсталлятор. Небо было безоблачным, ничто не предвещало беды. Ну что, в самом деле, может пойти не так? Сколько уже этих Visual Studio переставлено — не счесть (я, помнится, ещё 6.0 когда-то ставил). Кто бы мог подумать, что эта тривиальнейшая задача может вылиться в весьма неожиданный забег по граблям длинной почти в целый рабочий день.

Похрустев немного жестким диском, красивый инсталятор показал мне совершенно некрасивое сообщение об ошибке. Вот такое:

Хм. Не поставился значит, Team Explorer и ещё пару минорных пакетов. Ну ок. Закрываем, переустанавливаем. Не помогает. Удаляем студию, перезагружаемся, устанавливаем — та же ошибка. Лезем в Гугл с вопросом об ошибке установки Visual Studio 2015 на этапе инсталляции компонента Team Explorer и понимаем, что проблема это массовая — десятки ссылок с тем же описанием: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

Отвечают на все эти вопросы специалисты первой линии техподдержки Microsoft, советы которых сводятся к «отключите антивирус», «проверьте чексуму образа со студией», «проверьте диск на ошибки». Ничего из этого, конечно, не помогает, о чём им и рассказывают, после чего они пропадают и больше не отвечают. Очень дружелюбная пользовательская поддержка, ничего не скажешь.

Ну что же, пора включать голову, брать в руки инструменты и разбираться. Поехали. Итак, всё что у нас есть, это входная точка ошибки — проблема с Team Explorer. И ссылочка на лог-файл на приведённом выше скриншоте. Ну ок, давайте пойдём почитаем что там лог-файл думает о нашей ошибке.

Всё, что можно понять из этого лога, это то что компонент ставился-ставился, да что-то не поставился. Бывает, мол, чего уж там. Ну, спасибо большое за информацию!

Ладно, давайте зайдём с другой стороны. Team Explorer это (как и почти всё в современных версиях Visual Studio) — VSIX (компонент, расширение). Ставится отдельно от ядра студии специальной программой VSIXInstaller.exe, которая живёт в C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE и умеет при установке этих самых VSIX-компонентов писать во временную папку (ну, ту, которая %TEMP%) логи о том, как всё прошло. Идём в %TEMP%, находим по времени ошибки из лога выше файлик, соответствующий установке Team Explorer. Вот он:

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

26.11.2015 17:31:06 - System.TypeInitializationException: The type initializer for 'VSIXInstaller.SupportedSKUs' threw an exception. ---> System.BadImageFormatException: Could not load file or assembly 'Microsoft.VisualStudio.Settings.14.0.dll' or one of its dependencies. is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)

Хм, произошла ошибка при попытке загрузить сборку Microsoft.VisualStudio.Settings.14.0.dll. Первой моей мыслью было то, что студия как-то запуталась в порядке установки своих компонентов и пытается использовать при установке что-то, что ещё не установилось куда надо. Так, есть у нас в системе такая библиотека?

Оказалось — есть. Лежит в GAC, там где ей и положено лежать:

Так, что же получается? Сборка есть, она находится там, где нужно, но не загружается. Может быть, битая? Берём IL DASM, загружаем — всё ок.

Может быть умельцы из Microsoft сумели написать такой инсталлятор, у которого иногда получается не найти сборку в GAC? Берём Process Monitor, добавляем в него фильтр на открытие файлов и снова запускаем инсталлятор студии. Доходим до ошибки, смотрим логи.

Так, инсталлятор ищет Microsoft.VisualStudio.Settings.14.0.dll и находит её ровно там, где она и должна быть — в GAC. Ок, что же не так? Читаем ещё раз сообщение об ошибке: «System.BadImageFormatException: Could not load file or assembly 'Microsoft.VisualStudio.Settings.14.0.dll' or one of its dependencies. is not a valid Win32 application.». Так, если сама Microsoft.VisualStudio.Settings.14.0.dll есть и валидна — может быть дело в одной из её зависимостей? Возвращаемся в Process Monitor и смотрим что там загружается непосредственно после нашей сборки.

Ага, vcruntime140.dll загружается. Это redistributable-библиотека от Visual Studio 2015. Ну, она-то точно должна была поставиться на одном из первых этапов установки! Но давайте проверим, чем уже чёрт не шутит.

Проверка раз — в списке установленных программ:

Проверка два — в папке C:\Windows\SysWOW64\:

Проверка три — это, собственно, «SUCCESSS» в логе Process Monitor:

Последняя проверка — вообще железобетонный аргумент: видите, поискали, попробовали открыть, открылось успешно — значит файл найдён. Всё, подозрения снимаются, идём дальше. Так, какую-же библиотеку инсталлятор VSIX пытается подгрузить следующей по логами Process Monitor?

Как это опять vcruntime140.dll уже в другой папке?! Получается, найдя vcruntime140.dll в папке C:\Windows\SysWOW64\ и успешно её открыв (а мы знаем что так и было по логам выше!) загрузчик зависимостей всё-же почему-то счёл её недостаточно хорошей и отбросил. Как же так?! Это что — не майкрософтовская библиотека? Смотрим свойства:

Да нет, нормальная библиотека. Почему же не загрузилась? Давайте посмотрим на неё внимательнее. Для этого в составе любой версии Visual Studio есть отличная утилита dumpbin. Запускаем её с вот такими ключами:

и смотрим на результаты:

Подождите-подождите… А почему это ты, библиотечка, 64-битная?! Ты же лежишь в папке C:\windows\SysWOW64\, где вообще-то место только 32-битным библиотекам! А ну-ка давайте посмотрим, что же тогда лежит в C:\Windows\System32?

А то же самое (кто не верит в размер — можете проверить каким-нибудь WinMerge, они идентичны). Вы уже уловили, в чём суть? Ошибка закралась в инсталятор Redistributable-компонентов, входящий в инсталятор Visual Studio 2015 — он просто ставит 64-битные версии рантайм-библиотек и в папку для 64-битных библиотек (C:\Windows\System32) и в папку для 32-битных (c:\windows\SysWOW64\). В итоге при дальнейшей попытке использования 64-битной версии всё будет ок, а вот при попытке загрузки 32-битной версии будет то, что мы увидели при установке Team Explorer — загадочные ошибки вообще без упоминания библиотеки vcruntime140.dll и Redistributable-пакета. И делай, что хочешь.

А что же мы хотим делать? А удалить x86-часть Redistributable-пакета Visual Studio 2015, скачать её отдельно с сайта Microsoft и переустановить. Сюрприз — на сайте Microsoft версия правильная, она установит 32-битную версию библиотеки в C:\windows\SysWOW64, после чего можно перезапустить установку Visual Studio 2015 и она успешно дойдёт до конца!

Осталось как-то объяснить начальству почему это я целый день устанавливал Visual Studio, если с этим дети в третьем классе за час справляются. В общем-то ради этой цели и была написана данная статья, а уж зачем вы её прочли — я не знаю :)