Bagikan melalui

Gambaran Umum Add-Ins WPF

  • Artikel

.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-In

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:

  • Add-on Internet Explorer.

  • Pemutar Media Windows plug-in.

  • Add-in Visual Studio.

Misalnya, model add-in Pemutar Media Windows memungkinkan pengembang pihak ketiga menerapkan "plug-in" yang memperluas Pemutar Media Windows dengan berbagai cara, termasuk membuat dekode dan encoder untuk format media yang tidak didukung secara asli oleh Pemutar Media Windows (misalnya, DVD, MP3), efek audio, dan skin. 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 dari 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 mengekspos fungsionalitas untuk add-in untuk diintegrasikan.

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:

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

  • Aktivasi: Memuat, menjalankan, dan membangun komunikasi dengan add-in.

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

  • Komunikasi: Memungkinkan add-in dan aplikasi host berkomunikasi satu sama lain di seluruh batas isolasi dengan memanggil metode dan meneruskan data.

  • Manajemen Seumur Hidup: 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 add-in yang kuat adalah usaha yang tidak sepele. Untuk alasan ini, .NET Framework menyediakan infrastruktur untuk membangun model add-in.

Catatan

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 System.AddIn namespace, berisi sekumpulan jenis yang dirancang untuk menyederhanakan pengembangan ekstensibilitas add-in. Unit mendasar dari 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 kontrak khusus aplikasi host. Demikian juga, tampilan khusus add-in dari kontrak 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-In 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 mengembalikan UI. Add-in mengembalikan UI ke aplikasi host melalui panggilan metode, 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. Add-in adalah UI. Add-in adalah UI, 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 jarak jauh untuk berkomunikasi antara domain aplikasi, objek yang diteruskan di antara mereka harus dapat diremobilitas.

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

Catatan

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

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: INativeHandleContract antarmuka dan dua metode statis yang diimplementasikan oleh FrameworkElementAdapters kelas: 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. Di mana pun kontrak menyatakan bahwa UI akan diteruskan antara add-in dan aplikasi host, itu harus dinyatakan sebagai INativeHandleContract (bukan FrameworkElement); INativeHandleContract adalah representasi yang dapat diremobilitas dari UI add-in yang dapat diteruskan di seluruh batas isolasi.

  3. Sebelum diteruskan dari domain aplikasi add-in, dimas FrameworkElement 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 UI ke aplikasi host, berikut ini diperlukan:

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

  2. Kontrak harus menerapkan IContract dan, untuk mengembalikan UI, kontrak harus mendeklarasikan metode dengan nilai pengembalian jenis 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 ke FrameworkElement sebelum INativeHandleContract melewati batas isolasi.

  5. UI yang dikembalikan harus dikonversi dari menjadi INativeHandleContractFrameworkElement setelah melewati batas isolasi.

  6. Aplikasi host menampilkan yang dikembalikan FrameworkElement.

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

Add-In Adalah Antarmuka Pengguna

Saat add-in adalah UI, berikut ini diperlukan:

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

  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 ke FrameworkElement sebelum INativeHandleContract melewati batas isolasi.

  5. Add-in harus dikonversi dari menjadi INativeHandleContractFrameworkElement setelah melewati batas isolasi.

  6. Aplikasi host menampilkan yang dikembalikan FrameworkElement.

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

Mengembalikan Beberapa UI dari Add-In

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

Add-In dan Aplikasi Browser XAML

Dalam contoh sejauh ini, aplikasi host telah diinstal 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 alur (folder dan rakitan) dan rakitan add-in ke cache aplikasi ClickOnce pada komputer klien, di 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 ke 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 alur dan add-in harus berada di folder akar proyek XBAP host agar Visual Studio mendeteksi rakitan alur.

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 alur Jalur output build
Kontrak ..\HostXBAP\Contracts\
Tampilan Add-in ..\HostXBAP\AddInViews\
Adaptor Add-In-Side ..\HostXBAP\AddInSideAdapters\
Adaptor Sisi Host ..\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 Proyek.

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

