Integrasi shell Windows hari ini ── menu konteks, asosiasi file, dan apa yang berubah di Windows 11

Saya dikonsultasikan dengan “kami mengganti PC dengan Windows 11, dan menu konteks aplikasi yang Anda buat untuk kami bertahun-tahun lalu menghilang”. Mendengar lebih teliti, ia tidak menghilang. Klik kanan sebuah file, pilih “Tampilkan opsi selengkapnya” di bagian bawah menu, dan menu yang familiar muncul seperti biasa. Dengan kata lain, item menu aplikasi internal disembunyikan satu klik lebih dalam. Dari lapangan kami mendengar “ini satu klik ekstra” dan “pertanyaan bahwa mereka tidak dapat menemukan itemnya meningkat”.

Ini bukan kegagalan atau salah konfigurasi; ini perubahan desain Windows 11. Menu konteks File Explorer menjadi struktur dua lapisan, lama dan baru, dan syarat untuk menempatkan item di menu baru menjadi hal yang sama sekali berbeda dari sebelumnya.

Sementara itu, mesin asosiasi file dan ekstensi shell di bawahnya masih dunia lama COM dan registri. Kunci ekstensi menunjuk ke ProgID, verb ProgID menahan baris perintah, dan ekstensi yang lebih rumit berjalan sebagai server COM in-process (DLL) yang dimuat ke Explorer — struktur itu tidak berubah selama lebih dari dua puluh tahun. Jika Anda tidak mengetahui baik fondasi yang tidak berubah maupun menu yang Windows 11 belah dua, Anda tidak dapat mengisolasi “menu tidak muncul”, “tersembunyi”, atau “muncul dua kali”.

Artikel ini ditujukan kepada staf IT perusahaan kecil dan menengah serta pengembang Windows yang merawat aplikasi bisnis. Artikel ini merangkai, dalam satu gambar, struktur tiga lapisan asosiasi file, peringatan ekstensi shell klasik, cara menarget menu konteks baru Windows 11, serta pendaftaran, pembersihan, dan pemecahan masalah penginstal.

1. Intinya dulu

• Fondasi menu konteks dan asosiasi file adalah struktur registri tiga lapisan “kunci ekstensi → ProgID → verb”. Kunci ekstensi adalah penunjuk ke ProgID, ProgID adalah substansinya, dan shell\<verb>\command di bawahnya menahan baris perintah.¹
• HKEY_CLASSES_ROOT (HKCR) bukan hive independen; ia adalah tampilan gabungan HKLM\Software\Classes dan HKCU\Software\Classes. Tulis pendaftaran semua pengguna ke HKLM dan pendaftaran per pengguna ke HKCU, dan perlakukan HKCR sebagai hanya-baca.²
• Aplikasi default (yang terbuka saat diklik dua kali) dirancang untuk dipilih pengguna, dan program tidak dapat mencurinya. OS melindungi pilihan pengguna; yang dapat dilakukan penginstal adalah mendaftar sebagai kandidat.³
• Ekstensi shell klasik adalah DLL COM in-process yang dimuat ke Explorer. Crash atau penundaan di ekstensi menyebar ke Explorer secara keseluruhan (dan ke aplikasi lain yang memakai shell); lingkungan 64-bit memerlukan DLL 64-bit; dan implementasi kode terkelola tidak didukung.⁴⁵
• Di Windows 11 menu konteks terbelah dua. Satu-satunya perintah yang muncul di menu baru adalah yang terdaftar dengan IExplorerCommand plus identitas paket; ekstensi IContextMenu klasik dipindahkan ke menu lama di bawah “Tampilkan opsi selengkapnya” (Shift+F10).⁶⁷
• Jalur resmi untuk menempatkan perintah kustom di menu baru adalah mendaftarkan DLL native yang mengimplementasikan IExplorerCommand di manifes MSIX (desktop4:FileExplorerContextMenus). Aplikasi yang tidak dapat menjadi MSIX dapat diberi identitas saja dengan sparse package (MSIX dengan lokasi eksternal).⁷⁸
• Jika yang Anda inginkan hanya “buka dengan aplikasi ini”, asosiasi dan verb statis masih cukup. Anda tidak perlu DLL ekstensi shell, dan Microsoft sendiri menyatakan dengan tegas “pilih metode paling sederhana yang memenuhi persyaratan (verb statis)”.⁹
• Setelah pendaftaran atau perubahan, beritahu dengan SHChangeNotify(SHCNE_ASSOCCHANGED); saat uninstall, hapus ProgID tetapi jangan hapus nilai default kunci ekstensi — itu panduan resmi. Integrasi shell mencakup desain pembersihan.¹¹⁰

Dalam satu kalimat: dunia asosiasi dan verb tidak berubah; hanya cara menu ditampilkan yang terbelah dua di Windows 11. Di bawah ini kita menelusurinya dari fondasi.

2. Cara kerja asosiasi file — struktur tiga lapisan kunci ekstensi → ProgID → verb

2.1. Membaca struktur tiga lapisan dari satu contoh

Apa yang terjadi saat Anda mengklik dua kali file dengan ekstensi tertentu diputuskan oleh tiga lapisan kunci registri.¹

HKEY_CLASSES_ROOT
   .kmrpt                                  ← (1) Kunci ekstensi
      (Default) = KomuraSoft.Report.1      ←     Penunjuk yang hanya menamai ProgID
      OpenWithProgids
         KomuraSoft.Report.1               ←     Kandidat di "Buka dengan"
   KomuraSoft.Report.1                     ← (2) ProgID (substansi asosiasi)
      (Default) = Komura Report document
      DefaultIcon
         (Default) = "C:\Program Files\KomuraSoft\Report.exe",0
      shell                                ← (3) Daftar verb
         open
            command
               (Default) = "C:\Program Files\KomuraSoft\Report.exe" "%1"

• (1) Kunci ekstensi (.kmrpt) hanya menunjuk ke nama ProgID sebagai nilai default. Menulis perintah di sini secara langsung adalah kesalahan.
• (2) ProgID (KomuraSoft.Report.1) adalah substansi asosiasi; ia menahan nama tampilan, ikon, dan daftar verb.
• (3) Verb adalah tindakan seperti “buka” atau “cetak”, dan nilai default shell\open\command adalah baris perintah yang benar-benar diluncurkan.

Pemisahan ini memungkinkan Anda menunjuk beberapa ekstensi (.kmrpt dan .kmrpt-file, misalnya) ke ProgID yang sama, atau menukar ProgID saat meningkatkan aplikasi.

