Интеграция с оболочкой Windows сегодня ── контекстные меню, ассоциации файлов и что изменилось в Windows 11

Ко мне обратились с «мы заменили ПК на Windows 11, и контекстное меню приложения, которое вы нам сделали много лет назад, исчезло». Послушав внимательнее, оно не исчезло. Щёлкните файл правой кнопкой, выберите «Показать дополнительные параметры» внизу меню — и знакомое меню появляется как всегда. Иными словами, пункты меню внутреннего приложения спрятали на один щелчок глубже. С мест говорят «лишний щелчок» и «стало больше обращений, что пункт не находят».

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

При этом механизм ассоциации файлов и расширений оболочки под ним по-прежнему старый мир COM и реестра. Ключ расширения указывает на ProgID, verb ProgID хранит командную строку, а более сложное расширение работает как внутрипроцессный COM-сервер (DLL), загружаемый в Проводник — эта структура не менялась больше двадцати лет. Если вы не знаете и неизменный фундамент, и меню, которое Windows 11 разделила надвое, вы не отличите «меню не появляется», «оно спрятано» и «оно появляется дважды».

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

1. Сначала вывод

• Фундамент контекстного меню и ассоциации файлов — трёхслойная структура реестра «ключ расширения → ProgID → verb». Ключ расширения — указатель на ProgID, ProgID — сущность, а shell\<verb>\command под ним хранит командную строку.¹
• HKEY_CLASSES_ROOT (HKCR) — не независимый куст, а объединённое представление HKLM\Software\Classes и HKCU\Software\Classes. Регистрацию для всех пользователей пишите в HKLM, для одного пользователя — в HKCU, а HKCR считайте только для чтения.²
• Приложение по умолчанию (то, что открывается двойным щелчком) рассчитано на выбор пользователя, и программа не может его украсть. ОС защищает выбор пользователя; установщик может зарегистрироваться как кандидат.³
• Классическое расширение оболочки — внутрипроцессная COM DLL, загружаемая в Проводник. Сбой или задержка расширения распространяются на Проводник целиком (и на другие приложения, использующие оболочку); в 64-разрядной среде нужна 64-разрядная DLL; реализация на управляемом коде не поддерживается.⁴⁵
• В Windows 11 контекстное меню разделилось надвое. В новом меню появляются только команды, зарегистрированные через IExplorerCommand плюс идентичность пакета; классические расширения IContextMenu перенесены в старое меню под «Показать дополнительные параметры» (Shift+F10).⁶⁷
• Официальный путь поместить свою команду в новое меню — зарегистрировать нативную DLL, реализующую IExplorerCommand, в манифесте MSIX (desktop4:FileExplorerContextMenus). Приложение, которое не может стать MSIX, может получить только идентичность через sparse package (MSIX с внешним расположением).⁷⁸
• Если нужно только «открыть этим приложением», ассоциации и статического verb по-прежнему достаточно. DLL расширения оболочки не нужна, и сама Microsoft прямо говорит «выберите самый простой метод, удовлетворяющий требованиям (статический verb)».⁹
• После регистрации или изменения уведомите через SHChangeNotify(SHCNE_ASSOCCHANGED); при удалении удалите ProgID, но не удаляйте значение по умолчанию ключа расширения — такова официальная рекомендация. Интеграция с оболочкой включает проект очистки.¹¹⁰

Одним предложением: мир ассоциаций и verb не изменился; только показ меню в Windows 11 разделился надвое. Ниже идём от фундамента.

2. Как работает ассоциация файлов — трёхслойная структура ключ расширения → ProgID → verb

2.1. Читаем трёхслойную структуру на одном примере

Что происходит при двойном щелчке по файлу данного расширения, решают три слоя ключей реестра.¹

HKEY_CLASSES_ROOT
   .kmrpt                                  ← (1) Ключ расширения
      (Default) = KomuraSoft.Report.1      ←     Указатель, который только именует ProgID
      OpenWithProgids
         KomuraSoft.Report.1               ←     Кандидат в «Открыть с помощью»
   KomuraSoft.Report.1                     ← (2) ProgID (сущность ассоциации)
      (Default) = Komura Report document
      DefaultIcon
         (Default) = "C:\Program Files\KomuraSoft\Report.exe",0
      shell                                ← (3) Список verb
         open
            command
               (Default) = "C:\Program Files\KomuraSoft\Report.exe" "%1"

• (1) Ключ расширения (.kmrpt) только указывает на имя ProgID как значение по умолчанию. Писать команду прямо сюда — ошибка.
• (2) ProgID (KomuraSoft.Report.1) — сущность ассоциации; в нём отображаемое имя, значок и список verb.
• (3) Verb — действие вроде «открыть» или «печать», а значение по умолчанию shell\open\command — реально запускаемая командная строка.

Это разделение позволяет указывать несколько расширений (например .kmrpt и .kmrpt-file) на один ProgID или менять ProgID при обновлении приложения.

flowchart TB
    accTitle: Трёхслойная структура ассоциации файлов
    accDescr: Ключ расширения — указатель, чьё значение по умолчанию именует ProgID; ProgID — сущность с отображаемым именем, значком и списком verb; значение по умолчанию command под verb — реально запускаемая командная строка
    ext["Ключ расширения .kmrpt"] -->|именует ProgID как значение по умолчанию| pid["ProgID KomuraSoft.Report.1"]
    pid --> vb["verb（open и другие под shell）"]
    vb --> cmd["значение по умолчанию command"]
    cmd --> exe["Запускается Report.exe"]
    pid -.-> attr["Также хранит отображаемое имя и DefaultIcon"]

Рис. 1: Ключ расширения — указатель, ProgID — сущность, а command verb — реально запускаемая командная строка.

