Integrasi shell Windows saat ini ── menu klik kanan, asosiasi file, dan perubahan di Windows 11

Saya menerima konsultasi seperti ini: “Kami mengganti PC ke Windows 11, dan menu klik kanan aplikasi yang dulu Anda buat untuk kami tidak muncul lagi.” Setelah ditanya lebih teliti, ternyata menu itu tidak hilang. Klik kanan sebuah file, pilih “Tampilkan opsi selengkapnya” di bagian bawah menu, dan menu yang sudah familiar muncul seperti semula. Artinya, item menu aplikasi perusahaan hanya tersembunyi satu langkah lebih dalam. Dari lapangan terdengar keluhan “jadi bertambah satu kali klik” dan “pertanyaan karena itemnya tidak ditemukan meningkat”.

Ini bukan kerusakan atau salah konfigurasi, melainkan perubahan desain Windows 11. Menu klik kanan Explorer menjadi struktur ganda, baru dan lama, dan syarat untuk menempatkan item di menu baru sama sekali berbeda dari sebelumnya.

Sementara itu, mekanisme asosiasi file dan ekstensi shell di bawahnya masih dunia COM dan registri yang lama. Kunci ekstensi menunjuk ke ProgID, verb pada ProgID memegang baris perintah, dan ekstensi yang lebih rumit berjalan sebagai server COM in-process (DLL) yang dimuat ke Explorer ── struktur ini tidak berubah selama lebih dari dua puluh tahun. Jika fondasi yang tidak berubah itu dan menu yang menjadi dua lapis di Windows 11 tidak keduanya dipahami, “menu tidak muncul”, “tersembunyi”, atau “muncul dua kali” tidak dapat diisolasi.

Artikel ini ditujukan kepada staf IT perusahaan kecil dan menengah serta pengembang Windows yang merawat aplikasi bisnis. Dari struktur tiga lapis asosiasi file, catatan penting tentang ekstensi shell klasik, cara menarget menu konteks baru Windows 11, hingga pendaftaran, pembersihan, dan pemecahan masalah di penginstal, semuanya dihubungkan dalam satu alur.

1. Kesimpulan dulu

• Fondasi menu klik kanan dan asosiasi file adalah struktur registri tiga lapis “kunci ekstensi → ProgID → verb”. Kunci ekstensi adalah penunjuk ke ProgID, ProgID adalah objeknya, dan shell\<verb>\command di bawahnya memegang baris perintah.¹
• HKEY_CLASSES_ROOT (HKCR) bukan hive independen, melainkan tampilan gabungan HKLM\Software\Classes dan HKCU\Software\Classes. Pendaftaran untuk semua pengguna ditulis ke HKLM, pendaftaran per pengguna ke HKCU, dan HKCR diperlakukan sebagai tempat baca.²
• Aplikasi default (yang terbuka saat diklik dua kali) dirancang untuk dipilih pengguna, dan tidak dapat direbut dari program. 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 merambat ke Explorer secara keseluruhan (dan ke aplikasi lain yang memakai shell). Di lingkungan 64-bit DLL 64-bit wajib, dan implementasi dalam kode terkelola tidak didukung.⁴⁵
• Di Windows 11 menu klik kanan menjadi dua lapis. Yang masuk ke menu baru hanyalah perintah yang didaftarkan dengan IExplorerCommand plus identitas paket. Ekstensi IContextMenu klasik dipindahkan ke sisi menu lama di “Tampilkan opsi selengkapnya” (Shift+F10).⁶⁷
• Jalur resmi untuk menampilkan perintah kustom di menu baru adalah mendaftarkan DLL native yang mengimplementasikan IExplorerCommand di manifes MSIX (desktop4:FileExplorerContextMenus). Aplikasi yang tidak dapat dikemas MSIX dapat diberi identitas saja lewat sparse package (MSIX dengan lokasi eksternal).⁷⁸
• Jika yang ingin diwujudkan hanya “buka dengan aplikasi ini”, asosiasi dan verb statis masih cukup. DLL ekstensi shell tidak diperlukan, 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; yang menjadi dua lapis di Windows 11 hanya cara menu ditampilkan. Berikut ini ditelusuri dari fondasinya.

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 16, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Cara kerja asosiasi file ── struktur tiga lapis kunci ekstensi → ProgID → verb

2.1. Membaca struktur tiga lapis dari satu contoh

Apa yang terjadi saat file dengan suatu ekstensi diklik dua kali diputuskan oleh tiga lapis 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 (objek asosiasi)
      (Default) = Dokumen laporan Komura
      DefaultIcon
         (Default) = "C:\Program Files\KomuraSoft\Report.exe",0
      shell                                ← (3) daftar verb (kata kerja)
         open
            command
               (Default) = "C:\Program Files\KomuraSoft\Report.exe" "%1"

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

Pemisahan ini memungkinkan beberapa ekstensi (.kmrpt dan .kmrpt-file, misalnya) diarahkan ke ProgID yang sama, atau ProgID diganti saat aplikasi di-upgrade.

flowchart TB
    accTitle: Struktur tiga lapis asosiasi file
    accDescr: Kunci ekstensi adalah penunjuk yang nilai defaultnya menamai ProgID; ProgID adalah objek yang memegang nama tampilan, ikon, dan daftar verb; nilai default command di bawah verb adalah baris perintah yang benar-benar diluncurkan
    ext["Kunci ekstensi .kmrpt"] -->|menamai ProgID sebagai nilai 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 memegang nama tampilan dan DefaultIcon"]

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

2.2. HKCR adalah “tampilan gabungan” ── ke mana ditulis mengubah makna

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