flowchart TB
    accTitle: Struktur tiga lapisan asosiasi file
    accDescr: Kunci ekstensi adalah penunjuk yang nilai defaultnya menamai ProgID; ProgID adalah substansi yang menahan nama tampilan, ikon, dan daftar verb; dan nilai default command di bawah verb adalah baris perintah yang benar-benar diluncurkan
    ext["Kunci ekstensi .kmrpt"] -->|menamai ProgID sebagai default| pid["ProgID KomuraSoft.Report.1"]
    pid --> vb["verb（open dan lainnya di bawah shell）"]
    vb --> cmd["nilai default command"]
    cmd --> exe["Report.exe diluncurkan"]
    pid -.-> attr["Juga menahan nama tampilan dan DefaultIcon"]

Gambar 1: Kunci ekstensi adalah penunjuk, ProgID adalah substansi, dan command verb adalah baris perintah yang benar-benar diluncurkan.

2.2. HKCR adalah “tampilan gabungan” — ke mana Anda menulis mengubah makna

Contoh di atas ditampilkan di bawah HKEY_CLASSES_ROOT (HKCR), tetapi HKCR bukan lokasi penyimpanan fisik; ia adalah tampilan gabungan HKLM\Software\Classes dan HKCU\Software\Classes. Jika kunci yang sama ada di keduanya, sisi HKCU menang.²

flowchart TB
    accTitle: HKCR adalah tampilan gabungan
    accDescr: HKCR adalah HKLM dan HKCU Classes yang ditumpuk; jika kunci yang sama ada di keduanya, HKCU menang; tulis pendaftaran ke HKLM atau HKCU secara eksplisit dan perlakukan HKCR sebagai hanya-baca
    hklm["HKLM\\Software\\Classes（semua pengguna）"] --> hkcr["HKCR（tampilan gabungan）"]
    hkcu["HKCU\\Software\\Classes（per pengguna）"] --> hkcr
    hkcu -.-> win["Jika kunci yang sama ada, HKCU menang"]
    hkcr -.-> ro["Perlakukan sebagai hanya-baca（untuk konfirmasi）"]

Gambar 2: HKCR adalah tampilan HKLM dan HKCU Classes yang ditumpuk; selalu sebut salah satunya sebagai tujuan tulis.

Dalam praktik, pemisahan yang aman adalah selalu menulis pendaftaran ke HKLM atau HKCU secara eksplisit, dan memperlakukan HKCR sebagai hanya-baca (untuk konfirmasi). Hubungan dengan pengalihan registri WOW64 juga layak diurutkan. Data asosiasi langsung di bawah HKLM\Software\Classes seperti kunci ekstensi dan ProgID dibagi antara tampilan registri 32-bit dan 64-bit sejak Windows 7, jadi penginstal 32-bit yang menulisnya tidak kabur ke sisi Wow6432Node. Beberapa subkunci pendaftaran COM seperti Classes\CLSID, sebaliknya, dialihkan, dan saat Anda mendaftarkan ekstensi shell (COM in-process) pemisahan tulis 32-bit / 64-bit penting. Detail ada di “Registry 32-bit/64-bit Redirection and Virtualization Pitfalls — Wow6432Node and the "The Value I Wrote Isn’t There" Problem”.

2.3. Pendaftaran di sisi aplikasi — App Paths, Applications, RegisteredApplications

Ada juga tiga jenis pendaftaran di sisi aplikasi, berpasangan dengan sisi file (ekstensi dan ProgID).¹¹

• App Paths (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths): pendaftaran yang memungkinkan ShellExecuteEx diluncurkan hanya dengan nama file yang dapat dieksekusi. Microsoft merekomendasikan ini karena Anda tidak perlu mencemari variabel lingkungan PATH.
• Applications (HKCR\Applications\<app.exe>): mendefinisikan cara default membuka ketika file sembarang diserahkan di bawah “Buka dengan”, dan nama tampilan aplikasi (FriendlyAppName).
• RegisteredApplications + Capabilities: menyatakan ekstensi dan tipe MIME yang dapat ditangani aplikasi, dan merupakan pendaftaran yang membuatnya muncul sebagai kandidat di halaman pengaturan aplikasi Default Windows.

Sebagian besar konsultasi “aplikasi kami tidak muncul di daftar aplikasi Default” adalah kasus di mana ProgID didaftarkan dan pendaftaran Capabilities ini dihilangkan.

flowchart TB
    accTitle: Tiga jenis pendaftaran di sisi aplikasi
    accDescr: Pendaftaran sisi aplikasi memiliki tiga jenis — App Paths, Applications, dan RegisteredApplications — masing-masing bertanggung jawab untuk peluncuran hanya dengan nama file, cara default membuka di Buka dengan, dan kemunculan di halaman aplikasi Default
    app["Pendaftaran sisi aplikasi"] --> ap["App Paths"]
    app --> apps["Applications"]
    app --> ra["RegisteredApplications"]
    ap --> r1["Luncurkan hanya dengan nama file"]
    apps --> r2["Default di Buka dengan"]
    ra --> r3["Muncul di halaman aplikasi Default"]
    r3 -.-> cap["Deklarasi Capabilities diperlukan"]

Gambar 3: Ada tiga jenis pendaftaran sisi aplikasi, dan muncul sebagai kandidat aplikasi Default memerlukan pendaftaran Capabilities.

2.4. Aplikasi default milik pengguna — perlindungan UserChoice

Menulis ProgID sebagai nilai default kunci ekstensi tidak dengan sendirinya menjadikannya aplikasi default. Hasil pilihan eksplisit pengguna di bawah “Buka dengan” dan sejenisnya disimpan di HKCU\...\Explorer\FileExts\<extension>\UserChoice, dan resolusi asosiasi lebih memilih sisi itu.

Dan poin pentingnya adalah Windows tidak mendukung perubahan terprogram aplikasi default. Pengaturan aplikasi default dirancang untuk dilakukan pengguna melalui UI Pengaturan sistem; data UserChoice diobfuskasi, dan driver filter (UCPD.sys) memblokir penulisan dari aplikasi. Di lingkungan terkelola, Kebijakan Grup / kebijakan MDM adalah sarana resmi.³

Bahwa alat seperti SetUserFTA, yang “meniru hash dan menuliskannya ulang”, telah digunakan adalah sisi lain perlindungan ini. Yang harus Anda masukkan ke penginstal aplikasi internal bukan mencuri default, melainkan tiga (a) pendaftaran ProgID dan verb yang benar, (b) menambahkan diri ke OpenWithProgIds, dan (c) jika perlu, mengarahkan ke halaman Pengaturan.