2.2. HKCR — «объединённое представление» — куда пишете, меняет смысл

Пример выше показан под HKEY_CLASSES_ROOT (HKCR), но HKCR — не физическое место хранения, а объединённое представление HKLM\Software\Classes и HKCU\Software\Classes. Если один и тот же ключ есть в обоих, побеждает сторона HKCU.²

flowchart TB
    accTitle: HKCR — объединённое представление
    accDescr: HKCR — это HKLM и HKCU Classes, наложенные друг на друга; если один и тот же ключ есть в обоих, побеждает HKCU; пишите регистрацию явно в HKLM или HKCU и считайте HKCR только для чтения
    hklm["HKLM\\Software\\Classes（все пользователи）"] --> hkcr["HKCR（объединённое представление）"]
    hkcu["HKCU\\Software\\Classes（на пользователя）"] --> hkcr
    hkcu -.-> win["Если ключ один и тот же, побеждает HKCU"]
    hkcr -.-> ro["Считайте только для чтения（для проверки）"]

Рис. 2: HKCR — вид HKLM и HKCU Classes, наложенных вместе; всегда называйте одну из сторон как место записи.

На практике безопасное деление — всегда писать регистрацию явно в HKLM или HKCU и считать HKCR только для чтения (для проверки). Стоит разобрать и связь с перенаправлением реестра WOW64. Данные ассоциации прямо под HKLM\Software\Classes вроде ключей расширения и ProgID общие между 32- и 64-разрядными представлениями реестра начиная с Windows 7, поэтому 32-разрядный установщик, пишущий их, не уходит на сторону Wow6432Node. Некоторые подразделы COM-регистрации вроде Classes\CLSID, напротив, перенаправляются, и при регистрации расширения оболочки (внутрипроцессный COM) важно деление записи 32/64 бит. Подробности — в «Registry 32-bit/64-bit Redirection and Virtualization Pitfalls — Wow6432Node and the “The Value I Wrote Isn’t There” Problem».

2.3. Регистрация на стороне приложения — App Paths, Applications, RegisteredApplications

Есть и три вида регистрации на стороне приложения, в паре со стороной файла (расширение и ProgID).¹¹

• App Paths (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths): регистрация, позволяющая ShellExecuteEx запускать только по имени исполняемого файла. Microsoft рекомендует это, потому что не нужно засорять переменную среды PATH.
• Applications (HKCR\Applications\<app.exe>): задаёт способ открытия по умолчанию, когда произвольный файл передают через «Открыть с помощью», и отображаемое имя приложения (FriendlyAppName).
• RegisteredApplications + Capabilities: объявляет расширения и типы MIME, которые приложение умеет обрабатывать, и это регистрация, из-за которой оно появляется кандидатом на странице Параметры приложений по умолчанию Windows.

Большинство обращений «наше приложение не появляется в списке приложений по умолчанию» — случаи, когда ProgID зарегистрировали, а эту регистрацию Capabilities пропустили.

flowchart TB
    accTitle: Три вида регистрации на стороне приложения
    accDescr: Регистрация на стороне приложения бывает трёх видов — App Paths, Applications и RegisteredApplications — отвечающих соответственно за запуск только по имени файла, способ открытия по умолчанию в «Открыть с помощью» и появление на странице приложений по умолчанию
    app["Регистрация на стороне приложения"] --> ap["App Paths"]
    app --> apps["Applications"]
    app --> ra["RegisteredApplications"]
    ap --> r1["Запуск только по имени файла"]
    apps --> r2["По умолчанию в Открыть с помощью"]
    ra --> r3["Появляется на странице приложений по умолчанию"]
    r3 -.-> cap["Нужно объявление Capabilities"]

Рис. 3: Регистрация на стороне приложения бывает трёх видов, и чтобы появиться кандидатом приложений по умолчанию, нужна регистрация Capabilities.

2.4. Приложение по умолчанию принадлежит пользователю — защита UserChoice

Запись ProgID как значения по умолчанию ключа расширения сама по себе не делает его приложением по умолчанию. Результат явного выбора пользователя в «Открыть с помощью» и подобном хранится в HKCU\...\Explorer\FileExts\<extension>\UserChoice, и разрешение ассоциации предпочитает ту сторону.

И важный момент: Windows не поддерживает программную смену приложения по умолчанию. Настройки приложения по умолчанию рассчитаны на пользователя через системный интерфейс Параметры; данные UserChoice обфусцированы, а драйвер-фильтр (UCPD.sys) блокирует запись из приложений. В управляемой среде официальное средство — групповая политика / политика MDM.³

То, что использовали инструменты вроде SetUserFTA, которые «имитируют хеш и переписывают», — обратная сторона этой защиты. В установщик внутреннего приложения нужно класть не кражу значения по умолчанию, а три вещи: (a) правильная регистрация ProgID и verb, (b) добавление себя в OpenWithProgIds и (c) при необходимости направление на страницу Параметры.

flowchart TB
    accTitle: Разрешение приложения по умолчанию и защита UserChoice
    accDescr: Результат явного выбора пользователя хранится в UserChoice и предпочитается при разрешении ассоциации; UCPD.sys блокирует перезапись из приложений, поэтому установщик может зарегистрироваться как кандидат и направить на страницу Параметры
    uc["UserChoice（выбор пользователя）"] -->|предпочитается| res["Разрешение ассоциации"]
    ext["Значение по умолчанию ключа расширения"] --> res
    wr["Перезапись из приложения"] -.->|UCPD.sys блокирует| uc
    res ~~~ inst["Работа установщика"]
    inst --> a1["Зарегистрировать ProgID и verb"]
    inst --> a2["Добавить в OpenWithProgIds"]
    inst --> a3["Направить на страницу Параметры"]