flowchart TB
    accTitle: HKCR adalah tampilan gabungan
    accDescr: HKCR adalah tumpukan Classes dari HKLM dan HKCU; jika kunci yang sama ada di keduanya, HKCU yang diutamakan; tulis pendaftaran ke HKLM atau HKCU secara eksplisit dan perlakukan HKCR sebagai tempat 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 yang menang"]
    hkcr -.-> ro["Diperlakukan sebagai tempat baca (untuk pemeriksaan)"]

Gambar 2: HKCR adalah tampilan tumpukan Classes dari HKLM dan HKCU; tujuan tulis selalu disebutkan secara eksplisit ke salah satunya.

Dalam praktik, yang aman adalah selalu menulis pendaftaran ke HKLM atau HKCU secara eksplisit, dan memperlakukan HKCR sebagai tempat baca (untuk pemeriksaan). Hubungan dengan pengalihan registri WOW64 juga perlu disusun. Data asosiasi langsung di bawah HKLM\Software\Classes seperti kunci ekstensi dan ProgID dibagi bersama antar tampilan registri 32-bit dan 64-bit sejak Windows 7, sehingga penginstal 32-bit yang menulisnya tidak lari ke sisi Wow6432Node. Sebaliknya, sebagian subkunci pendaftaran COM seperti Classes\CLSID menjadi sasaran pengalihan, dan pada pendaftaran ekstensi shell (COM in-process) yang dibahas kemudian, pemisahan tulis 32-bit/64-bit menjadi relevan. Detailnya dibahas di “Jebakan pengalihan dan virtualisasi registri 32-bit/64-bit”.

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

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

• App Paths (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths): pendaftaran agar dapat diluncurkan dari ShellExecuteEx hanya dengan nama file eksekusi. Microsoft merekomendasikan ini karena tidak perlu mencemari variabel lingkungan PATH.
• Applications (HKCR\Applications\<aplikasi.exe>): mendefinisikan cara buka default ketika file sembarang diserahkan lewat “Buka dengan”, serta nama tampilan aplikasi (FriendlyAppName).
• RegisteredApplications + Capabilities: menyatakan ekstensi dan tipe MIME yang dapat ditangani aplikasi, dan merupakan pendaftaran agar 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 sudah didaftarkan, tetapi pendaftaran Capabilities ini dihilangkan.

flowchart TB
    accTitle: Tiga jenis pendaftaran di sisi aplikasi
    accDescr: Pendaftaran sisi aplikasi ada tiga jenis, yaitu App Paths, Applications, dan RegisteredApplications, masing-masing untuk peluncuran hanya dengan nama file, cara buka default di Buka dengan, dan kemunculan di halaman aplikasi default
    app["Pendaftaran sisi aplikasi"] --> ap["App Paths"]
    app --> apps["Applications"]
    app --> ra["RegisteredApplications"]
    ap --> r1["Diluncurkan hanya dengan nama file"]
    apps --> r2["Default di Buka dengan"]
    ra --> r3["Muncul di halaman aplikasi default"]
    r3 -.-> cap["Syaratnya deklarasi Capabilities"]

Gambar 3: Pendaftaran sisi aplikasi ada tiga jenis; agar masuk kandidat halaman aplikasi default, pendaftaran Capabilities diperlukan.

2.4. Aplikasi default milik pengguna ── perlindungan UserChoice

Menulis ProgID ke nilai default kunci ekstensi tidak otomatis menjadikan aplikasi itu aplikasi default. Hasil pilihan eksplisit pengguna lewat “Buka dengan” dan sejenisnya disimpan di HKCU\...\Explorer\FileExts\<ekstensi>\UserChoice, dan saat asosiasi diselesaikan, sisi ini yang diutamakan.

Yang penting: Windows tidak mendukung perubahan aplikasi default oleh program. Pengaturan aplikasi default dirancang agar pengguna melakukannya lewat UI Pengaturan sistem. Data UserChoice diobfuskasi, dan driver filter (UCPD.sys) memblokir penulisan dari aplikasi. Di lingkungan terkelola, sarana resminya adalah kebijakan Grup / kebijakan MDM.³

Dulu alat seperti SetUserFTA yang “meniru hash lalu menimpa” dipakai; itu adalah sisi sebaliknya dari perlindungan ini. Yang seharusnya dimasukkan ke penginstal aplikasi perusahaan bukan merebut default, melainkan tiga hal: (a) pendaftaran ProgID dan verb yang benar, (b) penambahan ke OpenWithProgIds, (c) jika perlu, pengarahan ke halaman pengaturan.

flowchart TB
    accTitle: Penyelesaian aplikasi default dan perlindungan UserChoice
    accDescr: Hasil pilihan eksplisit pengguna disimpan di UserChoice dan diutamakan saat asosiasi diselesaikan; penulisan dari aplikasi dipotong oleh UCPD.sys, sehingga yang dapat dilakukan penginstal hanya pendaftaran sebagai kandidat dan pengarahan ke halaman pengaturan
    uc["UserChoice (pilihan pengguna)"] -->|diutamakan| res["Penyelesaian asosiasi"]
    ext["Nilai default kunci ekstensi"] --> res
    wr["Penulisan dari aplikasi"] -.->|UCPD.sys memotong| uc
    res ~~~ inst["Pekerjaan penginstal"]
    inst --> a1["Pendaftaran ProgID dan verb"]
    inst --> a2["Penambahan ke OpenWithProgIds"]
    inst --> a3["Pengarahan ke halaman pengaturan"]

Gambar 4: Saat asosiasi diselesaikan, pilihan pengguna (UserChoice) yang diutamakan, dan penulisan dari aplikasi dilindungi OS.