flowchart TB
    accTitle: Resolusi aplikasi default dan perlindungan UserChoice
    accDescr: Hasil pilihan eksplisit pengguna disimpan di UserChoice dan diutamakan dalam resolusi asosiasi; UCPD.sys memblokir penulisan ulang dari aplikasi, jadi yang dapat dilakukan penginstal adalah mendaftar sebagai kandidat dan mengarahkan ke halaman Pengaturan
    uc["UserChoice（pilihan pengguna）"] -->|diutamakan| res["Resolusi asosiasi"]
    ext["Nilai default kunci ekstensi"] --> res
    wr["Penulisan ulang dari aplikasi"] -.->|UCPD.sys memblokirnya| uc
    res ~~~ inst["Tugas penginstal"]
    inst --> a1["Daftarkan ProgID dan verb"]
    inst --> a2["Tambahkan ke OpenWithProgIds"]
    inst --> a3["Arahkan ke halaman Pengaturan"]

Gambar 4: Resolusi asosiasi mengutamakan pilihan pengguna (UserChoice), dan OS melindunginya dari penulisan ulang oleh aplikasi.

3. Verb selain “Buka” — print, edit, runas, verb kustom

Verb bukan hanya open. Verb standar yang maknanya diketahui OS mencakup edit, print, play, dan preview serta open, dan verb standar secara otomatis mendapat nama tampilan yang mengikuti lokal OS. Verb default yang dipakai saat diklik dua kali diputuskan dalam urutan: nilai default kunci shell → verb pertama di registri → open → openwith.¹²

flowchart TB
    accTitle: Urutan diputuskannya verb default
    accDescr: Verb default yang dipakai saat diklik dua kali adalah yang pertama ditemukan dalam urutan nilai default kunci shell, verb pertama di registri, open, openwith
    s1["nilai default kunci shell"] -->|jika tidak ada| s2["Verb pertama di registri"]
    s2 -->|jika tidak ada| s3["open"]
    s3 -->|jika tidak ada| s4["openwith"]

Gambar 5: Verb default saat diklik dua kali adalah yang pertama ditemukan dalam urutan ini.

Ketika Anda ingin menambahkan tindakan sendiri, daftarkan verb kustom.

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 kustom
         (Default) = Verify report (&V)   ← nama tampilan menu
         command
            (Default) = "C:\Program Files\KomuraSoft\Report.exe" /verify "%1"

Tiga fakta kecil yang membantu diketahui.

• Daftarkan verb bernama runas dan Anda mendefinisikan peluncuran elevasi setara “Jalankan sebagai administrator”, dan ia juga dipakai ketika API keluarga ShellExecute menentukan runas.
• Letakkan nilai kosong bernama Extended pada kunci verb dan ia menjadi verb diperluas yang hanya ditampilkan saat Shift+klik kanan. Nyaman untuk menyembunyikan operasi berbahaya yang jarang dipakai.¹²
• Beberapa asosiasi aplikasi lama masih punya konfigurasi yang mengirim dokumen ke proses yang ada dengan DDE (kunci ddeexec), tetapi meluncurkan verb melalui DDE sudah warisan Deprecated. Tidak ada alasan menulisnya baru.¹²

Kecelakaan lain yang sering terjadi adalah tanda kutip pada baris perintah. Jika elemen string perintah dapat berisi spasi, Anda harus membungkusnya dengan tanda kutip. Itu berlaku tentu untuk jalur EXE seperti C:\Program Files\..., dan %1 (jalur file yang dipilih) harus selalu ditulis "%1". Anda tidak dapat menjamin bahwa jalur file pengguna tidak berisi spasi. My Program.exe tanpa kutip ditafsirkan sebagai “luncurkan My dengan argumen Program.exe”.¹³

flowchart TB
    accTitle: Kecelakaan tanda kutip pada baris perintah
    accDescr: Perintah tanpa kutip dipecah di spasi dan disalahartikan sebagai peluncuran My dengan argumen Program.exe, jadi jalur EXE yang dapat berisi spasi dan %1, yang mewakili jalur file yang dipilih, harus selalu dibungkus tanda kutip
    c1["Perintah tanpa kutip"] -->|dipecah di spasi| bad["Disalahartikan sebagai peluncuran EXE lain"]
    c2["Perintah berkutip"] --> good["Meluncur sesuai niat"]
    c2 -.-> q1["Bungkus jalur EXE dengan tanda kutip"]
    q1 -.-> q2["Selalu bungkus %1 dengan tanda kutip juga"]

Gambar 6: Perintah tanpa kutip dipecah salah di spasi, jadi selalu bungkus jalur EXE dan %1 dengan tanda kutip.

Mekanisme hanya-registri sejauh ini (verb statis) dapat diwujudkan tanpa menulis satu pun DLL, dan tidak berisiko membuat Explorer tidak stabil. Microsoft sendiri berulang kali berkata “sebelum Anda menulis ekstensi shell, pertimbangkan apakah verb statis paling sederhana yang memenuhi persyaratan sudah cukup”.⁹

4. Ekstensi shell klasik — DLL yang berjalan di dalam Explorer

4.1. Jenis ekstensi shell

Persyaratan yang tidak dapat dipenuhi verb statis — “ubah menu secara dinamis tergantung pilihan”, “ganti ikon atau lembar properti” — memakai penangan ekstensi shell. Jenis representatif sebagai berikut.⁴

Semua ini diimplementasikan sebagai kelas COM dan didaftarkan di registri menurut CLSID. Gagasan COM sendiri dibahas di “What Are COM / ActiveX / OCX? - The Differences and Relationships Explained”.

4.2. Apa artinya menjadi server COM in-process

Esensi ekstensi shell klasik adalah bahwa ia server COM in-process (DLL) yang dimuat ke Explorer (atau ke aplikasi mana pun yang membuka dialog file umum). Setiap peringatan mengikuti dari itu.⁴

• Jika ekstensi crash, Explorer ikut jatuh. Jika ia hang, klik kanan membeku beberapa detik. Kerusakan juga tidak terbatas pada Explorer; ia mencapai setiap aplikasi yang menampilkan dialog buka file.
• Pembangunan menu terjadi di thread UI, jadi Anda tidak boleh melakukan pekerjaan lambat seperti akses jaringan atau I/O file pada saat tampilan menu.
• Daftarkan model threading sebagai Apartment secara aturan.

