Управляемые .NET установки на Windows

Частично удаленные .NET установки являются распространенным причиной, по которой сканирование уязвимостей, например Управление уязвимостями Microsoft Defender будет сообщать об устройстве. Понимание того, как работают .NET установки, могут помочь администраторам в изучении отчетов и принятии исправлений.

В Windows .NET компоненты, такие как среда выполнения и пакет SDK, состоят из нескольких MSIs. Отдельные MSIs не распределяются напрямую. Вместо этого они объединяются для создания пакетов.

Получение .NET на Windows

• Автономные пакеты (EXEs) можно скачать на веб-сайте .NET.
• WinGet предоставляет пакеты, содержащие пакеты .NET.
• Обновления обслуживания распределяют пакеты через обновление Microsoft с помощью автоматических обновлений, WSUS и каталога клиентский компонент Центра обновления Windows.
• Независимые поставщики программного обеспечения (НЕЗАВИСИМЫе поставщики программного обеспечения) могут распространять пакеты .NET в рамках своего программного обеспечения.
• Изготовители оборудования иногда включают предварительно установленные копии пакетов .NET в образы фабрики новых устройств.
• Некоторые Azure образы Marketplace Windows включают предварительно установленные копии пакетов.
• Сторонние менеджеры пакетов, такие как Chocolatey, также распределяют пакеты .NET.
• Предприятия иногда перепаковывать пакеты с помощью собственных пакетов для внутреннего распределения.
• Некоторые узлы приложений .NET могут также направлять пользователей на скачивание и установку отсутствующих пакетов среды выполнения.

Visual Studio также можно использовать для получения .NET и использовать те же MSIs, что и автономные пакеты.

Note

Пакет SDK .NET поставляется с Visual Studio до 16.2. Начиная с .NET Core 3.0 в Visual Studio 16.3 пакеты SDK были заменены отдельными .NET MSIs.

Upgrades

.NET поддерживает обновления между версиями исправлений в основном или дополнительном выпуске. .NET 8.0.7 обновит предыдущие выпуски, такие как 8.0.4 или 8.0.0, включая предварительные версии, но не обновят предыдущий основной выпуск, например .NET 7.0. Пакет SDK .NET поддерживает обновления между исправлениями в пределах полосы компонентов. Пакет SDK 8.0.100 можно обновить до версии 8.0.103, но пакет SDK 8.0.3xx не будет обновлять диапазоны компонентов 1xx или 2xx.

Большинство обновлений обрабатываются на уровне пакета. Предыдущая версия удаляется только после установки новой версии. Существует два исключения: узел .NET и MSIS модуля ASP.NET Core обновляются.

Начиная с .NET 8 пользователи могут отложить удаление предыдущей версии пакета.

Состав пакета и подсчет ссылок

Пакеты состоят из нескольких MSIs, некоторые из которых совместно используются между несколькими пакетами.

• Пакет среды выполнения содержит три MSIs, которые также поставляется в пакете sdk для настольных компьютеров и среды выполнения.
• Пакет классических приложений включает дополнительный MSI, который предоставляется пакету SDK.
• Пакет SDK включает дополнительные MSIs, содержащие интерфейс командной строки, шаблоны и пакеты, используемые для создания и сборки приложений .NET.

Общие MSIs управляются с помощью подсчета ссылок. Каждый .NET MSI создает раздел реестра, называемый ключом поставщика, который позволяет пакету регистрировать себя в качестве зависимого. Если MSI уже установлен, пакет обновляет только сведения о регистрации. Пакеты отменяются при удалении. Общие MSIs удаляются только после отсутствия зарегистрированных зависимых.

Приведенные ниже сведения о реестре являются примером ключа поставщика MSI узла .NET. Существует четыре зарегистрированных зависимых, включая Visual Studio.

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Dependencies\Dotnet_CLI_SharedHost_10.0_x64
    (Default)   REG_SZ    {8A8CC49F-7D1E-45DC-B7B5-35FF61A2C25E}
    Version     REG_SZ    80.40.55332
    DisplayName REG_SZ    Microsoft .NET Host - 10.0.10 (x64)

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Dependencies\Dotnet_CLI_SharedHost_10.0_x64\Dependents\VS.{AEF703B8-D2CC-4343-915C-F54A30B90937}

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Dependencies\Dotnet_CLI_SharedHost_10.0_x64\Dependents\{609A456D-467D-4077-9BA2-B6404F1B1163}

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Dependencies\Dotnet_CLI_SharedHost_10.0_x64\Dependents\{866BECDA-F284-473A-9E84-0CCE816BF06F}

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Dependencies\Dotnet_CLI_SharedHost_10.0_x64\Dependents\{FD5EA214-C690-466F-B8FB-1741881913F9}

Note

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

Note

Visual Studio использует хорошо известное значение, VS.{AEF703B8-D2CC-4343-915C-F54A30B90937}чтобы зарегистрировать себя в качестве зависимого. Фактическое число ссылок определяется путем проверки манифеста установки для каждого экземпляра Visual Studio.

Развернутые установки bin