3. Verb selain “buka” ── print, edit, runas, verb kustom

Verb tidak hanya open. Verb standar yang maknanya dikenal OS mencakup open plus edit, print, play, preview, dan lainnya. Verb standar otomatis mendapat nama tampilan sesuai locale OS. Verb default yang dipakai saat diklik dua kali ditentukan dalam urutan: nilai default kunci shell → verb pertama di registri → open → openwith.¹²

flowchart TB
    accTitle: Urutan penentuan verb default
    accDescr: Verb default saat diklik dua kali ditentukan oleh yang pertama ditemukan, dalam urutan nilai default kunci shell, verb pertama di registri, open, lalu 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 memakai yang pertama ditemukan dalam urutan ini.

Untuk menambah kata kerja 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) = Verifikasi laporan(&V)   ← nama tampilan di menu
         command
            (Default) = "C:\Program Files\KomuraSoft\Report.exe" /verify "%1"

Tiga catatan kecil yang berguna:

• Jika verb bernama runas didaftarkan, peluncuran dengan elevasi setara “Jalankan sebagai administrator” dapat didefinisikan, dan juga dipakai saat API keluarga ShellExecute diluncurkan dengan runas.
• Jika nilai kosong bernama Extended diletakkan pada kunci verb, itu menjadi verb tambahan yang hanya tampil saat Shift ditahan sambil klik kanan. Berguna untuk menyembunyikan operasi berbahaya yang jarang dipakai.¹²
• Pada asosiasi aplikasi lama, kadang masih tersisa konfigurasi yang mengirim dokumen ke proses yang sudah berjalan lewat DDE (kunci ddeexec). Peluncuran verb lewat DDE sudah warisan yang tidak direkomendasikan (Deprecated). Tidak ada alasan menulisnya untuk yang baru.¹²

Satu lagi yang sering menimbulkan insiden: tanda kutip pada baris perintah. Jika elemen string perintah dapat mengandung spasi, elemen itu harus selalu diapit tanda kutip. Path EXE seperti C:\Program Files\... tentu saja, dan %1 (path file yang dipilih) harus selalu ditulis "%1". Tidak ada jaminan path file pengguna bebas spasi. My Program.exe tanpa tanda kutip ditafsirkan sebagai “luncurkan My dengan argumen Program.exe”.¹³

flowchart TB
    accTitle: Insiden tanda kutip pada baris perintah
    accDescr: Perintah tanpa tanda kutip dipotong di posisi spasi sehingga My diluncurkan dengan argumen Program.exe; path EXE dan %1 yang merepresentasikan path file yang dipilih, jika dapat mengandung spasi, harus selalu diapit tanda kutip
    c1["command tanpa tanda kutip"] -->|dipotong di spasi| bad["Salah tafsir sebagai peluncuran EXE lain"]
    c2["command dengan tanda kutip"] --> good["Diluncurkan sesuai niat"]
    c2 -.-> q1["Apit path EXE dengan tanda kutip"]
    q1 -.-> q2["%1 juga selalu diapit tanda kutip"]

Gambar 6: Perintah tanpa tanda kutip terpotong salah di spasi, jadi path EXE dan %1 selalu diapit tanda kutip.

Mekanisme registri sampai di sini (verb statis) dapat diwujudkan tanpa menulis satu pun DLL, dan tanpa risiko membuat Explorer tidak stabil. Microsoft sendiri berulang kali menyatakan: “sebelum menulis ekstensi shell, pertimbangkan apakah persyaratan dapat dipenuhi dengan verb statis paling sederhana”.⁹

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

4.1. Jenis ekstensi shell

Untuk persyaratan yang tidak cukup dengan verb statis — “mengubah menu secara dinamis sesuai pilihan”, “mengganti ikon atau halaman properti” — dipakai penangan ekstensi shell. Jenis yang representatif adalah sebagai berikut.⁴

Semua ini diimplementasikan sebagai kelas COM dan CLSID-nya didaftarkan di registri. Cara berpikir COM sendiri dibahas di “Apa itu COM / ActiveX / OCX”.

4.2. Artinya menjadi server COM in-process

Esensi ekstensi shell klasik adalah server COM in-process (DLL) yang dimuat ke dalam proses Explorer (atau aplikasi mana pun yang membuka dialog file umum). Semua catatan penting diturunkan dari sini.⁴

• Jika ekstensi crash, Explorer ikut crash. Jika hang, klik kanan membeku beberapa detik. Kerusakannya tidak terbatas pada Explorer; semua aplikasi yang menampilkan dialog buka file terkena dampak.
• Penyusunan menu dilakukan di thread UI, jadi pemrosesan lambat seperti akses jaringan atau I/O file tidak boleh dilakukan saat menu ditampilkan.
• Model threading pada prinsipnya didaftarkan sebagai Apartment.

flowchart TB
    accTitle: Struktur terdampak pada ekstensi in-process
    accDescr: DLL ekstensi shell dimuat tidak hanya ke Explorer tetapi juga ke proses aplikasi mana pun yang membuka dialog file, sehingga crash atau hang pada ekstensi merambat ke seluruh proses host
    dll["DLL ekstensi shell"] -->|dimuat ke dalam proses| exp["Explorer"]
    dll -->|dimuat ke dalam proses| any["Aplikasi mana pun yang membuka dialog"]
    exp --> dmg["Crash atau hang merambat"]
    any --> dmg
    dmg -.-> rule["Jangan lakukan pemrosesan lambat saat menampilkan"]

Gambar 7: DLL ekstensi berjalan di dalam proses host, jadi crash atau hang merambat ke seluruh host.

