Bagikan melalui

WPF Add-Ins Gambaran Umum

.NET Framework menyertakan model add-in yang dapat digunakan pengembang untuk membuat aplikasi yang mendukung ekstensibilitas add-in. Model add-in ini memungkinkan pembuatan add-in yang terintegrasi dengan dan memperluas fungsionalitas aplikasi. Dalam beberapa skenario, aplikasi juga perlu menampilkan antarmuka pengguna yang disediakan oleh add-in. Topik ini menunjukkan bagaimana WPF menambah model add-in .NET Framework untuk mengaktifkan skenario ini, arsitektur di baliknya, manfaatnya, dan batasannya.

Prasyarat

Diperlukan pemahaman tentang model add-in .NET Framework. Untuk informasi selengkapnya, lihat Add-in dan Ekstensibilitas.

Gambaran Umum Add-Ins

Untuk menghindari kompleksitas kompilasi ulang aplikasi dan penyebaran ulang untuk menggabungkan fungsionalitas baru, aplikasi menerapkan mekanisme ekstensibilitas yang memungkinkan pengembang (pihak pertama dan pihak ketiga) untuk membuat aplikasi lain yang terintegrasi dengan mereka. Cara paling umum untuk mendukung jenis ekstensibilitas ini adalah melalui penggunaan add-in (juga dikenal sebagai "add-on" dan "plug-in"). Contoh aplikasi dunia nyata yang mengekspos ekstensibilitas dengan add-in meliputi:

  • Pengaya Internet Explorer.

  • Plugin Windows Media Player.

  • Pengaya Visual Studio.

Misalnya, model add-in Windows Media Player memungkinkan pengembang pihak ketiga untuk menerapkan "plug-in" yang memperluas Windows Media Player dengan berbagai cara, termasuk membuat decoder dan encoder untuk format media yang tidak didukung secara asli oleh Windows Media Player (misalnya, DVD, MP3), efek audio, dan kulit. Setiap model add-in dibangun untuk mengekspos fungsionalitas yang unik untuk aplikasi, meskipun ada beberapa entitas dan perilaku yang umum untuk semua model add-in.

Tiga entitas utama solusi ekstensibilitas add-in yang khas adalah kontrak , add-in , dan aplikasi host . Kontrak menentukan bagaimana add-in terintegrasi dengan aplikasi host dengan dua cara:

  • Add-in terintegrasi dengan fungsionalitas yang diimplementasikan oleh aplikasi host.

  • Aplikasi host mengungkapkan fungsionalitas untuk memungkinkan addin berintegrasi.

Agar add-in dapat digunakan, aplikasi host perlu menemukannya dan memuatnya pada waktu proses. Akibatnya, aplikasi yang mendukung add-in memiliki tanggung jawab tambahan berikut:

  • Discovery: Menemukan add-in yang mematuhi kontrak yang didukung oleh aplikasi host.

  • Aktivasi: Memuat, menjalankan, dan menjalin komunikasi dengan plug-in.

  • Isolasi: Menggunakan domain atau proses aplikasi untuk menetapkan batas isolasi yang melindungi aplikasi dari potensi masalah keamanan dan eksekusi dengan add-in.

  • Communication: Memungkinkan penambahan dan aplikasi host untuk berkomunikasi satu sama lain melintasi batas-batas isolasi dengan memanggil metode dan meneruskan data.

  • Lifetime Management: Memuat dan membongkar domain dan proses aplikasi dengan cara yang bersih dan dapat diprediksi (lihat Domain Aplikasi).

  • Penerapan Versi: Memastikan bahwa aplikasi host dan add-in masih dapat berkomunikasi ketika versi baru keduanya dibuat.

Pada akhirnya, mengembangkan model tambahan yang kuat adalah usaha yang tidak sepele. Untuk alasan ini, .NET Framework menyediakan infrastruktur untuk membangun model add-in.

Nota

Untuk informasi selengkapnya tentang add-in, lihat Add-in dan Ekstensibilitas.

Gambaran Umum Model Add-In .NET Framework