Развернутые двоичные установки относятся к копиям .NET, которые не связаны с MSI. Это можно сделать, выполнив скрипты установки в качестве администратора и установив каталог установки на "Program Files\dotnet". Развернутые двоичные установки могут усложнить исправление. Сканеры сообщают об уязвимостях, но администраторы не будут находить MSIs для удаления. DNIM может обнаруживать развернутые двоичные установки.

Обнаружение

DNIM использует ряд эвристических средств для идентификации пакетов и MSIs, связанных с .NET. Точное обнаружение установок имеет решающее значение для успешного исправления устройств, не относящихся к жалобам.

Bundles

Пакеты определяются с помощью отображаемых имен и сведений о файлах, хранящихся в реестре. Дополнительные проверки выполняются для исполняемых файлов, чтобы убедиться, что они являются допустимыми установщиками. Эта информация также сравнивается с данными JSON, .NET публикуется для каждого выпуска.

Обнаружение MSI

DNIM выполняет исчерпывающий поиск по данным компонента установщика, хранящимся в регистреHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components, чтобы определить .NET MSIs.

Каждый подраздел представляет другой идентификатор компонента. Значения под каждым ключом представляют коды продуктов. Идентификатор компонента и коды продуктов хранятся в виде упакованных идентификаторов GUID. В приведенном ниже примере используется компонент, связанный с dotnet.exe.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\BBB993545ADD68342A9E16F83B5CA481
    40A3E8A8CB38EDC4299598B366C6A11B    REG_SZ    C:\Program Files\dotnet\dotnet.exe
    A75437C333A10ED46B2CF6AB78E7F1FC    REG_SZ    C:\Program Files (x86)\dotnet\dotnet.exe
    79D2396D1F638B04C9CDAC38562B0100    REG_SZ    C:\Program Files\dotnet\dotnet.exe
    EA6D9CBF69367CF4CB81005882631FD6    REG_SZ    C:\Program Files (x86)\dotnet\dotnet.exe
    872D9C61B8AA60F47A4CDF137C8523A3    REG_SZ    C:\Program Files (x86)\dotnet\dotnet.exe
    6235DF10DB18AED4F910D396BBDD7AE5    REG_SZ    C:\Program Files\dotnet\dotnet.exe
    0370151E43A53FE48B564853D1B81FAB    REG_SZ    C:\Program Files\dotnet\dotnet.exe
    F6D22817F79056B46B45655C7495EE9A    REG_SZ    C:\Program Files (x86)\dotnet\dotnet.exe
    D512842CB6C6A404BAE605D564042E50    REG_SZ    C:\Program Files\dotnet\dotnet.exe

Развернутые двоичные установки

Так как DNIM выполняет исчерпывающий поиск компонентов установщика, все файлы, Program Files\dotnet не связанные с MSI, классифицируются как развернутые в корзине установки.

Classification

Неправильная классификация установок может привести к удалению или хранению неправильной установки, потенциально критическим приложениям или выходу устройств в несоответствующем состоянии.

После определения продукта (например, NET 10) можно определить дополнительные сведения, такие как его выпуск (например, 10.0.4) и этап поддержки (например, активный). Это позволяет администраторам создавать гибкие развертывания.

Установки также классифицируются в соответствии с их компонентом .NET (ASP.NET Core, пакетом SDK и т. д.), архитектурой и типом установки (пакет, MSI или корзина развернуты).

Существуют некоторые особые случаи, которые стоит упомянуть.

.NET standard 2.1

Для обеспечения согласованного поведения требуется установка, чтобы определить свой продукт, выпуск и этап поддержки. Целевой пакет для .NET Standard 2.1 представляет интересную задачу. Он не содержит исполняемый код и предоставляет только эталонные сборки для API, определенных стандартом. Пакет назначения сначала поставляется в составе пакета SDK для .NET Core 3.0.100, но был включен в все последующие пакеты SDK до .NET 10. Хотя DNIM классифицирует выпуск и продукт в .NET Core 3.0, этап поддержки всегда сообщается как активный, так как он может быть включен в пакеты SDK, которые находятся в активной поддержке.

Note

Пакет назначения .NET standard 2.1 был удален из установки пакета SDK в .NET 10. Пакеты SDK автоматически загружают отсутствующие целевые пакеты с помощью пакетов NuGet при создании приложений.

.NET полосы функций пакета SDK

В .NET Core 1.0 и 1.1 пакеты SDK использовали схему управления версиями, аналогичную runime. Последний пакет SDK в .NET Core 1.1 был версиями 1.1.14 и включал среду выполнения 1.1.13.

В пакете SDK 2.1.100 были представлены полосы возможностей пакета SDK, чтобы различать поддерживаемые функции в Visual Studio. Пакет SDK, поставляемый в составе выпуска .NET Core 2.0.5. Последний пакет SDK версии 2.0 был версии 2.1.202 и включен в выпуск 2.0.9. Первый пакет SDK для отправки в .NET Core 2.1 был версии 2.1.300. В последующих выпусках группы функций SDK всегда начинаются с 100, например 2.2.100, 3.0.100 и т. д.