Saat menyelidiki keluhan “Explorer membeku saat folder tertentu dibuka” atau “klik kanan butuh 5 detik”, tidak jarang penyebabnya bukan aplikasi perusahaan, melainkan ekstensi shell pihak ketiga. Cara isolasinya dibahas di bab 8.

4.3. Kecocokan bitness ── di lingkungan 64-bit DLL 64-bit wajib

DLL in-process harus sama bitness-nya dengan proses yang memuatnya. Explorer di Windows 64-bit adalah proses 64-bit, jadi DLL ekstensi shell yang hanya dibangun 32-bit tidak dimuat sama sekali, dan tidak pernah muncul di menu. Tidak ada error, sehingga ini penyebab klasik “sudah didaftarkan tetapi tidak muncul”. Kombinasi aplikasi 32-bit dengan DLL ekstensi shell 64-bit adalah konfigurasi yang sah, tetapi perlu diingat bahwa pendaftaran COM terpisah per bitness (Wow6432Node). Peluncuran dari command verb adalah EXE di proses terpisah, jadi tidak terkena batasan ini (tetap 32-bit tidak masalah).

flowchart TB
    accTitle: Kecocokan bitness DLL ekstensi shell
    accDescr: Yang dapat dimuat ke Explorer 64-bit hanya DLL ekstensi shell 64-bit; DLL yang hanya 32-bit tidak muncul di menu tanpa error; EXE yang diluncurkan dari command verb adalah proses terpisah sehingga tidak terkena batasan
    exp["Explorer 64-bit"] -->|dapat dimuat| d64["DLL ekstensi shell 64-bit"]
    exp -.->|tidak dapat dimuat| d32["DLL hanya 32-bit"]
    d32 -.-> sym["Tidak muncul di menu, tanpa error"]
    exe["EXE yang diluncurkan verb"] -->|proses terpisah| ok32["Tetap 32-bit tidak masalah"]

Gambar 8: Yang dimuat ke Explorer 64-bit hanya DLL 64-bit; EXE yang diluncurkan verb tidak terkena batasan ini.

4.4. Alasan tidak boleh ditulis dalam kode terkelola

Pertanyaan “bisakah ekstensi shell ditulis dalam C#” sering muncul, tetapi Microsoft menyatakan dengan tegas bahwa menulis ekstensi shell in-process dalam kode terkelola (.NET) tidak direkomendasikan dan berada di luar dukungan.⁵

Alasannya ada pada sifat ekstensi yang dimuat ke proses mana pun. Konflik versi CLR (terutama di bawah .NET Framework 4), masalah CLR yang masuk kembali ke message loop saat menunggu kunci, dan masa hidup objek yang tidak deterministik karena garbage collection yang bertabrakan dengan kontrak reference count COM — faktor yang membuat aplikasi host tidak stabil ada secara struktural. Beberapa butir mereda di .NET Framework 4 dan seterusnya atau .NET modern, tetapi posisi resmi tidak berubah.

Pedoman praktiknya sederhana. Ekstensi in-process ditulis dalam C++ native. Jika 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: Keputusan boleh tidaknya kode terkelola
    accDescr: Ekstensi in-process yang berjalan di dalam proses Explorer pada prinsipnya ditulis dalam C++ native; jika ingin kode terkelola, jadikan EXE biasa yang diluncurkan dari command verb atau ekstensi out-of-process di proses terpisah
    q1{"Ekstensi yang berjalan di dalam proses?"} -->|ya| cpp["Tulis dalam C++ native"]
    q1 -->|tidak| mg["Kode terkelola juga boleh"]
    cpp -.-> why["Host tidak stabil karena konflik CLR atau reentrancy"]
    mg --> e1["EXE biasa yang diluncurkan verb"]
    mg --> e2["Ekstensi proses terpisah seperti pratinjau"]

Gambar 9: Ekstensi in-process pada prinsipnya C++ native; kode terkelola dibatasi pada konfigurasi yang berjalan di proses terpisah.

5. Menu konteks baru Windows 11 ── menu yang menjadi dua lapis

5.1. Apa yang terjadi

Windows 11 menyegarkan menu klik kanan Explorer. Potong, salin, dan sejenisnya menjadi deretan ikon di bagian atas; “Buka” dan “Buka dengan” dikelompokkan di bagian atas; perintah yang ditambahkan aplikasi dikelompokkan di bawah perintah standar shell. Jika satu aplikasi menambahkan beberapa perintah, perintah itu digabung ke flyout (submenu) berlabel nama aplikasi.⁶

Poin kuncinya ini. Ekstensi shell berbasis IContextMenu klasik tidak dihapus, melainkan dipindahkan ke sisi menu lama yang memuat menu Windows 10 apa adanya, dibuka lewat “Tampilkan opsi selengkapnya” (Shift+F10).⁶ Itulah identitas “menu tersembunyi” pada konsultasi di pembuka.

flowchart TB
    accTitle: Menu klik kanan yang menjadi dua lapis di Windows 11
    accDescr: Yang pertama terbuka saat klik kanan adalah menu baru; yang masuk ke sana hanyalah perintah yang didaftarkan dengan IExplorerCommand dan identitas paket; ekstensi IContextMenu klasik dipindahkan ke sisi menu lama yang dibuka lewat Tampilkan opsi selengkapnya
    rc["Klik kanan 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 digabung ke flyout"]

Gambar 10: Yang masuk menu baru hanyalah perintah IExplorerCommand + identitas; ekstensi klasik dipindahkan ke sisi menu lama.

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

Cara menampilkan perintah kustom di menu baru hanya satu. Siapkan DLL native yang mengimplementasikan antarmuka IExplorerCommand, lalu deklarasikan server COM dan ekstensi menu konteks di manifes paket MSIX.⁷