Model add-in .NET Framework, yang ditemukan di namespace System.AddIn, berisi sekumpulan jenis yang dirancang untuk menyederhanakan pengembangan ekstensibilitas add-in. Unit dasar model add-in .NET Framework adalah kontrak , yang menentukan bagaimana aplikasi host dan add-in berkomunikasi satu sama lain. Kontrak diekspos ke aplikasi host menggunakan tampilan khusus aplikasi host kontrak. Demikian juga, tampilan kontrak yang spesifik untuk add-in diekspos ke add-in. Adaptor digunakan untuk memungkinkan aplikasi host dan add-in untuk berkomunikasi antara tampilan kontrak masing-masing. Kontrak, tampilan, dan adaptor disebut sebagai segmen, dan sekumpulan segmen terkait merupakan alur . Alur adalah fondasi di mana model add-in .NET Framework mendukung penemuan, aktivasi, isolasi keamanan, isolasi eksekusi (menggunakan domain dan proses aplikasi), komunikasi, manajemen seumur hidup, dan penerapan versi.

Jumlah dukungan ini memungkinkan pengembang untuk membangun add-in yang terintegrasi dengan fungsionalitas aplikasi host. Namun, beberapa skenario mengharuskan aplikasi host untuk menampilkan antarmuka pengguna yang disediakan oleh add-in. Karena setiap teknologi presentasi dalam .NET Framework memiliki model sendiri untuk menerapkan antarmuka pengguna, model add-in .NET Framework tidak mendukung teknologi presentasi tertentu. Sebagai gantinya, WPF memperluas model add-in .NET Framework dengan dukungan UI untuk add-in.

Add-Ins WPF

WPF, bersama dengan model add-in .NET Framework, memungkinkan Anda untuk mengatasi berbagai skenario yang memerlukan aplikasi host untuk menampilkan antarmuka pengguna dari add-in. Secara khusus, skenario ini ditangani oleh WPF dengan dua model pemrograman berikut:

  1. Add-in menyediakan UI. Add-in mengembalikan UI ke aplikasi host melalui sebuah metode pemanggilan, seperti yang didefinisikan oleh kontrak. Skenario ini digunakan dalam kasus berikut:

    • Tampilan UI yang dikembalikan oleh add-in bergantung pada data atau kondisi yang hanya ada pada waktu proses, seperti laporan yang dihasilkan secara dinamis.

    • UI untuk layanan yang disediakan oleh add-in berbeda dari UI aplikasi host yang dapat menggunakan add-in.

    • Add-in terutama melakukan layanan untuk aplikasi host, dan melaporkan status ke aplikasi host dengan UI.

  2. Pengaya adalah UI. Add-in adalah antarmuka pengguna, seperti yang didefinisikan oleh kontrak. Skenario ini digunakan dalam kasus berikut:

    • Add-in tidak menyediakan layanan selain ditampilkan, seperti iklan.

    • UI untuk layanan yang disediakan oleh add-in umum untuk semua aplikasi host yang dapat menggunakan add-in tersebut, seperti kalkulator atau pemilih warna.

Skenario ini mengharuskan objek UI dapat diteruskan antara aplikasi host dan domain aplikasi add-in. Karena model add-in .NET Framework bergantung pada remoting untuk berkomunikasi antara domain aplikasi, objek yang diteruskan di antara mereka harus dapat di-remote.

Objek yang dapat diremobilitas adalah instans kelas yang melakukan satu atau beberapa hal berikut:

Nota

Untuk informasi selengkapnya mengenai pembuatan objek .NET Framework yang dapat diremote, lihat Membuat Objek Dapat Diremote.

Jenis UI WPF tidak dapat diremobilitas. Untuk mengatasi masalah tersebut, WPF memperluas model add-in .NET Framework untuk mengaktifkan WPF UI yang dibuat oleh add-in untuk ditampilkan dari aplikasi host. Dukungan ini disediakan oleh WPF oleh dua jenis: antarmuka INativeHandleContract dan dua metode statis yang diterapkan oleh kelas FrameworkElementAdapters: ContractToViewAdapter dan ViewToContractAdapter. Pada tingkat tinggi, jenis dan metode ini digunakan dengan cara berikut:

  1. WPF mengharuskan antarmuka pengguna yang disediakan oleh add-in adalah kelas yang berasal secara langsung atau tidak langsung dari FrameworkElement, seperti bentuk, kontrol, kontrol pengguna, panel tata letak, dan halaman.

  2. Setiap kali kontrak menyatakan bahwa UI akan diteruskan antara add-in dan aplikasi host, itu harus dinyatakan sebagai INativeHandleContract (bukan FrameworkElement); INativeHandleContract adalah representasi dari UI add-in yang dapat diakses jarak jauh dan dapat diteruskan melewati batas isolasi.

  3. Sebelum diteruskan dari domain aplikasi add-in, FrameworkElement dikemas sebagai INativeHandleContract dengan memanggil ViewToContractAdapter.

  4. Setelah diteruskan ke domain aplikasi aplikasi host, INativeHandleContract harus dikemas ulang sebagai FrameworkElement dengan memanggil ContractToViewAdapter.