flowchart TB
    accTitle: Struktur kerusakan sampingan ekstensi in-process
    accDescr: DLL ekstensi shell dimuat tidak hanya ke Explorer tetapi juga ke proses aplikasi mana pun yang membuka dialog file, jadi crash atau hang di ekstensi menyebar ke seluruh proses host
    dll["DLL ekstensi shell"] -->|dimuat in-process| exp["Explorer"]
    dll -->|dimuat in-process| any["Aplikasi mana pun yang membuka dialog"]
    exp --> dmg["Crash atau hang menyebar"]
    any --> dmg
    dmg -.-> rule["Jangan lakukan pekerjaan lambat saat tampil"]

Gambar 7: DLL ekstensi berjalan di dalam proses host, jadi crash atau hang menyebar ke host secara keseluruhan.

Selidiki konsultasi seperti “Explorer membeku ketika saya membuka folder tertentu” atau “klik kanan memakan lima detik” dan tidak jarang penyebabnya adalah ekstensi shell pihak ketiga, bukan aplikasi internal. Metode isolasi ada di Bab 8.

4.3. Menyelaraskan bitness — lingkungan 64-bit memerlukan DLL 64-bit

DLL in-process harus cocok dengan bitness proses yang memuatnya. Explorer di Windows 64-bit adalah proses 64-bit, jadi DLL ekstensi shell yang dibangun hanya sebagai 32-bit tidak pernah dimuat dan tidak pernah muncul di menu sama sekali. Tidak ada kesalahan juga, jadi ini penyebab andalan “saya daftarkan tetapi tidak muncul”. Menggabungkan badan aplikasi 32-bit dengan DLL ekstensi shell 64-bit adalah konfigurasi sah, tetapi Anda perlu memperhatikan fakta bahwa pendaftaran COM terbagi menurut bitness (Wow6432Node). Meluncurkan dari command verb adalah EXE proses terpisah, jadi tidak tunduk pada batasan ini (membiarkannya EXE 32-bit tidak apa-apa).

flowchart TB
    accTitle: Menyelaraskan bitness DLL ekstensi shell
    accDescr: Satu-satunya DLL ekstensi shell yang dapat dimuat Explorer 64-bit adalah yang 64-bit; DLL hanya-32-bit tidak pernah muncul di menu dan tidak menghasilkan kesalahan; EXE yang diluncurkan dari command verb adalah proses terpisah dan tidak tunduk pada batasan
    exp["Explorer 64-bit"] -->|dapat memuat| d64["DLL ekstensi shell 64-bit"]
    exp -.->|tidak dapat memuat| d32["DLL hanya-32-bit"]
    d32 -.-> sym["Tidak muncul di menu, tanpa kesalahan"]
    exe["EXE diluncurkan dari verb"] -->|proses terpisah| ok32["Boleh dibiarkan 32-bit"]

Gambar 8: Satu-satunya DLL yang dimuat ke Explorer 64-bit adalah DLL 64-bit; EXE yang diluncurkan dari verb tidak tunduk pada batasan ini.

4.4. Mengapa Anda tidak boleh menulisnya dalam kode terkelola

Saya sering mendapat pertanyaan “dapatkah saya menulis ekstensi shell dalam C#”, tetapi Microsoft menyatakan dengan tegas bahwa menulis ekstensi shell in-process dalam kode terkelola (.NET) tidak direkomendasikan dan di luar dukungan.⁵

Alasannya adalah sifat ekstensi yang dimuat ke proses sembarang. Tabrakan versi CLR (terutama di bawah .NET Framework 4), masalah CLR memasuki kembali loop pesan sambil menunggu kunci, dan masa hidup objek tidak deterministik dari pengumpulan sampah yang bertabrakan dengan kontrak hitungan referensi COM adalah alasan struktural aplikasi host menjadi tidak stabil. Beberapa item telah diringankan di .NET Framework 4 dan kemudian serta .NET modern, tetapi posisi resmi tidak berubah.

Pedoman praktisnya sederhana. Tulis ekstensi in-process dalam C++ native. Jika Anda ingin memakai kode terkelola, jadikan EXE biasa yang diluncurkan dari command verb, atau ekstensi out-of-process yang berjalan di proses terpisah (penangan pratinjau dan sejenisnya).⁵

flowchart TB
    accTitle: Menilai apakah kode terkelola diizinkan
    accDescr: Ekstensi in-process yang berjalan di dalam Explorer ditulis dalam C++ native secara aturan; jika Anda ingin kode terkelola, jadikan EXE biasa yang diluncurkan dari command verb atau ekstensi out-of-process yang berjalan di proses terpisah
    q1{"Berjalan in-process?"} -->|ya| cpp["Tulis dalam C++ native"]
    q1 -->|tidak| mg["Kode terkelola boleh"]
    cpp -.-> why["Risiko CLR / reentrancy membuat host tidak stabil"]
    mg --> e1["EXE diluncurkan verb"]
    mg --> e2["Pratinjau out-of-process"]

Gambar 9: Ekstensi in-process secara aturan adalah C++ native; kode terkelola terbatas pada konfigurasi yang berjalan di proses terpisah.

5. Menu konteks baru Windows 11 — menu yang terbelah dua

5.1. Apa yang terjadi

Windows 11 menyegarkan menu konteks File Explorer. Potong, salin, dan sejenisnya menjadi baris ikon di atas; “Buka” dan “Buka dengan” dikelompokkan di atas; dan perintah yang ditambahkan aplikasi dikelompokkan di bawah perintah standar shell. Ketika satu aplikasi menambahkan beberapa perintah, mereka dikumpulkan ke flyout (submenu) yang dinamai menurut aplikasi.⁶

Dan poin krusialnya adalah ini. Ekstensi shell klasik berbasis IContextMenu tidak dihapus; mereka dipindahkan ke sisi menu lama yang dibuka dengan “Tampilkan opsi selengkapnya” (Shift+F10) dan memuat menu Windows 10 apa adanya.⁶ Identitas konsultasi pembuka “menu disembunyikan” adalah pembelahan ini.

flowchart TB
    accTitle: Menu konteks yang Windows 11 belah dua
    accDescr: Yang terbuka dulu saat klik kanan adalah menu baru; satu-satunya perintah yang muncul di sana adalah yang terdaftar dengan IExplorerCommand dan identitas paket; ekstensi IContextMenu klasik dipindahkan ke menu lama yang dibuka dengan Tampilkan opsi selengkapnya
    rc["Klik kanan sebuah file"] --> newm["Menu baru（Windows 11）"]
    newm --> newi["Perintah IExplorerCommand + identitas"]
    newm -->|Tampilkan opsi selengkapnya Shift+F10| oldm["Menu lama（menu Windows 10）"]
    oldm --> oldi["Ekstensi IContextMenu klasik"]
    newi -.-> fly["Beberapa perintah dikumpulkan ke flyout"]