<!-- Kutipan manifes paket -->
<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>

Pada Type di ItemType, selain ekstensi tertentu, dapat ditentukan * (semua file), Directory (folder), dan Directory\Background (latar folder). DLL disesuaikan dengan arsitektur Explorer (64-bit/ARM64).⁷

IExplorerCommand sendiri adalah antarmuka yang sudah ada sejak era Windows 7, dan mengimplementasikan judul (GetTitle), ikon (GetIcon), status aktif/nonaktif/tersembunyi (GetState), dan eksekusi (Invoke). Metode dipanggil dari thread UI, jadi akses ke sumber daya jaringan dilarang, dan metode penyusunan menu harus kembali dengan cepat. Pemrosesan berat dilakukan setelah Invoke.¹⁴⁷

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

Gambar 11: Dua deklarasi di manifes mengikat DLL implementasi dengan target, lalu perintah masuk ke menu baru.

5.3. Pilihan untuk aplikasi non-paket ── memperoleh identitas saja dengan sparse package

Jalan keluar jika “aplikasi kami hanya bisa didistribusikan sebagai MSI; MSIX tidak mungkin” adalah sparse package (MSIX dengan lokasi eksternal). Buat MSIX kecil berisi hanya manifes, tanpa badan aplikasi, tandatangani, lalu daftarkan di akhir penginstal yang sudah ada. Dengan itu aplikasi memperoleh identitas paket, dan pendaftaran manifes di atas (= tampil di menu baru) menjadi mungkin. Tersedia sejak 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 badan aplikasi diletakkan oleh penginstal yang sudah ada, sparse package yang hanya berisi manifes didaftarkan dengan lokasi eksternal; aplikasi memperoleh identitas paket dan pendaftaran manifes ke menu baru menjadi mungkin
    inst["Penginstal yang sudah ada"] --> files["Meletakkan badan aplikasi"]
    sp["sparse package"] -.-> only["Hanya manifes, tanpa badan"]
    files --> reg["Didaftarkan dengan lokasi eksternal"]
    sp --> reg
    reg --> id["Memperoleh identitas paket"]
    id --> ok["Pendaftaran menu baru menjadi mungkin"]
    sp -.-> sign["Tanda tangan yang dipercaya diperlukan"]

Gambar 12: Sparse package tanpa badan aplikasi, didaftarkan dengan lokasi eksternal, membuat aplikasi memperoleh identitas paket.

Keuntungan terbesarnya adalah penginstal tidak perlu diganti; ini solusi realistis bagi aplikasi yang punya aset penginstal MSI/EXE. Perbandingan dengan migrasi penuh ke MSIX juga ada di “Cara memilih metode distribusi aplikasi Windows”.

5.4. Bagaimana verb asosiasi terlihat di menu baru

Poin yang mudah disalahpahami: asosiasi di bab 2–3 (ProgID dan verb) tetap hidup di menu baru. Verb default klik dua kali, “Buka”, dan kandidat “Buka dengan” diselesaikan dari asosiasi dan ditampilkan di bagian atas menu baru. Jadi jika hanya ingin “dapat dibuka dengan aplikasi ini”, di Windows 11 pun tidak perlu penanganan tambahan. Di sisi lain, asosiasi bukan ekstensi menu yang bersifat umum, jadi jika ingin menampilkan perintah kustom sembarang di hierarki pertama menu baru, IExplorerCommand + identitas diperlukan — itu pembagian perannya.⁷

flowchart TB
    accTitle: Pembagian peran asosiasi dan menu baru
    accDescr: Asosiasi ProgID dan verb tetap dipakai di menu baru untuk menyelesaikan verb default klik dua kali serta Buka dan Buka dengan, lalu ditampilkan di bagian atas; untuk menampilkan perintah kustom sembarang di hierarki pertama menu baru, IExplorerCommand dan identitas diperlukan
    assoc["Asosiasi (ProgID dan verb)"] --> sol["Penyelesaian verb default dan Buka"]
    sol --> top["Ditampilkan di bagian atas menu baru"]
    assoc -.-> keep["Di Windows 11 pun tidak perlu penanganan tambahan"]
    cmd["Perintah kustom sembarang"] --> need["IExplorerCommand + identitas"]
    need --> first["Ditampilkan di hierarki pertama menu baru"]

Gambar 13: Asosiasi tetap menyelesaikan keluarga “Buka” di menu baru; hanya perintah kustom yang memerlukan IExplorerCommand + identitas.

6. Tabel keputusan praktis ── mana dari tiga pilihan yang diambil

Sampai di sini disusun menjadi tiga pilihan praktis.

Ada dua titik keputusan. Pertama, jangan membawa (b) atau (c) ke persyaratan yang cukup dengan (a). Begitu ekstensi shell ditulis, tanggung jawab atas stabilitas Explorer ikut dipikul. Kedua, (c) “tidak rusak”, tetapi secara pengalaman pengguna tetap diletakkan satu tingkat lebih dalam. Semakin sering perintah itu dipakai dalam operasi harian, semakin besar imbal hasil investasi migrasi ke (b).

flowchart TB
    accTitle: Cara memilih tiga opsi
    accDescr: Jika hanya ingin diluncurkan lewat klik dua kali atau Buka, asosiasi dan verb statis cukup; jika ingin perintah kustom di menu baru, IExplorerCommand dan pendaftaran manifes MSIX; jika tidak dapat MSIX, beri identitas dengan sparse package; ekstensi IContextMenu klasik yang sudah ada dipertahankan untuk saat ini di sisi menu lama
    q1{"Cukup Buka saja?"} -->|ya| pa["Asosiasi + verb statis"]
    q1 -->|tidak| q2{"Perintah kustom di menu baru?"}
    q2 -->|ya| q3{"Dapat dikemas MSIX?"}
    q3 -->|ya| pb1["IExplorerCommand + MSIX"]
    q3 -->|tidak| pb2["Identitas lewat sparse package"]
    q2 -->|tidak| pc["Klasik dipertahankan untuk saat ini"]
    pc -.-> old["Hanya tampil di sisi menu lama"]
    pa -.-> dllfree["Tanpa DLL, risikonya kecil"]

