Сосуществование нескольких версий платформы выполнения на одной машине

Современные приложения почти никогда не несут в себе всё необходимое для работы. Многие из них опираются на платформу выполнения - набор библиотек и сред, который ставится в систему отдельно и предоставляет программам общую базу. Одно приложение требует одну версию этой платформы, другое - совсем иную, и на типичной рабочей машине нередко уживаются сразу несколько версий бок о бок. Понимание того, как они сосуществуют, как узнать установленное и как управлять версиями, избавляет от целого класса загадочных отказов запуска.

Корень сложности в том, что версии платформы выполнения не всегда взаимозаменяемы. Программа, собранная под конкретную версию, ждёт именно её и не всегда готова работать на более новой. Поэтому удалить старую версию, понадеявшись, что свежая её заменит, бывает рискованно: зависящие от старой версии приложения после этого перестанут запускаться. Грамотное управление версиями - это не гонка за установкой самой новой, а аккуратное поддержание того набора, который реально нужен установленным приложениям.

Почему версии платформы уживаются параллельно, а не вытесняют друг друга

Разработчики платформы выполнения предусмотрели параллельное сосуществование версий не случайно. Будь версии взаимоисключающими, установка новой ломала бы все приложения, рассчитанные на старую, и обновление превращалось бы в катастрофу. Вместо этого каждая версия ставится в свой отдельный каталог и не трогает соседей. Среда выполнения, ядро платформы и сопутствующие компоненты раскладываются по подкаталогам, и внутри каждого лежит каталог под конкретную версию.

Такое раздельное хранение и есть основа параллельной работы. Когда приложение запускается, система смотрит, какая версия ему нужна, и подбирает подходящую из установленных, обращаясь к нужному каталогу. Программа под старую версию получает свою, программа под новую - свою, и обе работают одновременно на одной машине, не мешая друг другу. Удаление какой-либо версии сводится к удалению её каталога, после чего эта версия исчезает из системы, а остальные остаются нетронутыми.

Тонкость в том, что компоненты, установленные одним выпуском платформы, могут иметь разные версии между собой. Установив, к примеру, среду для веб-приложений определённого поколения, можно получить одну версию одного компонента и слегка иную версию другого, и у каждого будет свой каталог. Поэтому при разборе установленного важно смотреть не на общее впечатление, а на конкретные версии конкретных компонентов, ведь именно их сверяет с собой запускаемое приложение.

Как узнать, какие версии платформы установлены

Прежде чем что-то менять, нужно увидеть текущую картину. Для платформы выполнения есть штатные команды, которые перечисляют установленное. Три команды покрывают потребности: одна выводит установленные комплекты разработки, другая - установленные среды выполнения, третья показывает всё сразу с дополнительными сведениями. Для задачи управления версиями важнее всего список сред выполнения, ведь именно они нужны для запуска готовых программ.

dotnet --list-runtimes
dotnet --list-sdks
dotnet --info

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

Полученный список сопоставляют с требованиями приложений. Если программа жалуется на отсутствие платформы определённой версии, а в списке этой версии нет, ответ очевиден: нужную среду выполнения надо доустановить. Если же версия есть, а приложение всё равно капризничает, дело может быть в разрядности или в типе среды - например, настольному приложению нужна именно настольная среда выполнения, а не серверная или базовая.

Установка нужной версии среды выполнения

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

dotnet-sdk-9.0.100-win-x64.exe /install /quiet /norestart

Эта команда молча ставит указанную версию комплекта разработки. Установщик возвращает код выхода ноль при успехе и код 3010, когда для завершения нужна перезагрузка - те же коды, что и у других системных установщиков, поэтому скрипт обрабатывает их привычным образом. Если у установщика есть ключ установки, то по аналогии у него есть и ключ удаления конкретной версии, и ключ восстановления, проверяющий и чинящий повреждённые файлы установки.

dotnet-sdk-9.0.100-win-x64.exe /repair /quiet /norestart

Ключ восстановления полезен, когда версия вроде бы установлена, но работает с ошибками: он сверяет ключевые файлы и компоненты установки и заменяет повреждённые. Помимо прямого запуска установщика, версии платформы удобно ставить и обновлять через менеджер пакетов системы, который умеет тянуть нужную версию из доверенного источника и накатывать ежемесячные исправления вместе с обновлением самой платформы.

Удаление лишних версий без поломки приложений