Gambar 10: Satu-satunya perintah yang muncul di menu baru adalah perintah IExplorerCommand + identitas; ekstensi klasik dipindahkan ke sisi menu lama.

5.2. Jalur resmi ke menu baru — IExplorerCommand + pendaftaran manifes

Ada satu cara menempatkan perintah kustom di menu baru. Siapkan DLL native yang mengimplementasikan antarmuka IExplorerCommand, dan nyatakan server COM serta ekstensi menu konteks di manifes paket MSIX.⁷

<!-- Manifes paket (kutipan) -->
<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 milik ItemType dapat menentukan ekstensi tertentu, atau * (semua file), Directory (folder), atau Directory\Background (latar folder). Selaraskan DLL dengan arsitektur Explorer (64-bit / ARM64).⁷

IExplorerCommand sendiri adalah antarmuka yang ada sejak era Windows 7; Anda mengimplementasikan judul (GetTitle), ikon (GetIcon), status diaktifkan / dinonaktifkan / tersembunyi (GetState), dan eksekusi (Invoke). Metode dipanggil dari thread UI, jadi akses ke sumber daya jaringan dilarang, dan metode pembangunan menu perlu kembali dengan cepat. Kerjakan pekerjaan berat setelah Invoke.¹⁴⁷

flowchart TB
    accTitle: Struktur manifes pendaftaran menu baru
    accDescr: Deklarasi server COM manifes MSIX memetakan CLSID ke DLL, dan deklarasi ekstensi menu konteks mengikat target dan implementasi dengan ItemType dan Verb, sehingga perintah kustom muncul di menu baru
    man["Manifes MSIX"] --> com["Deklarasi server COM"]
    man --> ctx["Deklarasi ekstensi menu"]
    com -->|memetakan CLSID ke DLL| impl["DLL implementasi IExplorerCommand"]
    ctx -->|menentukan dengan ItemType dan Verb| impl
    impl --> shown["Perintah muncul di menu baru"]
    ctx -.-> tgt["Target adalah ekstensi, semua file, dan sejenisnya"]

Gambar 11: Dua deklarasi di manifes mengikat DLL implementasi ke target, dan perintah muncul di menu baru.

5.3. Opsi untuk aplikasi tidak dikemas — mendapatkan identitas saja dengan sparse package

Pintu darurat ketika “aplikasi kami tidak dapat didistribusikan kecuali sebagai MSI; MSIX mustahil” adalah sparse package (MSIX dengan lokasi eksternal). Anda menandatangani MSIX kecil yang hanya manifes, tanpa badan aplikasi, dan mendaftarkannya di akhir penginstal yang ada. Aplikasi kemudian memperoleh identitas paket, dan pendaftaran manifes di atas (= kemunculan di menu baru) menjadi mungkin. Tersedia dari Windows 10 versi 2004, dan paket memerlukan tanda tangan dengan sertifikat yang dipercaya di mesin target.⁸

flowchart TB
    accTitle: Alur memperoleh identitas dengan sparse package
    accDescr: Setelah penginstal yang ada menempatkan badan aplikasi, mendaftarkan sparse package hanya-manifes dengan lokasi eksternal memberi aplikasi identitas paket dan membuat pendaftaran manifes menu baru menjadi mungkin
    inst["Penginstal yang ada"] --> files["Tempatkan badan aplikasi"]
    sp["Sparse package"] -.-> only["Hanya manifes, tanpa badan"]
    files --> reg["Daftarkan dengan lokasi eksternal"]
    sp --> reg
    reg --> id["Peroleh identitas paket"]
    id --> ok["Pendaftaran menu baru menjadi mungkin"]
    sp -.-> sign["Tanda tangan tepercaya diperlukan"]

Gambar 12: Daftarkan sparse package yang tidak berisi badan, dengan lokasi eksternal, dan aplikasi memperoleh identitas paket.

Keuntungan terbesar adalah Anda tidak harus mengganti penginstal; ini jawaban realistis untuk aplikasi yang sudah punya aset penginstal MSI/EXE. Untuk perbandingan dengan pindah penuh ke MSIX, lihat juga “Choosing a Windows App Distribution Method - MSI/MSIX/ClickOnce/xcopy/Custom Updater”.

5.4. Bagaimana verb asosiasi muncul di menu baru

Poin yang mudah disalahpahami: asosiasi Bab 2 dan 3 (ProgID dan verb) masih hidup di menu baru. Verb default saat diklik dua kali, “Buka”, dan kandidat “Buka dengan” diselesaikan dari asosiasi dan ditampilkan di bagian atas menu baru. Jadi jika yang Anda inginkan hanya “dapat membuka dengan aplikasi ini”, Windows 11 tidak membutuhkan pekerjaan ekstra. Di sisi lain, asosiasi bukan ekstensi menu tujuan umum, jadi jika Anda ingin perintah kustom sembarang di lapisan pertama menu baru, Anda memerlukan IExplorerCommand plus identitas — itulah pembagian peran.⁷

flowchart TB
    accTitle: Pembagian peran antara asosiasi dan menu baru
    accDescr: Asosiasi ProgID-dan-verb masih dipakai di menu baru untuk menyelesaikan verb default, Buka, dan Buka dengan, dan ditampilkan di atas; menempatkan perintah kustom sembarang di lapisan pertama menu baru memerlukan IExplorerCommand dan identitas
    assoc["Asos.（ProgID + verb）"] --> sol["Selesaikan default / Buka"]
    sol --> top["Atas menu baru"]
    assoc -.-> keep["Tidak ada pekerjaan ekstra di Win11"]
    cmd["Perintah kustom"] --> need["IExplorerCommand+identitas"]
    need --> first["Lapisan pertama menu baru"]

Gambar 13: Asosiasi masih menangani resolusi keluarga “Buka” di menu baru; hanya perintah kustom yang memerlukan IExplorerCommand plus identitas.

6. Tabel keputusan praktis — opsi mana dari tiga yang diambil

Kita merapikan yang sejauh ini menjadi pilihan praktis tiga arah.

Ada dua titik penilaian. Pertama, jangan bawa (b) atau (c) untuk persyaratan yang (a) akan penuhi. Saat Anda menulis ekstensi shell Anda menanggung tanggung jawab atas stabilitas Explorer. Kedua, (c) hanya “tidak rusak”; sebagai pengalaman pengguna ia tetap satu langkah lebih buruk. Semakin sering perintah dipakai dalam operasi harian, semakin besar imbal hasil pindah ke (b).