Gambar 14: Pilih dari tiga opsi sesuai persyaratan: verb statis, IExplorerCommand + identitas, atau mempertahankan yang klasik.

7. Praktik penyebaran dan pendaftaran ── penginstal, sparse package, pembersihan

7.1. HKLM atau HKCU

Diselaraskan dengan bentuk penginstal. Instalasi untuk semua pengguna (diletakkan di Program Files, hak administrator) memakai HKLM\Software\Classes; instalasi per pengguna (tanpa elevasi hak) memakai HKCU\Software\Classes. Jika dicampur, muncul pertanyaan tipe “A bisa membuka, B tidak bisa”. Untuk ekstensi shell yang disertai pendaftaran CLSID, Reg-Free COM yang meniadakan pendaftaran registri itu sendiri efektif untuk pemakaian COM di dalam aplikasi, tetapi tidak dapat diterapkan pada ekstensi shell yang dimuat Explorer, jadi pendaftaran jalur resmi tetap diperlukan (“Apa itu Reg-Free COM”).

7.2. Setelah diubah, beritahu ── SHChangeNotify

Setelah asosiasi didaftarkan, diubah, atau dihapus, beritahu peristiwa SHCNE_ASSOCCHANGED dengan SHChangeNotify. Jika ini dihilangkan, perubahan kadang tidak dikenali Explorer sampai dimulai ulang.¹¹⁰

// Panggil sekali setelah mengubah asosiasi, misalnya di custom action penginstal
SHChangeNotify(SHCNE_ASSOCCHANGED, SHCNF_IDLIST, nullptr, nullptr);

7.3. Pendaftaran dan pencabutan sparse package

Pendaftaran dan pencabutan sparse package adalah pekerjaan penginstal. Pendaftaran dilakukan setelah file diletakkan; pencabutan sebelum file dihapus.⁸

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

# Saat uninstall: cabut pendaftaran paket sebelum menghapus file
Remove-AppxPackage <nama lengkap paket>

Catatan: Add-AppxPackage didaftarkan terhadap pengguna yang menjalankannya. Jika dipanggil dari custom action MSI per-machine, menjalankannya sebagai LocalSystem tidak memberi identitas kepada pengguna yang menginstal, jadi konfigurasinya dijalankan dengan peniruan pengguna (impersonate). Namun, yang terdaftar lewat impersonasi juga hanya pengguna yang menjalankan instalasi itu. Di lingkungan satu PC dipakai banyak pengguna, pengguna lain atau pengguna yang dibuat kemudian tidak punya identitas paket, dan perintah tidak muncul di menu baru. Agar dipakai semua pengguna, siapkan mekanisme seperti memeriksa pendaftaran paket sendiri saat aplikasi pertama kali dijalankan lalu mendaftar jika belum (pendaftaran per pengguna), dan rencanakan pencabutan dari setiap pengguna yang sudah terdaftar saat uninstall. Selain itu, agar pendaftaran manifes berlaku, kadang diperlukan mulai ulang Explorer (atau sign-out).⁷

flowchart TB
    accTitle: Urutan pendaftaran dan pencabutan sparse package
    accDescr: Saat instalasi, daftarkan sparse package setelah file diletakkan; saat uninstall, cabut pendaftaran sebelum file dihapus; perhatikan bahwa pendaftaran hanya berlaku bagi pengguna yang menjalankannya
    i1["Instalasi"] --> i2["Letakkan file"]
    i2 --> i3["Daftarkan sparse package"]
    u1["Uninstall"] --> u2["Cabut pendaftaran paket"]
    u2 --> u3["Hapus file"]
    i3 -.-> pu["Pendaftaran hanya berlaku bagi pengguna yang menjalankan"]

Gambar 15: Daftar setelah file diletakkan, cabut sebelum file dihapus, dan perhatikan bahwa pendaftaran bersifat per pengguna yang menjalankan.

7.4. Pembersihan saat uninstall ── yang dihapus dan yang ditinggalkan

Untuk pembersihan saat uninstall, panduan resmi memberi arahan yang jelas.¹

• Yang dihapus: seluruh kunci ProgID milik sendiri, pendaftaran Capabilities/RegisteredApplications, pendaftaran CLSID ekstensi shell, sparse package (Remove-AppxPackage).
• Yang ditinggalkan: nilai default kunci ekstensi (.kmrpt). Rekomendasi resmi adalah jangan menghapusnya meski masih menunjuk ke ProgID sendiri. Sulit menilai apakah aplikasi lain sudah mengambil default setelah instalasi, dan Windows mengabaikan saja ProgID pada nilai default jika tidak terdaftar, jadi meninggalkannya tidak menimbulkan dampak nyata.
• Di akhir pembersihan, panggil juga SHChangeNotify(SHCNE_ASSOCCHANGED).

Banyak masalah “setelah uninstall masih ada sisa di menu” berasal dari celah pada desain pembersihan ini.