Langkah terakhir adalah mengonfigurasi manifes aplikasi untuk menyertakan file perakitan alur dan file rakitan add-in untuk diunduh. File harus terletak di folder di akar folder di cache ClickOnce yang ditempati 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 Publikasi setiap alur dan DLL add-in ke Sertakan (Otomatis), dan atur Grup Unduhan untuk setiap alur dan DLL add-in ke (Diperlukan).

Menggunakan Alur 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 anggota model add-in .NET Framework untuk menggunakan alur dan add-in memberikan dukungan khusus untuk skenario ini. Pertama, jalur diidentifikasi oleh ApplicationBase nilai enumerasi. 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 AddInSecurityLevel.Host nilai enumerasi, dan diteruskan ke Activate metode ketika 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 bahwa aplikasi host dikembalikan yang FrameworkElement 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:

  • Di sisi add-in, WPF memperoleh handel jendela untuk UI yang akan ditampilkan oleh aplikasi host. Handel jendela dienkapsulasi oleh kelas WPF internal yang berasal dari HwndSource dan mengimplementasikan INativeHandleContract. Instans kelas ini dikembalikan oleh ViewToContractAdapter dan dinamai dari domain aplikasi add-in ke domain aplikasi aplikasi host.

  • Di sisi aplikasi host, WPF mengemas HwndSource ulang 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, diidentifikasi oleh handel jendela, dari antarmuka pengguna WPF. Untuk informasi selengkapnya, lihat Interoperatur WPF dan Win32.

Singkatnya, INativeHandleContract, , 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 ViewToContractAdapteraplikasi host.

Catatan

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 diperluas HwndHost dengan beberapa kemampuan untuk skenario add-in. Manfaat dan batasan ini dijelaskan di bawah ini.

Manfaat Add-in WPF

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 internalnya HwndHost dengan kemampuan tambahan yang mencakup hal-hal berikut:

  • Tab antara UI aplikasi host dan UI add-in. Perhatikan bahwa model pemrograman "add-in adalah UI" mengharuskan adaptor add-in-side untuk mengambil alih QueryContract untuk mengaktifkan tab, apakah add-in sepenuhnya tepercaya atau dipercaya 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 handel jendela UI add-in saat add-in berjalan dengan isolasi keamanan (yaitu, sandbox keamanan kepercayaan parsial). ViewToContractAdapter Panggilan 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 is a UI", mengambil alih QueryContract adaptor dan panggilan ViewToContractAdapter sisi add-in (seperti yang ditunjukkan dalam contoh sebelumnya) diperlukan, seperti yang memanggil implementasi adaptor QueryContract add-in-side dari adaptor sisi host.

  • Memberikan beberapa perlindungan eksekusi 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 untuk utas Dispatcher tempat domain aplikasi berjalan, jika aplikasi host adalah aplikasi WPF. Anda dapat mendeteksi semua pengecualian yang tidak tertangani yang terjadi di domain aplikasi dengan menangani UnhandledException peristiwa add-in DispatcherWPF. Anda bisa mendapatkan Dispatcher dari CurrentDispatcher properti .

Batasan Add-In WPF

Di luar manfaat yang ditambahkan WPF ke perilaku default yang disediakan oleh HwndSource, , HwndHostdan handel 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 Gambaran Umum 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 ini ke 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 dengan menggambar operasi dari System.Drawing namespace dapat menyertakan pencamburan alfa. Namun, UI add-in dan UI aplikasi host yang berisinya harus 100% buram; dengan kata lain, Opacity properti pada keduanya harus diatur ke 1.

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

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

  • Tidak ada bagian UI add-in yang dapat dirender 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 dalam UI add-in.

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

  • Ketika fokus bergeser antar kontrol di UI add-in, GotFocus peristiwa dan LostFocus tidak diterima atau dinaikkan 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 dibongkar jika aplikasi host melanjutkan eksekusi. Kontrak dapat menerapkan metode yang memungkinkan aplikasi host untuk memberi sinyal add-in sebelum add-in dibongkar, sehingga memungkinkan UI add-in untuk mematikan dispatcher-nya.

  • Jika UI add-in adalah InkCanvas atau berisi InkCanvas, Anda tidak dapat membongkar 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 LoaderOptimizationAttribute atribut , 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).

Baca juga