Рис. 4: Разрешение ассоциации предпочитает выбор пользователя (UserChoice), и ОС защищает его от перезаписи приложениями.

3. Verb кроме «Открыть» — print, edit, runas, свои verb

Verb — не только open. Стандартные verb, смысл которых знает ОС, включают edit, print, play и preview наряду с open, и стандартный verb автоматически получает отображаемое имя по языку ОС. Verb по умолчанию при двойном щелчке решается в порядке: значение по умолчанию ключа shell → первый verb в реестре → open → openwith.¹²

flowchart TB
    accTitle: Порядок, в котором решается verb по умолчанию
    accDescr: Verb по умолчанию при двойном щелчке — первый найденный в порядке значение по умолчанию ключа shell, первый verb в реестре, open, openwith
    s1["значение по умолчанию ключа shell"] -->|если нет| s2["Первый verb в реестре"]
    s2 -->|если нет| s3["open"]
    s3 -->|если нет| s4["openwith"]

Рис. 5: Verb по умолчанию при двойном щелчке — первый найденный в этом порядке.

Когда хотите добавить своё действие, зарегистрируйте свой verb.

KomuraSoft.Report.1
   shell
      open
         command
            (Default) = "C:\Program Files\KomuraSoft\Report.exe" "%1"
      print
         command
            (Default) = "C:\Program Files\KomuraSoft\Report.exe" /print "%1"
      verify                          ← свой verb
         (Default) = Verify report (&V)   ← отображаемое имя в меню
         command
            (Default) = "C:\Program Files\KomuraSoft\Report.exe" /verify "%1"

Три мелких факта, которые полезно знать.

• Зарегистрируйте verb с именем runas — и определите запуск с повышением, эквивалентный «Запуск от имени администратора»; его же используют API семейства ShellExecute, когда указывают runas.
• Положите на ключ verb пустое значение с именем Extended — и он станет расширенным verb, показываемым только при Shift+правый щелчок. Удобно прятать опасную редко используемую операцию.¹²
• У части ассоциаций старых приложений ещё есть конфигурация, отправляющая документ в существующий процесс через DDE (ключ ddeexec), но запуск verb через DDE уже устаревшее наследие Deprecated. Писать это заново незачем.¹²

Ещё одна частая авария — кавычки в командной строке. Если элемент командной строки может содержать пробел, его нужно обернуть в кавычки. Это относится и к пути EXE вроде C:\Program Files\..., и %1 (путь выбранного файла) всегда пишите как "%1". Нельзя гарантировать, что путь файла пользователя не содержит пробела. Незаключённый в кавычки My Program.exe толкуется как «запустить My с аргументом Program.exe».¹³

flowchart TB
    accTitle: Авария с кавычками в командной строке
    accDescr: Команда без кавычек режется по пробелу и ошибочно толкуется как запуск My с аргументом Program.exe, поэтому путь EXE, который может содержать пробел, и %1, обозначающий путь выбранного файла, всегда нужно оборачивать в кавычки
    c1["Команда без кавычек"] -->|режется по пробелу| bad["Ошибочно толкуется как запуск другого EXE"]
    c2["Команда в кавычках"] --> good["Запускается как задумано"]
    c2 -.-> q1["Оберните путь EXE в кавычки"]
    q1 -.-> q2["Всегда оборачивайте и %1 в кавычки"]

Рис. 6: Команда без кавычек ошибочно режется по пробелу, поэтому путь EXE и %1 всегда оборачивайте в кавычки.

Механизм только реестра до сих пор (статический verb) можно реализовать, не написав ни одной DLL, и он не рискует сделать Проводник нестабильным. Сама Microsoft неоднократно говорит «прежде чем писать расширение оболочки, подумайте, хватит ли самого простого статического verb, удовлетворяющего требованиям».⁹

4. Классические расширения оболочки — DLL, которая работает внутри Проводника

4.1. Виды расширений оболочки

Требования, которые статический verb не закрывает — «менять меню динамически в зависимости от выбора», «заменить значок или лист свойств» — используют обработчик расширения оболочки. Типичные виды таковы.⁴

Всё это реализовано как классы COM и зарегистрировано в реестре по CLSID. Сама идея COM разобрана в «Что такое COM / ActiveX / OCX - объясняем различия и связь между ними».

4.2. Что значит быть внутрипроцессным COM-сервером

Суть классического расширения оболочки в том, что это внутрипроцессный COM-сервер (DLL), загружаемый в Проводник (или в любое приложение, открывшее общее диалоговое окно файлов). Все оговорки следуют отсюда.⁴

• Если расширение падает, Проводник падает вместе с ним. Если оно зависает, правый щелчок замирает на несколько секунд. Ущерб не ограничивается Проводником; он достигает каждого приложения, показавшего диалог открытия файла.
• Построение меню идёт на потоке UI, поэтому нельзя делать медленную работу вроде доступа к сети или файлового ввода-вывода в момент показа меню.
• Модель потоков регистрируйте как правило Apartment.

flowchart TB
    accTitle: Структура сопутствующего ущерба внутрипроцессного расширения
    accDescr: DLL расширения оболочки загружается не только в Проводник, но и в процесс любого приложения, открывшего диалог файлов, поэтому сбой или зависание расширения распространяются на весь процесс-хост
    dll["DLL расширения оболочки"] -->|загружается внутри процесса| exp["Проводник"]
    dll -->|загружается внутри процесса| any["Любое приложение, открывающее диалог"]
    exp --> dmg["Сбой или зависание распространяются"]
    any --> dmg
    dmg -.-> rule["Не делать медленную работу при показе"]