flowchart TB
    accTitle: Desain pembersihan saat uninstall
    accDescr: Saat uninstall, hapus kunci ProgID sendiri, pendaftaran CLSID, dan sparse package; nilai default kunci ekstensi ditinggalkan karena diabaikan jika tidak terdaftar; di akhir pembersihan beritahu perubahan dengan SHChangeNotify
    un["Uninstall"] --> del["Yang dihapus"]
    un --> keep["Yang ditinggalkan"]
    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["Di akhir, beritahu dengan SHChangeNotify"]
    k1 --> fin

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

8. Pemecahan masalah ── tidak muncul, ganda, berat

8.1. Tidak muncul di menu

Isolasi secara berurutan.

1. Menu mana yang sedang dilihat: pendaftaran cara lama hanya muncul di sisi menu lama Shift+F10. Periksa keduanya dulu.
2. Bitness: DLL ekstensi shell yang hanya 32-bit tidak dimuat ke Explorer 64-bit (pasal 4.3).
3. Tujuan pendaftaran: tertukarnya HKLM/HKCU atau Wow6432Node. Periksa kunci yang benar-benar ada dengan reg query.
4. Pendaftaran paket: jika untuk menu baru, periksa ada tidaknya pendaftaran dengan Get-AppxPackage, kepercayaan sertifikat tanda tangan, dan path -ExternalLocation, lalu mulai ulang Explorer.⁷
5. Pemberitahuan terlewat: jika SHChangeNotify terlupa, dapat dibedakan dari apakah mulai ulang Explorer membuatnya berlaku.

flowchart TB
    accTitle: Urutan isolasi saat tidak muncul di menu
    accDescr: Mulai dari memeriksa menu mana yang sedang dilihat, lalu bitness DLL, tujuan pendaftaran registri, pendaftaran paket dan tanda tangan, kemudian pemberitahuan SHChangeNotify yang terlewat
    c1["Pastikan menu baru atau lama"] --> c2["Periksa bitness DLL"]
    c2 --> c3["Periksa tujuan pendaftaran HKLM dan HKCU"]
    c3 --> c4["Periksa pendaftaran paket dan tanda tangan"]
    c4 --> c5["Bedakan pemberitahuan terlewat dengan mulai ulang"]

Gambar 17: Saat “tidak muncul”, isolasi dalam urutan menu yang dilihat, bitness, tujuan pendaftaran, pendaftaran paket, lalu pemberitahuan terlewat.

8.2. Muncul dua kali atau tidak hilang

Penyebab tipikal adalah pendaftaran registri cara lama dan pendaftaran manifes hidup berdampingan, pembersihan uninstall yang tidak lengkap (pasal 7.4), atau sisa ProgID versi lama. Jika ganda hanya di menu lama, arahnya sisa; jika muncul di baru dan lama, arahnya hidup berdampingan.

flowchart TB
    accTitle: Isolasi tampilan ganda
    accDescr: Jika ganda hanya di menu lama, arahnya sisa pembersihan atau ProgID lama; jika muncul di baru dan lama, arahnya pendaftaran registri cara lama dan pendaftaran manifes hidup berdampingan
    q{"Ganda di mana?"} -->|hanya menu lama| zan["Tipe sisa"]
    q -->|baru dan lama| hei["Tipe hidup berdampingan"]
    zan -.-> z1["Kebocoran pembersihan atau sisa ProgID lama"]
    hei -.-> h1["Pendaftaran registri lama dan pendaftaran baru hidup berdampingan"]

Gambar 18: Ganda hanya di menu lama → tipe sisa; muncul di baru dan lama → tipe hidup berdampingan.

8.3. Explorer berat atau crash

Jika klik kanan lambat atau crash di folder tertentu, pertama-tama inventarisasi ekstensi shell yang terpasang. Dengan alat seperti ShellExView dari NirSoft, daftarkan ekstensi non-Microsoft, nonaktifkan sementara yang mencurigakan, dan temukan DLL penyebab dengan pencarian biner. Jika crash, “modul yang mengalami gangguan” di Event Viewer juga menjadi petunjuk. Jika ekstensi internal yang menjadi penyebab, curigai I/O sinkron dan akses jaringan di jalur penyusunan menu (pasal 4.2 dan 5.2).

flowchart TB
    accTitle: Menemukan DLL penyebab saat berat atau crash
    accDescr: Daftarkan ekstensi shell non-Microsoft di ShellExView, nonaktifkan sementara yang mencurigakan sambil pencarian biner untuk menemukan DLL penyebab; jika crash, modul gangguan di Event Viewer juga menjadi petunjuk
    s1["Inventarisasi ekstensi shell"] --> s2["Daftarkan yang non-Microsoft"]
    s2 --> s3["Nonaktifkan sementara dan pencarian biner"]
    s3 --> s4["Temukan DLL penyebab"]
    crash["Jika crash"] -.-> ev["Periksa modul gangguan"]
    ev -.-> s4

Gambar 19: Nonaktifkan sementara ekstensi non-Microsoft sambil pencarian biner; saat crash, Event Viewer juga dipakai bersama.

8.4. Verifikasi nyaman dengan Windows Sandbox

Verifikasi integrasi shell dasarnya adalah konfirmasi “instal di lingkungan bersih → operasi → uninstall → sisa nol”. Yang nyaman di sini adalah Windows Sandbox (Pro/Enterprise/Education): setiap kali dimulai, Windows sekali pakai yang bersih berdiri dalam beberapa detik, sehingga pengujian pendaftaran dan pembersihan penginstal dapat diulang berkali-kali. Setelah ditutup semuanya hilang, jadi cocok juga untuk menyelidiki sisa registri.¹⁵

9. Ringkasan