Накопившиеся старые версии со временем занимают место, и возникает соблазн их вычистить. Делать это нужно осторожно, предварительно убедившись, что удаляемая версия никому не нужна. Удаление сводится либо к запуску установщика с ключом удаления, либо, при ручной установке, к удалению каталога соответствующей версии, после чего эта версия пропадает из системы.

Перед удалением стоит свериться со списком установленного и подумать, какие приложения могли опираться на эту версию. Если в системе есть программа, рассчитанная именно на удаляемую среду выполнения, после удаления она перестанет запускаться с жалобой на отсутствие платформы. Поэтому безопасное правило простое: удаляют только те версии, которые заведомо не требуются ни одному установленному приложению, а в сомнительных случаях оставляют как есть, благо параллельное хранение позволяет версиям мирно сосуществовать.

Отдельно стоит история с платформой, встроенной в саму систему. Часть платформенных компонентов в современных версиях Windows является частью операционной системы и не удаляется отдельно - их обновления приходят вместе с системными и отображаются среди установленных обновлений, а не как отдельная программа. Пытаться удалить такой встроенный компонент бессмысленно и даже вредно, в отличие от отдельно установленных версий, которыми управляют свободно.

Разрядность, типы сред и совпадение версий

Помимо номера версии у платформы выполнения есть ещё два измерения, которые часто становятся источником путаницы. Первое - разрядность: на 64-разрядной системе могут понадобиться и 64-, и 32-разрядные среды выполнения, в зависимости от разрядности приложений. Программа определённой разрядности ищет среду той же разрядности, и наличие только одной из них оставляет приложения другой разрядности без поддержки.

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

Чтобы не блуждать вслепую, разбор требований приложения удобно вести по понятному порядку:

1. посмотреть, какую версию платформы требует приложение, обычно это указано в его документации или в тексте ошибки;
2. определить нужный тип среды выполнения, отделив настольную от базовой и серверной;
3. учесть разрядность приложения, чтобы поставить среду совпадающей разрядности;
4. сверить требуемое с установленным через команду списка сред выполнения;
5. доустановить недостающую версию нужного типа и разрядности, не трогая остальные;
6. перепроверить список после установки и убедиться, что приложение запускается.

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

Две линейки платформы и проверка установленного через реестр

Источником изрядной путаницы служит то, что под именем платформы выполнения у Microsoft уживаются две разные по устройству линейки. Старшая - классический Framework, глубоко встроенный в Windows и десятилетиями обслуживавший оконные приложения. Младшая - современная кроссплатформенная линейка, которая ставится отдельными версиями и сосуществует параллельно так, как описано выше. Команды просмотра вроде списка сред выполнения относятся именно к современной линейке, а классический Framework живёт по своим правилам.

Различие принципиально для управления. Современные версии ставятся и удаляются по отдельности, каждая в своём каталоге, и ими управляют свободно. Классический же Framework в актуальных версиях Windows является частью операционной системы, обновляется вместе с ней и не удаляется как отдельная программа. Попытка применить к нему логику параллельных каталогов ни к чему не приведёт, потому что устроен он иначе: внутри одной крупной версии новые выпуски надстраиваются поверх прежних, а не ставятся рядом.

Узнать, какая версия классического Framework установлена, через команды современной линейки не получится - нужен другой путь. Сведения о нём хранятся в реестре, в специальном разделе, где лежит числовой параметр выпуска, по значению которого определяется конкретная версия. Этот способ полезен, когда приложение требует классический Framework определённой версии, а команды современной линейки о нём молчат. Заглянув в нужный раздел реестра, администратор видит установленный выпуск и понимает, хватает ли его приложению или нужно доставить обновление, приходящее через системный центр обновлений.

Что отличает зрелое управление версиями платформы

Главная мысль проста: версии платформы выполнения - это не лестница, по которой надо непременно карабкаться вверх, а набор инструментов, который держат под нужды конкретных приложений. Самая новая версия не обязательно лучшая для данной машины; лучшая та, что соответствует тому, что на машине реально работает. Параллельное сосуществование версий существует именно для того, чтобы не приходилось выбирать между старым и новым приложением.

Зрелый администратор не удаляет версии из эстетического желания навести порядок, а оставляет ровно тот набор, что нужен установленному софту, плюс рекомендованную ветку с длительной поддержкой как надёжную базу. Он знает, как посмотреть установленное, как доставить недостающее и как безопасно убрать лишнее, не обрушив зависящие приложения. И он различает отдельно установленные версии, которыми управляет свободно, и встроенные в систему компоненты, которые трогать не следует.

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