flowchart TB
    accTitle: Cara memilih di antara tiga opsi
    accDescr: Jika yang Anda inginkan hanya peluncuran saat diklik dua kali atau Buka, asosiasi dan verb statis cukup; untuk menempatkan perintah kustom di menu baru pakai IExplorerCommand dan pendaftaran manifes MSIX; jika tidak dapat menjadi MSIX, berikan identitas dengan sparse package; pertahankan ekstensi IContextMenu klasik yang ada di sisi menu lama untuk saat ini
    q1{"Buka cukup?"} -->|ya| pa["Asos. + verb statis"]
    q1 -->|tidak| q2{"Kustom di menu baru?"}
    q2 -->|ya| q3{"Dapat menjadi MSIX?"}
    q3 -->|ya| pb1["IExplorerCommand+MSIX"]
    q3 -->|tidak| pb2["Identitas sparse-pkg"]
    q2 -->|tidak| pc["Pertahankan klasik untuk saat ini"]
    pc -.-> old["Hanya sisi menu lama"]
    pa -.-> dllfree["Tidak ada DLL, risiko kecil"]

Gambar 14: Pilih di antara verb statis, IExplorerCommand plus identitas, dan mempertahankan yang klasik, sesuai persyaratan.

7. Penerapan dan pendaftaran dalam praktik — penginstal, sparse package, pembersihan

7.1. HKLM atau HKCU

Selaraskan dengan bentuk penginstal. Semua pengguna (ditempatkan di bawah Program Files, hak administrator) adalah HKLM\Software\Classes; instal per pengguna (tanpa elevasi) adalah HKCU\Software\Classes. Campur keduanya dan Anda menghasilkan pertanyaan jenis “A dapat membukanya tetapi B tidak”. Untuk ekstensi shell yang melibatkan pendaftaran CLSID, Reg-Free COM — yang menghilangkan kebutuhan pendaftaran registri itu sendiri — adalah opsi sah untuk pemakaian COM di dalam aplikasi, tetapi tidak dapat diterapkan ke ekstensi shell yang dimuat Explorer, jadi Anda perlu pendaftaran langsung (“What Is Reg-Free COM - Using COM Without Registration”).

7.2. Setelah perubahan, beritahu — SHChangeNotify

Setelah Anda mendaftar, mengubah, atau menghapus asosiasi, beritahu peristiwa SHCNE_ASSOCCHANGED dengan SHChangeNotify. Lewati ini dan Explorer dapat gagal memperhatikan perubahan sampai reboot.¹¹⁰

// Panggil sekali setelah mengubah asosiasi, mis. dari aksi kustom penginstal
SHChangeNotify(SHCNE_ASSOCCHANGED, SHCNF_IDLIST, nullptr, nullptr);

7.3. Mendaftarkan dan menghapus sparse package

Mendaftarkan dan menghapus sparse package adalah tugas penginstal. Daftarkan setelah menempatkan file; hapus sebelum menghapus file.⁸