Bagaimana INativeHandleContract, ContractToViewAdapter, dan ViewToContractAdapter digunakan tergantung pada skenario tertentu. Bagian berikut memberikan detail untuk setiap model pemrograman.

Add-In Mengembalikan Antarmuka Pengguna

Agar add-in mengembalikan antarmuka pengguna ke aplikasi induk, hal-hal berikut diperlukan:

  1. Aplikasi host, add-in, dan alur harus dibuat, seperti yang dijelaskan oleh dokumentasi Add-in .NET Framework dan Ekstensibilitas.

  2. Kontrak harus menerapkan IContract dan, untuk mengembalikan UI, harus mendeklarasikan metode dengan nilai pengembalian bertipe INativeHandleContract.

  3. UI yang diteruskan antara add-in dan aplikasi host harus secara langsung atau tidak langsung berasal dari FrameworkElement.

  4. UI yang dikembalikan oleh add-in harus dikonversi dari FrameworkElement ke INativeHandleContract sebelum melewati batas isolasi.

  5. UI yang dikembalikan harus dikonversi dari INativeHandleContract ke FrameworkElement setelah melewati batas isolasi.

  6. Aplikasi host menampilkan FrameworkElementyang dikembalikan.

Untuk contoh yang menunjukkan cara menerapkan add-in yang mengembalikan UI, lihat Membuat Add-In yang Mengembalikan UI.

Add-In Adalah Antarmuka Pengguna

Ketika add-in berupa antarmuka pengguna, hal-hal berikut ini diperlukan:

  1. Aplikasi host, add-in, dan alur harus dibuat, seperti yang dijelaskan oleh dokumentasi Add-in .NET Framework dan Ekstensibilitas.

  2. Antarmuka kontrak untuk add-in harus menerapkan INativeHandleContract.

  3. Add-in yang diteruskan ke aplikasi host harus secara langsung atau tidak langsung berasal dari FrameworkElement.

  4. Add-in harus dikonversi dari FrameworkElement ke INativeHandleContract sebelum melewati batas isolasi.

  5. Suatu add-in harus dikonversi dari INativeHandleContract ke FrameworkElement setelah melewati batas isolasi.

  6. Aplikasi host menampilkan FrameworkElementyang dikembalikan.

Untuk contoh yang menunjukkan cara menerapkan add-in yang merupakan UI, lihat Membuat Add-In Itu adalah UI.

Mengembalikan Beberapa Antarmuka Pengguna dari Add-In

Add-in sering menyediakan beberapa antarmuka pengguna untuk ditampilkan aplikasi host. Misalnya, pertimbangkan add-in yang berfungsi sebagai UI dan juga menyediakan informasi status kepada aplikasi host dalam bentuk UI. Add-in seperti ini dapat diimplementasikan dengan menggunakan kombinasi teknik dari Add-In Mengembalikan Antarmuka Pengguna dan Add-In Adalah model Antarmuka Pengguna.

Aplikasi Browser Add-Ins dan XAML

Dalam contoh sejauh ini, aplikasi host yang telah diinstal adalah aplikasi mandiri. Tetapi aplikasi browser XAML (XBAP) juga dapat menghosting add-in, meskipun dengan persyaratan build dan implementasi tambahan berikut:

  • Manifes aplikasi XBAP harus dikonfigurasi khusus untuk mengunduh pipeline (folder dan rakitan) serta rakitan add-in ke cache aplikasi ClickOnce pada komputer klien, di dalam folder yang sama dengan XBAP.

  • Kode XBAP untuk menemukan dan memuat add-in harus menggunakan cache aplikasi ClickOnce untuk XBAP sebagai lokasi alur dan add-in.

  • XBAP harus memuat add-in ke dalam konteks keamanan khusus jika add-in mereferensikan file longgar yang terletak di situs asal; ketika dihosting oleh XBAP, add-in hanya dapat mereferensikan file longgar yang terletak di situs asal aplikasi host.

Tugas-tugas ini dijelaskan secara rinci dalam sub bagian berikut.

Mengonfigurasi Alur dan Add-In untuk Penyebaran ClickOnce