Рис. 7: DLL расширения работает внутри процесса-хоста, поэтому сбой или зависание распространяются на хост целиком.

Разбирая обращение вроде «Проводник зависает, когда открываю определённую папку» или «правый щелчок занимает пять секунд», нередко выясняется, что причина — стороннее расширение оболочки, а не внутреннее приложение. Методы изоляции — в главе 8.

4.3. Согласовать разрядность — 64-разрядной среде нужна 64-разрядная DLL

Внутрипроцессная DLL должна совпадать по разрядности с процессом, который её загружает. Проводник в 64-разрядной Windows — 64-разрядный процесс, поэтому DLL расширения оболочки, собранная только как 32-разрядная, никогда не загружается и вообще не появляется в меню. Ошибки тоже нет, поэтому это типичная причина «зарегистрировал, а не появляется». Сочетание 32-разрядного тела приложения с 64-разрядной DLL расширения оболочки законно, но нужно следить за тем, что COM-регистрация делится по разрядности (Wow6432Node). Запуск из command verb — отдельный процесс EXE, поэтому этому ограничению не подлежит (оставить 32-разрядный EXE нормально).

flowchart TB
    accTitle: Согласование разрядности DLL расширения оболочки
    accDescr: Единственная DLL расширения оболочки, которую 64-разрядный Проводник может загрузить, — 64-разрядная; только 32-разрядная DLL не появляется в меню и не даёт ошибки; EXE, запускаемый из command verb, — отдельный процесс и ограничению не подлежит
    exp["64-разрядный Проводник"] -->|может загрузить| d64["64-разрядная DLL расширения оболочки"]
    exp -.->|не может загрузить| d32["Только 32-разрядная DLL"]
    d32 -.-> sym["Не появляется в меню, без ошибки"]
    exe["EXE, запускаемый из verb"] -->|отдельный процесс| ok32["Можно оставить 32-разрядным"]

Рис. 8: В 64-разрядный Проводник загружается только 64-разрядная DLL; EXE, запускаемый из verb, этому ограничению не подлежит.

4.4. Почему нельзя писать на управляемом коде

Меня часто спрашивают «можно ли писать расширение оболочки на C#», но Microsoft прямо заявила, что писать внутрипроцессное расширение оболочки на управляемом коде (.NET) не рекомендуется и находится вне поддержки.⁵

Причина — природа расширения, загружаемого в произвольный процесс. Столкновения версий CLR (особенно ниже .NET Framework 4), повторный вход CLR в цикл сообщений в ожидании блокировки и недетерминированное время жизни объектов из-за сборки мусора, конфликтующее с контрактом счётчика ссылок COM, — структурные причины нестабильности хоста. Часть пунктов смягчена в .NET Framework 4 и новее и в современном .NET, но официальная позиция не изменилась.

Практическое правило простое. Внутрипроцессное расширение пишите на нативном C++. Если нужен управляемый код, сделайте обычный EXE, запускаемый из command verb, или внепроцессное расширение, работающее в отдельном процессе (обработчик предпросмотра и подобное).⁵

flowchart TB
    accTitle: Решение, допустим ли управляемый код
    accDescr: Внутрипроцессное расширение, работающее внутри Проводника, по правилу пишут на нативном C++; если нужен управляемый код, сделайте обычный EXE, запускаемый из command verb, или внепроцессное расширение в отдельном процессе
    q1{"Работает внутри процесса?"} -->|да| cpp["Пишите на нативном C++"]
    q1 -->|нет| mg["Управляемый код допустим"]
    cpp -.-> why["Риск CLR / повторного входа делает хост нестабильным"]
    mg --> e1["EXE, запускаемый из verb"]
    mg --> e2["Внепроцессный предпросмотр"]

Рис. 9: Внутрипроцессное расширение по правилу — нативный C++; управляемый код ограничен конфигурацией, работающей в отдельном процессе.

5. Новое контекстное меню Windows 11 — меню, разделённое надвое

5.1. Что произошло

Windows 11 обновила контекстное меню Проводника. Вырезать, копировать и подобное стали рядом значков сверху; «Открыть» и «Открыть с помощью» сгруппировали сверху; команды, которые добавляет приложение, группируются под стандартными командами оболочки. Когда одно приложение добавляет несколько команд, их собирают во всплывающее меню (подменю) с именем приложения.⁶

И решающий момент таков. Классические расширения оболочки на IContextMenu не удалили; их перенесли на сторону старого меню, которое открывается «Показать дополнительные параметры» (Shift+F10) и загружает меню Windows 10 как есть.⁶ Личность начального обращения «меню спрятали» — это это разделение.

flowchart TB
    accTitle: Контекстное меню, которое Windows 11 разделила надвое
    accDescr: Сначала при правом щелчке открывается новое меню; там появляются только команды, зарегистрированные через IExplorerCommand и идентичность пакета; классические расширения IContextMenu перенесены в старое меню, открываемое «Показать дополнительные параметры»
    rc["Правый щелчок по файлу"] --> newm["Новое меню（Windows 11）"]
    newm --> newi["Команды IExplorerCommand + идентичность"]
    newm -->|Показать дополнительные параметры Shift+F10| oldm["Старое меню（меню Windows 10）"]
    oldm --> oldi["Классические расширения IContextMenu"]
    newi -.-> fly["Несколько команд собирают во всплывающее меню"]

Рис. 10: В новом меню появляются только команды IExplorerCommand + идентичность; классические расширения перенесены на сторону старого меню.

5.2. Официальный путь в новое меню — IExplorerCommand + регистрация в манифесте