# Saat instal: setelah menempatkan file, daftarkan folder instalasi sebagai lokasi eksternal
Add-AppxPackage -Path "C:\Program Files\KomuraSoft\KomuraReport.identity.msix" `
                -ExternalLocation "C:\Program Files\KomuraSoft"

# Saat uninstall: hapus pendaftaran paket sebelum menghapus file
Remove-AppxPackage <package full name>

Poin yang perlu diperhatikan: Add-AppxPackage mendaftar untuk pengguna yang menjalankannya. Jika Anda memanggilnya dari aksi kustom MSI per-mesin, berjalan di bawah LocalSystem tidak memberi identitas kepada pengguna yang menginstal, jadi Anda mengonfigurasinya agar berjalan di bawah impersonasi pengguna. Bahkan begitu, pendaftaran di bawah impersonasi hanya untuk pengguna yang menjalankan instalasi itu. Di PC yang dipakai beberapa pengguna, pengguna lain dan pengguna yang dibuat kemudian tidak punya identitas paket, dan perintah tidak muncul di menu baru. Agar setiap pengguna memakainya, sediakan mekanisme seperti memeriksa pendaftaran paket sendiri saat peluncuran pertama dan mendaftar jika hilang (pendaftaran per pengguna), dan sertakan penghapusan dari setiap pengguna yang punya pendaftaran dalam rencana uninstall. Merefleksikan pendaftaran manifes juga dapat memerlukan restart Explorer (atau keluar).⁷

flowchart TB
    accTitle: Urutan mendaftarkan dan menghapus sparse package
    accDescr: Saat instal daftarkan sparse package setelah menempatkan file; saat uninstall hapus pendaftaran sebelum menghapus file; perhatikan fakta bahwa pendaftaran efektif hanya untuk pengguna yang menjalankannya
    i1["Instal"] --> i2["Tempatkan file"]
    i2 --> i3["Daftarkan sparse package"]
    u1["Uninstall"] --> u2["Hapus pendaftaran paket"]
    u2 --> u3["Hapus file"]
    i3 -.-> pu["Pendaftaran efektif hanya untuk pengguna yang berjalan"]

Gambar 15: Daftarkan setelah menempatkan file, hapus sebelum menghapus file, dan perhatikan fakta bahwa pendaftaran per pengguna yang berjalan.

7.4. Pembersihan saat uninstall — apa yang dihapus dan apa yang ditinggalkan

Pembersihan saat uninstall punya garis panduan resmi yang jelas.¹

• Hapus: seluruh kunci ProgID internal, pendaftaran Capabilities/RegisteredApplications, pendaftaran CLSID ekstensi shell, sparse package (Remove-AppxPackage).
• Tinggalkan: nilai default kunci ekstensi (.kmrpt). Rekomendasi resmi adalah tidak menghapusnya meskipun masih menunjuk ke ProgID internal. Menilai setelah instal apakah aplikasi lain telah mengambil default sulit, dan Windows cukup mengabaikan ProgID nilai default yang tidak terdaftar, jadi meninggalkannya tidak merugikan secara nyata.
• Panggil SHChangeNotify(SHCNE_ASSOCCHANGED) juga di akhir pembersihan.

Sebagian besar masalah “kami uninstall dan sisa masih muncul di menu” adalah kebocoran dalam desain pembersihan ini.

flowchart TB
    accTitle: Desain pembersihan saat uninstall
    accDescr: Saat uninstall Anda menghapus kunci ProgID internal, pendaftaran CLSID, dan sparse package; tinggalkan nilai default kunci ekstensi karena ProgID yang tidak terdaftar diabaikan; beritahu perubahan dengan SHChangeNotify di akhir pembersihan
    un["Uninstall"] --> del["Hapus"]
    un --> keep["Tinggalkan"]
    del --> d1["Pendaftaran ProgID dan CLSID"]
    del --> d2["Sparse package"]
    keep --> k1["Nilai default kunci ekstensi"]
    k1 -.-> why["ProgID yang tidak terdaftar diabaikan"]
    d1 --> fin["Beritahu dengan SHChangeNotify di akhir"]
    k1 --> fin

Gambar 16: Hapus pendaftaran internal, tinggalkan nilai default kunci ekstensi, dan beritahu perubahan di akhir pembersihan.

8. Pemecahan masalah — hilang, ganda, berat

8.1. Tidak muncul di menu

Isolasi dalam urutan ini.

1. Menu mana yang Anda lihat: pendaftaran gaya klasik hanya muncul di sisi menu lama di bawah Shift+F10. Periksa keduanya dulu.
2. Bitness: DLL ekstensi shell hanya-32-bit tidak dimuat ke Explorer 64-bit (Bagian 4.3).
3. Tujuan pendaftaran: HKLM/HKCU, kebingungan Wow6432Node. Konfirmasikan kunci sebenarnya dengan reg query.
4. Pendaftaran paket: untuk menu baru, konfirmasikan kehadiran dengan Get-AppxPackage, kepercayaan sertifikat tanda tangan, dan jalur -ExternalLocation, lalu restart Explorer.⁷
5. Pemberitahuan terlewat: jika SHChangeNotify terlupakan, Anda dapat mengetahuinya dari apakah restart Explorer membuatnya berlaku.

flowchart TB
    accTitle: Urutan isolasi ketika tidak muncul di menu
    accDescr: Mulai dengan mengonfirmasi menu mana yang Anda lihat, lalu isolasi bitness DLL, tujuan pendaftaran registri, pendaftaran paket dan tanda tangan, serta SHChangeNotify yang terlewat, dalam urutan itu
    c1["Konfirmasikan menu mana, lama atau baru"] --> c2["Konfirmasikan bitness DLL"]
    c2 --> c3["Konfirmasikan tujuan pendaftaran HKLM dan HKCU"]
    c3 --> c4["Konfirmasikan pendaftaran paket dan tanda tangan"]
    c4 --> c5["Ketahui pemberitahuan terlewat dengan restart"]

Gambar 17: Ketika “tidak muncul”, isolasi dalam urutan menu yang Anda lihat, bitness, tujuan pendaftaran, pendaftaran paket, pemberitahuan terlewat.

8.2. Muncul dua kali, atau tidak hilang

Penyebab tipikal adalah koeksistensi pendaftaran registri klasik dan pendaftaran manifes, kebocoran pembersihan uninstall (Bagian 7.4), atau sisa ProgID versi lama. Jika muncul dua kali hanya di menu lama, pikirkan sisa; jika muncul di lama dan baru, pikirkan koeksistensi.

flowchart TB
    accTitle: Mengisolasi tampilan ganda
    accDescr: Dua kali hanya di menu lama menunjuk ke sisa seperti kebocoran pembersihan atau ProgID lama; dua kali di lama dan baru menunjuk ke koeksistensi pendaftaran registri klasik dan pendaftaran manifes
    q{"Di mana ia muncul dua kali?"} -->|hanya menu lama| zan["Sisa"]
    q -->|lama dan baru| hei["Koeksistensi"]
    zan -.-> z1["Kebocoran pembersihan atau ProgID lama tertinggal"]
    hei -.-> h1["Pendaftaran registri klasik hidup berdampingan dengan yang baru"]

Gambar 18: Dua kali hanya di menu lama menunjuk ke sisa; dua kali di lama dan baru menunjuk ke koeksistensi.

8.3. Explorer berat atau crash

Ketika klik kanan lambat, atau folder tertentu crash, pertama inventarisasikan ekstensi shell yang terpasang. Daftarkan ekstensi non-Microsoft dengan alat seperti ShellExView NirSoft, nonaktifkan sementara yang mencurigakan, dan cari DLL penyebab dengan pencarian biner. Saat crash, “Faulting module” Event Viewer juga merupakan petunjuk. Jika ekstensi internal adalah penyebabnya, curigai I/O sinkron atau akses jaringan di jalur pembangunan menu (Bagian 4.2 dan 5.2).

flowchart TB
    accTitle: Mengidentifikasi DLL penyebab ketika berat atau crash
    accDescr: Daftarkan ekstensi shell non-Microsoft di ShellExView, nonaktifkan sementara yang mencurigakan dan cari DLL penyebab dengan pencarian biner; saat crash, faulting module Event Viewer juga petunjuk
    s1["Inventarisasi ekstensi shell"] --> s2["Daftarkan yang non-Microsoft"]
    s2 --> s3["Nonaktifkan sementara dan pencarian biner"]
    s3 --> s4["Identifikasi DLL penyebab"]
    crash["Saat crash"] -.-> ev["Periksa faulting module"]
    ev -.-> s4

Gambar 19: Nonaktifkan sementara ekstensi non-Microsoft dan cari secara biner; saat crash, pakai juga Event Viewer.

8.4. Windows Sandbox nyaman untuk verifikasi

Verifikasi integrasi shell didasarkan pada mengonfirmasi “instal di lingkungan bersih → operasikan → uninstall → sisa nol”. Nyaman di sini adalah Windows Sandbox (Pro/Enterprise/Education): setiap peluncuran menampilkan Windows sekali pakai yang baru dalam beberapa detik, jadi Anda dapat menjalankan uji pendaftaran dan pembersihan penginstal sebanyak yang Anda suka. Tutup dan semuanya hilang, jadi ia juga cocok untuk investigasi registri sisa.¹⁵

9. Ringkasan

• Asosiasi file adalah struktur tiga lapisan “kunci ekstensi → ProgID → verb”, dan HKCR adalah tampilan gabungan HKLM/HKCU Classes. Sebut tujuan tulis secara eksplisit, dan selalu bungkus %1 dengan tanda kutip.
• Aplikasi default dirancang untuk dipilih pengguna dan tidak dapat diubah dari program. Tugas penginstal adalah mendaftar dengan benar sebagai kandidat.
• Ekstensi shell klasik adalah DLL COM in-process yang dimuat ke Explorer. Crash atau penundaan menyebar ke keseluruhan; 64-bit diperlukan; kode terkelola tidak didukung; implementasi dalam C++ native adalah aturan.
• Di Windows 11 menu konteks terbelah dua. Menempatkan perintah kustom di menu baru memerlukan IExplorerCommand plus manifes MSIX; IContextMenu klasik dipindahkan ke sisi “Tampilkan opsi selengkapnya”.
• Untuk aplikasi yang tidak dapat menjadi MSIX, memperoleh identitas dengan sparse package (MSIX dengan lokasi eksternal) adalah jawaban realistis.
• Jika yang Anda inginkan hanya “buka dengan aplikasi ini”, asosiasi dan verb statis masih cukup. Memulai dari sarana paling sederhana juga pedoman resmi.
• Setelah pendaftaran, perubahan, atau penghapusan, beritahu dengan SHChangeNotify; saat uninstall, hapus ProgID tetapi tinggalkan nilai default kunci ekstensi. Windows Sandbox nyaman untuk verifikasi.

Jika penggantian PC Windows 11 membuat Anda memperhatikan bahwa “menu disembunyikan”, pertama konfirmasikan mana dari (a), (b), dan (c) di tabel keputusan Bab 6 itu. Anda seharusnya dapat memperkirakan skala pekerjaan di tempat.

Artikel terkait

• What Are COM / ActiveX / OCX? - The Differences and Relationships Explained
• What Is Reg-Free COM - Using COM Without Registration
• Registry 32-bit/64-bit Redirection and Virtualization Pitfalls — Wow6432Node and the “The Value I Wrote Isn’t There” Problem
• Choosing a Windows App Distribution Method - MSI/MSIX/ClickOnce/xcopy/Custom Updater
• DLL and COM Interface Backward Compatibility — A Decision Table for Which Changes Break Callers
• Cara kerja kompatibilitas aplikasi Windows — menjaga aplikasi lama tetap hidup dengan mode kompatibilitas, shim, dan Compatibility Administrator

Area konsultasi terkait

KomuraSoft LLC menangani desain dan implementasi asosiasi file, menu konteks, dan ekstensi shell untuk aplikasi bisnis; menarget menu konteks baru Windows 11 (pindah ke IExplorerCommand, memperkenalkan sparse package); meninjau pendaftaran dan pembersihan penginstal yang ada; dan menyelidiki penyebab Explorer yang berat atau crash. Tidak apa-apa memulai dari memutuskan apa yang harus dilakukan tentang “menu yang tersembunyi di bawah Tampilkan opsi selengkapnya”.

• Pengembangan aplikasi Windows
• Pemanfaatan ulang dan migrasi aset yang ada
• Konsultasi teknis dan tinjauan desain
• Hubungi kami

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Mengapa item menu konteks aplikasi kami di Windows 11 hanya muncul di bawah "Tampilkan opsi selengkapnya"?

Karena di Windows 11 menu konteks File Explorer terbagi dua lapisan, lama dan baru. Satu-satunya perintah yang dapat muncul di menu baru adalah yang mengimplementasikan antarmuka IExplorerCommand dan terdaftar di manifes paket MSIX (= memiliki identitas paket). Ekstensi shell klasik berbasis IContextMenu dipindahkan ke menu lama yang dibuka dengan "Tampilkan opsi selengkapnya" (Shift+F10). Ekstensinya sendiri tidak rusak, jadi untuk saat ini masih berfungsi, tetapi jika Anda ingin menampilkannya di menu baru, Anda perlu migrasi ke IExplorerCommand dan mengemas sebagai MSIX atau memberi identitas dengan sparse package.

Dapatkah penginstal menetapkan aplikasi kami sebagai aplikasi default untuk suatu file (aplikasi yang terbuka saat diklik dua kali)?

Tidak. Memilih aplikasi default dirancang sebagai pekerjaan pengguna, dan Windows tidak mendukung mengubah aplikasi default dari mana pun selain UI Pengaturan sistem. Informasi UserChoice yang menyimpan pilihan setiap pengguna diobfuskasi, dan driver filter (UCPD.sys) juga melindungi tulisannya dari aplikasi. Yang dapat dilakukan penginstal adalah mendaftarkan ProgID dan verb, menambahkan diri ke OpenWithProgIds agar muncul sebagai kandidat di "Buka dengan", dan mengarahkan pengguna ke halaman aplikasi Default. Implementasi yang benar bukan mencuri default, melainkan siap dipilih.

Bolehkah saya menulis ekstensi shell dalam kode terkelola seperti C#?

Microsoft menyatakan dengan tegas bahwa menulis ekstensi shell in-process (penangan menu konteks, penangan ikon, dan sejenisnya) dalam kode terkelola tidak direkomendasikan dan tidak didukung. Ekstensi dimuat ke Explorer dan ke proses aplikasi mana pun yang membuka dialog file umum, sehingga tabrakan versi CLR, reentrancy, dan masa hidup objek yang tidak deterministik membuat aplikasi host tidak stabil. Aturannya adalah implementasi dalam C++ native. EXE biasa yang diluncurkan dari command verb, atau ekstensi out-of-process seperti penangan pratinjau yang berjalan di proses terpisah, boleh dalam kode terkelola.

Apa itu sparse package (MSIX dengan lokasi eksternal)?

Paket MSIX kecil yang tidak berisi file aplikasi, hanya manifes (informasi identitas). Untuk aplikasi yang diinstal secara biasa dengan penginstal yang ada (MSI, Inno Setup, dan sejenisnya), Anda mendaftarkannya dengan Add-AppxPackage -ExternalLocation yang menunjuk ke folder instalasi, dan aplikasi memperoleh identitas paket serta dapat memakai fitur yang mensyaratkan identitas, seperti pendaftaran di menu konteks baru Windows 11 dan notifikasi toast. Tersedia dari Windows 10 versi 2004, dan paket memerlukan tanda tangan kode yang dipercaya di mesin target. Ini opsi realistis ketika Anda ingin dukungan menu baru tanpa memindahkan seluruh metode distribusi ke MSIX.

Apa yang harus saya lakukan ketika item menu konteks muncul dua kali, atau tidak hilang?

Pertama isolasi penyebabnya dengan memeriksa di menu mana ia muncul: menu baru atau menu lama (Tampilkan opsi selengkapnya). Tampilan ganda yang tipikal adalah pendaftaran registri klasik dan pendaftaran manifes MSIX hidup berdampingan, atau pendaftaran ProgID atau CLSID ekstensi tertinggal saat uninstall. Setelah mengubah asosiasi, curigai juga SHChangeNotify(SHCNE_ASSOCCHANGED) yang terlewat; tepat setelah pendaftaran paket, curigai restart Explorer yang terlewat. Jika itu masih tidak menyelesaikan, nonaktifkan sementara ekstensi non-Microsoft di ShellExView dan cari DLL penyebab dengan pencarian biner.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.