XBAP diunduh dan dijalankan dari folder aman di cache penyebaran ClickOnce. Agar XBAP menghosting add-in, alur dan rakitan add-in juga harus diunduh ke folder aman. Untuk mencapai hal ini, Anda perlu mengonfigurasi manifes aplikasi untuk menyertakan rakitan alur dan add-in untuk diunduh. Ini paling mudah dilakukan di Visual Studio, meskipun rakitan pipeline dan add-in harus berada di folder utama proyek XBAP host agar Visual Studio dapat mendeteksi rakitan pipeline.

Akibatnya, langkah pertama adalah membangun rakitan alur dan add-in ke akar proyek XBAP dengan mengatur output build dari setiap rakitan alur dan proyek perakitan add-in. Tabel berikut menunjukkan jalur output build untuk proyek perakitan alur dan proyek perakitan add-in yang berada dalam solusi dan folder akar yang sama dengan proyek XBAP host.

Tabel 1: Membangun Jalur Output untuk Rakitan Alur yang Dihosting oleh XBAP

Proyek perakitan pipa Jalur keluaran build
Kontrak ..\HostXBAP\Contracts\
Tampilan Add-In ..\HostXBAP\AddInViews\
Tambahkan AdaptorIn-Side ..\HostXBAP\AddInSideAdapters\
Host-Side Adaptor ..\HostXBAP\HostSideAdapters\
Add-In ..\HostXBAP\AddIns\WPFAddIn1

Langkah selanjutnya adalah menentukan rakitan alur dan rakitan add-in sebagai file konten XBAP di Visual Studio dengan melakukan hal berikut:

  1. Termasuk rakitan alur dan add-in dalam proyek dengan mengklik kanan setiap folder alur di Penjelajah Solusi dan memilih Sertakan Dalam Project.

  2. Mengatur Tindakan Build dari setiap rakitan pipeline dan rakitan add-in ke Konten dari jendela Properti.

Langkah terakhir adalah mengonfigurasi manifes aplikasi untuk menyertakan file perakitan pipeline dan file perakitan add-in agar dapat diunduh. File harus terletak di folder utama dalam cache ClickOnce yang ditempati oleh aplikasi XBAP. Konfigurasi dapat dicapai di Visual Studio dengan melakukan hal berikut:

  1. Klik kanan proyek XBAP, klik Properti, klik Terbitkan, lalu klik tombol File Aplikasi.

  2. Dalam dialog File Aplikasi, atur Status Terbitkan dari setiap pipeline dan DLL add-in ke Sertakan (Otomatis), dan atur Grup Unduhan untuk setiap pipeline dan DLL add-in ke (Wajib).

Menggunakan Pipeline dan Add-In dari Basis Aplikasi

Ketika alur dan add-in dikonfigurasi untuk penyebaran ClickOnce, mereka diunduh ke folder cache ClickOnce yang sama dengan XBAP. Untuk menggunakan alur dan add-in dari XBAP, kode XBAP harus mendapatkannya dari basis aplikasi. Berbagai jenis dan komponen model add-in .NET Framework untuk penggunaan pipeline dan add-in memberikan dukungan khusus untuk skenario ini. Pertama, jalur diidentifikasi oleh nilai enumerasi ApplicationBase. Anda menggunakan nilai ini dengan kelebihan beban anggota add-in yang bersangkutan untuk menggunakan alur yang menyertakan yang berikut ini:

Mengakses Situs Asal Host

Untuk memastikan bahwa add-in dapat mereferensikan file dari situs asal, add-in harus dimuat dengan isolasi keamanan yang setara dengan aplikasi host. Tingkat keamanan ini diidentifikasi oleh nilai enumerasi AddInSecurityLevel.Host, dan diteruskan ke metode Activate saat add-in diaktifkan.

Arsitektur Add-In WPF

Pada tingkat tertinggi, seperti yang telah kita lihat, WPF memungkinkan add-in .NET Framework untuk mengimplementasikan antarmuka pengguna (yang berasal secara langsung atau tidak langsung dari FrameworkElement) menggunakan INativeHandleContract, ViewToContractAdapter dan ContractToViewAdapter. Hasilnya adalah aplikasi host menerima FrameworkElement yang ditampilkan dari UI di aplikasi host.

Untuk skenario add-in UI sederhana, ini sama detailnya dengan yang dibutuhkan pengembang. Untuk skenario yang lebih kompleks, terutama yang mencoba menggunakan layanan WPF tambahan seperti tata letak, sumber daya, dan pengikatan data, pengetahuan yang lebih rinci tentang bagaimana WPF memperluas model add-in .NET Framework dengan dukungan UI diperlukan untuk memahami manfaat dan batasannya.