Есть один способ поместить свою команду в новое меню. Подготовьте нативную DLL, реализующую интерфейс IExplorerCommand, и объявите COM-сервер и расширение контекстного меню в манифесте пакета MSIX.⁷

<!-- Манифест пакета (фрагмент) -->
<com:Extension Category="windows.comServer">
  <com:ComServer>
    <com:SurrogateServer DisplayName="Komura commands">
      <com:Class Id="01234567-89AB-CDEF-0123-456789ABCDEF"
                 Path="KomuraCommand.dll" ThreadingModel="STA" />
    </com:SurrogateServer>
  </com:ComServer>
</com:Extension>
<desktop4:Extension Category="windows.fileExplorerContextMenus">
  <desktop4:FileExplorerContextMenus>
    <desktop5:ItemType Type=".kmrpt">
      <desktop5:Verb Id="VerifyReport"
                     Clsid="01234567-89AB-CDEF-0123-456789ABCDEF" />
    </desktop5:ItemType>
  </desktop4:FileExplorerContextMenus>
</desktop4:Extension>

Type у ItemType может задавать конкретное расширение, или * (все файлы), Directory (папки) или Directory\Background (фон папки). Согласуйте DLL с архитектурой Проводника (64 бит / ARM64).⁷

Сам IExplorerCommand — интерфейс со времён Windows 7; вы реализуете заголовок (GetTitle), значок (GetIcon), состояние включено / отключено / скрыто (GetState) и выполнение (Invoke). Методы вызываются с потока UI, поэтому доступ к сетевым ресурсам запрещён, а методы построения меню должны возвращаться быстро. Тяжёлую работу делайте после Invoke.¹⁴⁷

flowchart TB
    accTitle: Структура манифеста регистрации в новом меню
    accDescr: Объявление COM-сервера в манифесте MSIX сопоставляет CLSID с DLL, а объявление расширения контекстного меню связывает цель и реализацию через ItemType и Verb, поэтому своя команда появляется в новом меню
    man["Манифест MSIX"] --> com["Объявление COM-сервера"]
    man --> ctx["Объявление расширения меню"]
    com -->|сопоставляет CLSID с DLL| impl["DLL реализации IExplorerCommand"]
    ctx -->|задаёт через ItemType и Verb| impl
    impl --> shown["Команда появляется в новом меню"]
    ctx -.-> tgt["Цель — расширение, все файлы и подобное"]

Рис. 11: Два объявления в манифесте связывают DLL реализации с целью, и команда появляется в новом меню.

5.3. Вариант для неупакованного приложения — получить только идентичность через sparse package

Лазейка, когда «наше приложение можно распространять только как MSI; MSIX невозможен», — sparse package (MSIX с внешним расположением). Вы подписываете небольшой MSIX, который есть только манифест, без тела приложения, и регистрируете его в конце существующего установщика. Тогда приложение получает идентичность пакета, и регистрация в манифесте выше (= появление в новом меню) становится возможной. Доступно начиная с Windows 10 версии 2004, пакету нужна подпись сертификатом, которому доверяют на целевой машине.⁸

flowchart TB
    accTitle: Поток получения идентичности через sparse package
    accDescr: После того как существующий установщик разместил тело приложения, регистрация sparse package только с манифестом и внешним расположением даёт приложению идентичность пакета и делает возможной регистрацию манифеста нового меню
    inst["Существующий установщик"] --> files["Разместить тело приложения"]
    sp["Sparse package"] -.-> only["Только манифест, без тела"]
    files --> reg["Зарегистрировать с внешним расположением"]
    sp --> reg
    reg --> id["Получить идентичность пакета"]
    id --> ok["Регистрация в новом меню становится возможной"]
    sp -.-> sign["Нужна доверенная подпись"]

Рис. 12: Зарегистрируйте sparse package без тела с внешним расположением — и приложение получит идентичность пакета.

Главное преимущество — не нужно менять установщик; это реалистичный ответ для приложения, у которого уже есть актив установщика MSI/EXE. Сравнение с полным переходом на MSIX см. также в «Как выбрать способ распространения Windows-приложения — MSI/MSIX/ClickOnce/xcopy/собственный updater».

5.4. Как verb ассоциации появляются в новом меню

Легко понять неправильно: ассоциации глав 2 и 3 (ProgID и verb) в новом меню ещё живы. Verb по умолчанию при двойном щелчке, «Открыть» и кандидаты «Открыть с помощью» разрешаются из ассоциации и показываются вверху нового меню. Поэтому если нужно только «открывать этим приложением», Windows 11 не требует лишней работы. С другой стороны, ассоциация — не универсальное расширение меню, поэтому произвольную свою команду в первый слой нового меню ставят через IExplorerCommand плюс идентичность — таково разделение ролей.⁷

flowchart TB
    accTitle: Разделение ролей между ассоциациями и новым меню
    accDescr: Ассоциация ProgID-и-verb в новом меню по-прежнему используется, чтобы разрешить verb по умолчанию, Открыть и Открыть с помощью, и показывается вверху; произвольную свою команду в первый слой нового меню ставят через IExplorerCommand и идентичность
    assoc["Ассоц.（ProgID + verb）"] --> sol["Разрешить по умолчанию / Открыть"]
    sol --> top["Верх нового меню"]
    assoc -.-> keep["Нет лишней работы на Win11"]
    cmd["Своя команда"] --> need["IExplorerCommand+идентичность"]
    need --> first["Первый слой нового меню"]

Рис. 13: Ассоциации по-прежнему отвечают за разрешение семейства «Открыть» в новом меню; только своя команда требует IExplorerCommand плюс идентичность.

6. Практическая таблица решения — какой из трёх вариантов взять

Сводим сказанное в практический выбор из трёх.