• Asosiasi file adalah struktur tiga lapis “kunci ekstensi → ProgID → verb”, dan HKCR adalah tampilan gabungan Classes HKLM/HKCU. Tujuan tulis disebutkan secara eksplisit, dan %1 selalu diapit tanda kutip.
• Aplikasi default dirancang untuk dipilih pengguna, dan tidak dapat diubah dari program. Pekerjaan penginstal hanya mendaftar dengan benar sebagai kandidat.
• Ekstensi shell klasik adalah DLL COM in-process yang dimuat ke Explorer. Crash dan penundaan merambat ke keseluruhan, 64-bit wajib, kode terkelola tidak didukung, dan implementasi pada prinsipnya C++ native.
• Di Windows 11 menu klik kanan menjadi dua lapis. Untuk menampilkan perintah kustom di menu baru diperlukan IExplorerCommand + manifes MSIX; IContextMenu klasik dipindahkan ke sisi “Tampilkan opsi selengkapnya”.
• Aplikasi yang tidak dapat dikemas MSIX, solusi realistisnya memperoleh identitas dengan sparse package (MSIX dengan lokasi eksternal).
• Jika hanya “buka dengan aplikasi ini”, asosiasi dan verb statis masih cukup. Memulai dari sarana paling sederhana juga merupakan 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 saat penggantian PC ke Windows 11 terasa “menu tersembunyi”, pertama-tama pastikan di tabel keputusan bab 6 termasuk (a), (b), atau (c). Skala penanganannya seharusnya dapat diperkirakan di tempat.

Artikel terkait

• Apa itu COM / ActiveX / OCX - merangkum perbedaan dan hubungannya
• Apa itu Reg-Free COM - memakai COM tanpa pendaftaran
• Jebakan pengalihan dan virtualisasi registri 32-bit/64-bit ── Wow6432Node dan masalah “nilai yang seharusnya sudah ditulis tidak ada”
• Cara memilih metode distribusi aplikasi Windows - MSI/MSIX/ClickOnce/xcopy/pembaruan sendiri
• Kompatibilitas mundur DLL dan antarmuka COM ── tabel keputusan perubahan mana yang merusak pemanggil
• Mekanisme kompatibilitas aplikasi Windows ── memperpanjang umur aplikasi lama dengan mode kompatibilitas, shim, dan Compatibility Administrator

Area konsultasi terkait

Di Komura Soft LLC kami menangani desain dan implementasi asosiasi file, menu klik kanan, dan ekstensi shell untuk aplikasi bisnis; penanganan menu konteks baru Windows 11 (IExplorerCommand, pengenalan sparse package); peninjauan pendaftaran dan pembersihan penginstal yang sudah ada; serta investigasi penyebab Explorer yang berat atau crash. Mulai dari penentuan arah “bagaimana menu yang tersembunyi di Tampilkan opsi selengkapnya” pun tidak masalah.

• Pengembangan aplikasi Windows
• Pemanfaatan aset yang ada dan dukungan migrasi
• 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 di Windows 11 menu klik kanan aplikasi kami hanya muncul di dalam "Tampilkan opsi selengkapnya"?

Karena di Windows 11 menu klik kanan Explorer terbagi dua lapisan, baru dan lama. Item yang dapat muncul di menu baru hanyalah perintah yang mengimplementasikan antarmuka IExplorerCommand dan didaftarkan di manifes paket MSIX (= memiliki identitas paket). Ekstensi shell klasik berbasis IContextMenu dipindahkan ke menu lama yang dibuka lewat "Tampilkan opsi selengkapnya" (Shift+F10). Ekstensinya sendiri tidak rusak, jadi untuk saat ini tetap berjalan. Jika ingin muncul di menu baru, perlu migrasi ke IExplorerCommand serta pengemasan sebagai MSIX atau pemberian identitas lewat 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 per pengguna diobfuskasi, dan driver filter (UCPD.sys) juga memblokir penulisan 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 pengaturan aplikasi default. Implementasi yang benar bukan merebut default, melainkan menyiapkan diri agar dipilih.

Bolehkah ekstensi shell ditulis 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 proses Explorer maupun ke aplikasi mana pun yang membuka dialog file umum, sehingga konflik versi CLR, reentrancy, dan masa hidup objek yang tidak deterministik membuat aplikasi host tidak stabil. Prinsipnya 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, tidak bermasalah jika memakai 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 sudah ada (MSI, Inno Setup, dan sejenisnya), daftarkan paket itu dengan Add-AppxPackage -ExternalLocation yang menunjuk ke folder instalasi. Aplikasi lalu memperoleh identitas paket dan dapat memakai fitur yang mensyaratkan identitas, seperti pendaftaran di menu konteks baru Windows 11 dan notifikasi toast. Tersedia sejak Windows 10 versi 2004, dan paket memerlukan tanda tangan kode yang dipercaya di mesin target. Ini pilihan realistis jika ingin mendukung menu baru tanpa memindahkan seluruh cara distribusi ke MSIX.

Apa yang harus dilakukan jika item menu klik kanan muncul dua kali, atau tidak hilang?

Pertama isolasi penyebabnya dengan memeriksa di menu mana item itu muncul: menu baru atau menu lama (Tampilkan opsi selengkapnya). Tampilan ganda yang tipikal terjadi ketika pendaftaran registri cara lama dan pendaftaran manifes MSIX hidup berdampingan, atau ketika pendaftaran ProgID maupun CLSID ekstensi tidak dibersihkan saat uninstall. Setelah mengubah asosiasi, curigai juga SHChangeNotify(SHCNE_ASSOCCHANGED) yang terlewat; tepat setelah pendaftaran paket, curigai Explorer yang belum dimulai ulang. Jika masih belum selesai, nonaktifkan sementara ekstensi non-Microsoft di ShellExView dan temukan 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.