Pada dasarnya, WPF tidak meneruskan UI dari add-in ke aplikasi host; sebaliknya, WPF meneruskan handel jendela Win32 untuk UI dengan menggunakan interoperabilitas WPF. Dengan demikian, ketika UI dari add-in diteruskan ke aplikasi host, hal berikut terjadi:

  • Pada sisi add-in, WPF memperoleh handle jendela untuk UI yang akan ditampilkan oleh aplikasi host. Pegangan jendela dienkapsulasi oleh kelas WPF internal yang berasal dari HwndSource dan mengimplementasikan INativeHandleContract. Instance kelas ini dikembalikan oleh ViewToContractAdapter dan dipindahkan dari domain aplikasi add-in ke domain aplikasi host.

  • Di sisi aplikasi host, WPF mengemas ulang HwndSource sebagai kelas WPF internal yang berasal dari HwndHost dan mengonsumsi INativeHandleContract. Instans kelas ini dikembalikan oleh ContractToViewAdapter ke aplikasi host.

HwndHost ada untuk menampilkan antarmuka pengguna, yang diidentifikasi oleh handel jendela, dari antarmuka pengguna WPF. Untuk informasi selengkapnya, lihat WPF dan Win32 Interoperation.

Singkatnya, INativeHandleContract, ViewToContractAdapter, dan ContractToViewAdapter ada untuk memungkinkan handel jendela untuk UI WPF diteruskan dari add-in ke aplikasi host, di mana itu dienkapsulasi oleh HwndHost dan menampilkan UI aplikasi host.

Nota

Karena aplikasi host mendapatkan HwndHost, aplikasi host tidak dapat mengonversi objek yang dikembalikan oleh ContractToViewAdapter ke jenis yang diimplementasikan seperti oleh add-in (misalnya, UserControl).

Secara alami, HwndHost memiliki batasan tertentu yang memengaruhi bagaimana aplikasi host dapat menggunakannya. Namun, WPF memperluas HwndHost dengan beberapa kemampuan untuk skenario tambahan. Manfaat dan batasan ini dijelaskan di bawah ini.

WPF Add-In Manfaat

Karena antarmuka pengguna add-in WPF ditampilkan dari aplikasi host menggunakan kelas internal yang berasal dari HwndHost, antarmuka pengguna tersebut dibatasi oleh kemampuan HwndHost sehubungan dengan layanan UI WPF seperti tata letak, penyajian, pengikatan data, gaya, templat, dan sumber daya. Namun, WPF menambah subkelas HwndHost internalnya dengan kemampuan tambahan yang mencakup hal-hal berikut:

  • Beralih antara UI aplikasi host dan UI add-in. Perhatikan bahwa model pemrograman "komponen tambahan adalah UI" memerlukan adaptor sisi komponen tambahan untuk menggantikan QueryContract guna mengaktifkan fungsi tab, apakah komponen tambahan memiliki kepercayaan penuh atau memiliki kepercayaan sebagian.

  • Menghormati persyaratan aksesibilitas untuk antarmuka pengguna add-in yang ditampilkan dari antarmuka pengguna aplikasi host.

  • Memungkinkan aplikasi WPF berjalan dengan aman dalam beberapa skenario domain aplikasi.

  • Mencegah akses ilegal ke handle jendela UI add-in ketika add-in berjalan dengan isolasi keamanan (yaitu, sandbox keamanan berkepercayaan parsial). Memanggil ViewToContractAdapter memastikan keamanan ini:

    • Untuk model pemrograman "add-in mengembalikan UI", satu-satunya cara untuk meneruskan handel jendela untuk UI add-in di seluruh batas isolasi adalah dengan memanggil ViewToContractAdapter.

    • Untuk model pemrograman "add-in adalah UI", diperlukan mengambil alih QueryContract pada adaptor sisi add-in dan memanggil ViewToContractAdapter (seperti yang ditunjukkan pada contoh sebelumnya), serta memanggil implementasi QueryContract adaptor sisi add-in dari adaptor sisi host.

  • Memberikan perlindungan eksekusi untuk beberapa domain aplikasi. Karena keterbatasan dengan domain aplikasi, pengecualian yang tidak tertangani yang dilemparkan dalam domain aplikasi add-in menyebabkan seluruh aplikasi mengalami crash, meskipun batas isolasi ada. Namun, WPF dan model add-in .NET Framework menyediakan cara sederhana untuk mengatasi masalah ini dan meningkatkan stabilitas aplikasi. Add-in WPF yang menampilkan UI membuat Dispatcher untuk utas tempat domain aplikasi berjalan, jika aplikasi host itu adalah aplikasi WPF. Anda dapat mendeteksi semua pengecualian yang tidak tertangani yang terjadi di domain aplikasi dengan menangani peristiwa UnhandledException add-in WPF Dispatcher. Anda dapat memperoleh Dispatcher dari properti CurrentDispatcher.