Два пункта суждения. Первое: не тащите (b) или (c) под требование, которое закрывает (a). В момент, когда пишете расширение оболочки, вы берёте ответственность за стабильность Проводника. Второе: (c) лишь «не сломано»; как пользовательский опыт оно остаётся на шаг хуже. Чем чаще команда используется в повседневной работе, тем больше отдача от перехода на (b).

flowchart TB
    accTitle: Как выбирать среди трёх вариантов
    accDescr: Если нужен только запуск двойным щелчком или Открыть, хватит ассоциации и статического verb; чтобы поместить свою команду в новое меню, используйте IExplorerCommand и регистрацию в манифесте MSIX; если нельзя стать MSIX, выдайте идентичность через sparse package; существующее классическое расширение IContextMenu пока оставьте на стороне старого меню
    q1{"Хватит Открыть?"} -->|да| pa["Ассоц. + статический verb"]
    q1 -->|нет| q2{"Своя команда в новом меню?"}
    q2 -->|да| q3{"Можете стать MSIX?"}
    q3 -->|да| pb1["IExplorerCommand+MSIX"]
    q3 -->|нет| pb2["Идентичность sparse-pkg"]
    q2 -->|нет| pc["Пока оставить классическое"]
    pc -.-> old["Только сторона старого меню"]
    pa -.-> dllfree["Нет DLL, малый риск"]

Рис. 14: Выбирайте среди статического verb, IExplorerCommand плюс идентичность и сохранения классического — по требованию.

7. Развёртывание и регистрация на практике — установщик, sparse package, очистка

7.1. HKLM или HKCU

Согласуйте с формой установщика. Все пользователи (размещено под Program Files, права администратора) — HKLM\Software\Classes; установка на пользователя (без повышения) — HKCU\Software\Classes. Смешаете — получите обращение «у A открывается, у B нет». Для расширения оболочки с регистрацией CLSID Reg-Free COM — убирающий саму регистрацию в реестре — годится для COM внутри приложения, но неприменим к расширению оболочки, которое загружает Проводник, поэтому нужна прямая регистрация («Что такое Reg-Free COM — механизм использования COM без регистрации»).

7.2. После изменения уведомите — SHChangeNotify

После регистрации, изменения или удаления ассоциации уведомите событие SHCNE_ASSOCCHANGED через SHChangeNotify. Пропустите это — и Проводник может не заметить изменение до перезагрузки.¹¹⁰

// Вызвать один раз после смены ассоциаций, напр. из пользовательского действия установщика
SHChangeNotify(SHCNE_ASSOCCHANGED, SHCNF_IDLIST, nullptr, nullptr);

7.3. Регистрация и снятие sparse package

Регистрация и снятие sparse package — работа установщика. Регистрируйте после размещения файлов; снимайте до удаления файлов.⁸

# При установке: после размещения файлов зарегистрировать папку установки как внешнее расположение
Add-AppxPackage -Path "C:\Program Files\KomuraSoft\KomuraReport.identity.msix" `
                -ExternalLocation "C:\Program Files\KomuraSoft"

# При удалении: снять регистрацию пакета до удаления файлов
Remove-AppxPackage <package full name>

На что смотреть: Add-AppxPackage регистрирует для пользователя, который его выполнил. Если вызвать из пользовательского действия MSI на машину под LocalSystem, идентичность не выдаётся установившему пользователю, поэтому настраивают выполнение под олицетворением пользователя. Даже тогда регистрация под олицетворением — только для пользователя, выполнившего эту установку. На ПК с несколькими пользователями у других и у созданных позже пользователей нет идентичности пакета, и команда не появляется в новом меню. Чтобы каждый пользователь мог пользоваться, дайте механизм вроде проверки своей регистрации пакета при первом запуске и регистрации, если её нет (регистрация на пользователя), и включите снятие у каждого пользователя с регистрацией в план удаления. Чтобы отразить регистрацию манифеста, может понадобиться перезапуск Проводника (или выход).⁷

flowchart TB
    accTitle: Порядок регистрации и снятия sparse package
    accDescr: При установке регистрируйте sparse package после размещения файлов; при удалении снимайте регистрацию до удаления файлов; следите за тем, что регистрация действует только для пользователя, который её выполнил
    i1["Установка"] --> i2["Разместить файлы"]
    i2 --> i3["Зарегистрировать sparse package"]
    u1["Удаление"] --> u2["Снять регистрацию пакета"]
    u2 --> u3["Удалить файлы"]
    i3 -.-> pu["Регистрация действует только для текущего пользователя"]

Рис. 15: Регистрируйте после размещения файлов, снимайте до удаления и следите за тем, что регистрация — на текущего пользователя.

7.4. Очистка при удалении — что удалять и что оставлять

У очистки при удалении есть ясная линия официальной рекомендации.¹

• Удалять: весь внутренний ключ ProgID, регистрацию Capabilities/RegisteredApplications, регистрацию CLSID расширения оболочки, sparse package (Remove-AppxPackage).
• Оставлять: значение по умолчанию ключа расширения (.kmrpt). Официальная рекомендация — не удалять его, даже если оно всё ещё указывает на внутренний ProgID. После установки трудно судить, не забрало ли другое приложение значение по умолчанию, а Windows просто игнорирует незарегистрированный ProgID значения по умолчанию, так что оставлять его не вредно.
• Вызовите SHChangeNotify(SHCNE_ASSOCCHANGED) и в конце очистки.

Большинство проблем «удалили, а в меню ещё остатки» — утечка в этом проекте очистки.

flowchart TB
    accTitle: Проект очистки при удалении
    accDescr: При удалении удаляете внутренний ключ ProgID, регистрацию CLSID и sparse package; оставляете значение по умолчанию ключа расширения, потому что незарегистрированный ProgID игнорируется; в конце очистки уведомляете об изменении через SHChangeNotify
    un["Удаление"] --> del["Удалить"]
    un --> keep["Оставить"]
    del --> d1["Регистрация ProgID и CLSID"]
    del --> d2["Sparse package"]
    keep --> k1["Значение по умолчанию ключа расширения"]
    k1 -.-> why["Незарегистрированный ProgID игнорируется"]
    d1 --> fin["В конце уведомить через SHChangeNotify"]
    k1 --> fin

Рис. 16: Удалите внутреннюю регистрацию, оставьте значение по умолчанию ключа расширения и в конце очистки уведомите об изменении.

8. Устранение неполадок — нет, дубль, тяжело

8.1. Не появляется в меню

Изолируйте в таком порядке.

1. Какое меню смотрите: регистрация в классическом стиле появляется только на стороне старого меню под Shift+F10. Сначала проверьте оба.
2. Разрядность: только 32-разрядная DLL расширения оболочки не загружается в 64-разрядный Проводник (раздел 4.3).
3. Место регистрации: HKLM/HKCU, путаница Wow6432Node. Подтвердите фактический ключ через reg query.
4. Регистрация пакета: для нового меню подтвердите наличие через Get-AppxPackage, доверие сертификата подписи и путь -ExternalLocation, затем перезапустите Проводник.⁷
5. Пропущенное уведомление: если забыли SHChangeNotify, это видно по тому, помогает ли перезапуск Проводника.

flowchart TB
    accTitle: Порядок изоляции, когда не появляется в меню
    accDescr: Начните с подтверждения, какое меню смотрите, затем изолируйте разрядность DLL, место регистрации в реестре, регистрацию пакета и подпись, и пропущенный SHChangeNotify, в этом порядке
    c1["Подтвердить, какое меню, старое или новое"] --> c2["Подтвердить разрядность DLL"]
    c2 --> c3["Подтвердить место регистрации HKLM и HKCU"]
    c3 --> c4["Подтвердить регистрацию пакета и подпись"]
    c4 --> c5["Распознать пропущенное уведомление перезапуском"]

Рис. 17: Когда «не появляется», изолируйте в порядке меню, которое смотрите, разрядность, место регистрации, регистрация пакета, пропущенное уведомление.

8.2. Появляется дважды или не исчезает

Типичные причины — сосуществование классической регистрации в реестре и регистрации в манифесте, утечка очистки при удалении (раздел 7.4) или остатки ProgID старой версии. Если дважды только в старом меню — думайте об остатках; если на старом и новом — о сосуществовании.

flowchart TB
    accTitle: Изоляция двойного отображения
    accDescr: Дважды только в старом меню указывает на остатки вроде утечки очистки или старого ProgID; дважды на старом и новом указывает на сосуществование классической регистрации в реестре и регистрации в манифесте
    q{"Где появляется дважды?"} -->|только старое меню| zan["Остатки"]
    q -->|старое и новое| hei["Сосуществование"]
    zan -.-> z1["Утечка очистки или оставленный старый ProgID"]
    hei -.-> h1["Классическая регистрация в реестре сосуществует с новой"]

Рис. 18: Дважды только в старом меню указывает на остатки; дважды на старом и новом — на сосуществование.

8.3. Проводник тяжёлый или падает

Когда правый щелчок медленный или определённая папка падает, сначала составьте опись установленных расширений оболочки. Перечислите расширения не от Microsoft инструментом вроде ShellExView от NirSoft, временно отключите подозрительные и найдите виновную DLL двоичным поиском. При сбое подсказкой служит и «Faulting module» в Просмотре событий. Если причиной было внутреннее расширение, подозревайте синхронный ввод-вывод или доступ к сети на пути построения меню (разделы 4.2 и 5.2).

flowchart TB
    accTitle: Поиск виновной DLL, когда тяжело или падает
    accDescr: Перечислите расширения оболочки не от Microsoft в ShellExView, временно отключите подозрительные и найдите виновную DLL двоичным поиском; при сбое подсказкой служит и faulting module в Просмотре событий
    s1["Опись расширений оболочки"] --> s2["Перечислить не от Microsoft"]
    s2 --> s3["Временно отключить и двоичный поиск"]
    s3 --> s4["Найти виновную DLL"]
    crash["При сбое"] -.-> ev["Проверить faulting module"]
    ev -.-> s4

Рис. 19: Временно отключите расширения не от Microsoft и ищите двоично; при сбое используйте и Просмотр событий.

8.4. Для проверки удобна Windows Sandbox

Проверка интеграции с оболочкой строится на подтверждении «установить в чистой среде → поработать → удалить → остатков ноль». Здесь удобна Windows Sandbox (Pro/Enterprise/Education): каждый запуск за несколько секунд поднимает совершенно новую одноразовую Windows, поэтому тесты регистрации и очистки установщика можно гонять сколько угодно. Закроете — всё исчезнет, поэтому подходит и для расследования остаточного реестра.¹⁵

9. Итог

• Ассоциация файлов — трёхслойная структура «ключ расширения → ProgID → verb», а HKCR — объединённое представление HKLM/HKCU Classes. Называйте место записи явно и всегда оборачивайте %1 в кавычки.
• Приложение по умолчанию рассчитано на выбор пользователя и не меняется из программы. Работа установщика — правильно зарегистрироваться как кандидат.
• Классическое расширение оболочки — внутрипроцессная COM DLL, загружаемая в Проводник. Сбой или задержка распространяются на целое; нужны 64 бита; управляемый код не поддерживается; правило — реализация на нативном C++.
• В Windows 11 контекстное меню разделилось надвое. Чтобы поместить свою команду в новое меню, нужны IExplorerCommand плюс манифест MSIX; классический IContextMenu перенесён на сторону «Показать дополнительные параметры».
• Для приложения, которое не может стать MSIX, получение идентичности через sparse package (MSIX с внешним расположением) — реалистичный ответ.
• Если нужно только «открыть этим приложением», ассоциации и статического verb по-прежнему достаточно. Начинать с самого простого средства — и официальная рекомендация.
• После регистрации, изменения или удаления уведомите через SHChangeNotify; при удалении удалите ProgID, но оставьте значение по умолчанию ключа расширения. Для проверки удобна Windows Sandbox.

Если замена ПК на Windows 11 заставила заметить, что «меню спрятали», сначала подтвердите, какой это из (a), (b) и (c) в таблице решения главы 6. Масштаб работы должно быть видно на месте.

Похожие статьи

• Что такое COM / ActiveX / OCX - объясняем различия и связь между ними
• Что такое Reg-Free COM — механизм использования COM без регистрации
• Registry 32-bit/64-bit Redirection and Virtualization Pitfalls — Wow6432Node and the “The Value I Wrote Isn’t There” Problem
• Как выбрать способ распространения Windows-приложения — MSI/MSIX/ClickOnce/xcopy/собственный updater
• Обратная совместимость интерфейсов DLL и COM — таблица решений: какие изменения ломают вызывающую сторону
• Как работает совместимость приложений Windows — оставлять старые приложения в живых режимом совместимости, шимами и Compatibility Administrator

Смежные области консультирования

Компания KomuraSoft LLC занимается проектированием и реализацией ассоциации файлов, контекстных меню и расширений оболочки для деловых приложений; нацеливанием на новое контекстное меню Windows 11 (переход на IExplorerCommand, внедрение sparse package); проверкой регистрации и очистки существующего установщика; и расследованием причины, когда Проводник тяжёлый или падает. Можно начать с решения, что делать с «меню, спрятанным под Показать дополнительные параметры».

• Разработка приложений для Windows
• Использование и перенос существующих активов
• Технические консультации и ревью дизайна
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

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

Почему пункт контекстного меню нашего приложения в Windows 11 появляется только в «Показать дополнительные параметры»?

Потому что в Windows 11 контекстное меню Проводника разделилось на два слоя, старый и новый. В новом меню могут появиться только команды, которые реализуют интерфейс IExplorerCommand и зарегистрированы в манифесте пакета MSIX (= имеют идентичность пакета). Классические расширения оболочки на IContextMenu перенесены в старое меню, которое открывается «Показать дополнительные параметры» (Shift+F10). Само расширение не сломано, поэтому пока продолжает работать, но чтобы оно было в новом меню, нужна миграция на IExplorerCommand и либо упаковка в MSIX, либо выдача идентичности через sparse package.

Может ли установщик назначить наше приложение приложением по умолчанию для файла (тем, что открывается двойным щелчком)?

Нет. Выбор приложения по умолчанию рассчитан на пользователя, и Windows не поддерживает смену приложения по умолчанию ниоткуда, кроме системного интерфейса Параметры. Сведения UserChoice, которые хранят выбор каждого пользователя, обфусцированы, а драйвер-фильтр (UCPD.sys) ещё и защищает их от записи приложениями. Установщик может зарегистрировать ProgID и verb, добавить себя в OpenWithProgIds, чтобы появиться кандидатом в «Открыть с помощью», и направить пользователя на страницу приложений по умолчанию. Правильная реализация — не украсть значение по умолчанию, а подготовиться к тому, чтобы вас выбрали.

Можно ли писать расширение оболочки на управляемом коде, например на C#?

Microsoft прямо заявила, что писать внутрипроцессное расширение оболочки (обработчик контекстного меню, обработчик значков и подобное) на управляемом коде не рекомендуется и не поддерживается. Расширение загружается в Проводник и в процесс любого приложения, открывшего общее диалоговое окно файлов, поэтому столкновения версий CLR, повторный вход и недетерминированное время жизни объектов делают хост нестабильным. Правило — реализация на нативном C++. Обычный EXE, запускаемый из command verb, или внепроцессное расширение вроде обработчика предпросмотра, работающее в отдельном процессе, на управляемом коде допустимы.

Что такое sparse package (MSIX с внешним расположением)?

Небольшой пакет MSIX, который не содержит файлов приложения, только манифест (сведения об идентичности). Для приложения, установленного обычным установщиком (MSI, Inno Setup и подобными), его регистрируют через Add-AppxPackage -ExternalLocation, указывая папку установки, и приложение получает идентичность пакета и может использовать функции, которые её требуют: регистрацию в новом контекстном меню Windows 11 и всплывающие уведомления. Доступно начиная с Windows 10 версии 2004, пакету нужна доверенная на целевой машине подпись кода. Это реалистичный вариант, когда нужна поддержка нового меню без перевода всей поставки на MSIX.

Что делать, если пункт контекстного меню появляется дважды или не исчезает?

Сначала изолируйте причину, проверив, на каком меню он появляется: на новом или на старом (Показать дополнительные параметры). Типичное двойное отображение — сосуществование классической регистрации в реестре и регистрации в манифесте MSIX либо оставшаяся при удалении регистрация ProgID или CLSID расширения. После смены ассоциации подозревайте также пропущенный SHChangeNotify(SHCNE_ASSOCCHANGED); сразу после регистрации пакета — пропущенный перезапуск Проводника. Если это не помогает, временно отключите расширения не от Microsoft в ShellExView и найдите виновную DLL двоичным поиском.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.