Batasan WPF Add-In

Selain manfaat yang diberikan oleh WPF kepada perilaku default yang disediakan oleh HwndSource, HwndHost, dan handle jendela, ada juga batasan untuk antarmuka pengguna add-in yang ditampilkan dari aplikasi host.

  • Antarmuka pengguna add-in yang ditampilkan dari aplikasi host tidak menghormati perilaku kliping aplikasi host.

  • Konsep ruang udara dalam skenario interoperabilitas juga berlaku untuk add-in (lihat Ikhtisar Wilayah Teknologi).

  • Layanan UI aplikasi host, seperti pewarisan sumber daya, pengikatan data, dan perintah, tidak tersedia secara otomatis untuk antarmuka pengguna add-in. Untuk menyediakan layanan-layanan ini pada add-in, Anda perlu memperbarui alur.

  • UI add-in tidak dapat diputar, diskalakan, condong, atau dipengaruhi oleh transformasi (lihat gambaran umum transformasi ).

  • Konten di dalam antarmuka pengguna add-in yang dirender menggunakan operasi menggambar dari namespace System.Drawing dapat mencakup alpha blending. Namun, UI add-in dan UI aplikasi host yang mengandungnya harus 100% buram; dengan kata lain, properti Opacity pada keduanya harus diatur ke 1.

  • Jika properti AllowsTransparency dari jendela di aplikasi host yang mengandung antarmuka pengguna add-in diatur ke true, add-in tersebut menjadi tidak terlihat. Ini benar bahkan jika UI add-in adalah 100% buram (artinya, properti Opacity memiliki nilai 1).

  • UI add-in harus muncul di atas elemen WPF lainnya di jendela tingkat atas yang sama.

  • Tidak ada bagian antarmuka pengguna tambahan yang dapat digambarkan menggunakan VisualBrush. Sebagai gantinya, add-in dapat mengambil rekam jepret UI yang dihasilkan untuk membuat bitmap yang dapat diteruskan ke aplikasi host menggunakan metode yang ditentukan oleh kontrak.

  • File media tidak dapat diputar dari MediaElement di UI add-in.

  • Peristiwa mouse yang dihasilkan untuk UI add-in tidak diterima atau dinaikkan oleh aplikasi host, dan properti IsMouseOver untuk UI aplikasi host memiliki nilai false.

  • Saat fokus bergeser antar pengendali di UI add-in, peristiwa GotFocus dan LostFocus tidak diterima atau dimunculkan oleh aplikasi host.

  • Bagian dari aplikasi host yang berisi UI add-in tampak putih saat dicetak.

  • Semua dispatcher (lihat Dispatcher) yang dibuat oleh UI add-in harus dimatikan secara manual sebelum add-in pemilik dilepas jika aplikasi host melanjutkan eksekusi. Kontrak dapat mengimplementasikan metode yang memungkinkan aplikasi host untuk memberi sinyal kepada add-in sebelum add-in dibongkar, sehingga memungkinkan UI add-in untuk menghentikan dispatcher-nya.

  • Jika UI add-in berupa InkCanvas atau berisi InkCanvas, Anda tidak dapat memuat keluar add-in.

Pengoptimalan Performa

Secara default, ketika beberapa domain aplikasi digunakan, berbagai rakitan .NET Framework yang diperlukan oleh setiap aplikasi semuanya dimuat ke dalam domain aplikasi tersebut. Akibatnya, waktu yang diperlukan untuk membuat domain aplikasi baru dan memulai aplikasi di dalamnya dapat memengaruhi performa. Namun, .NET Framework menyediakan cara bagi Anda untuk mengurangi waktu mulai dengan menginstruksikan aplikasi untuk berbagi rakitan di seluruh domain aplikasi jika sudah dimuat. Anda melakukan ini dengan menggunakan atribut LoaderOptimizationAttribute, yang harus diterapkan ke metode titik masuk (Main). Dalam hal ini, Anda hanya boleh menggunakan kode untuk mengimplementasikan definisi aplikasi Anda (lihat Gambaran Umum Manajemen Aplikasi).

Lihat juga

  • Last updated on