Bukan hal sepele untuk membuat file konfigurasi .NET untuk .DLL, dan untuk alasan yang baik. Mekanisme konfigurasi .NET memiliki banyak fitur di dalamnya untuk memudahkan peningkatan / pembaruan aplikasi, dan untuk melindungi aplikasi yang terinstal dari menginjak-injak file konfigurasi satu sama lain.
Ada perbedaan besar antara bagaimana DLL digunakan dan bagaimana aplikasi digunakan. Anda tidak mungkin memiliki banyak salinan aplikasi yang diinstal pada mesin yang sama untuk pengguna yang sama. Tetapi Anda mungkin memiliki 100 aplikasi atau pustaka yang berbeda yang semuanya memanfaatkan beberapa .NET DLL.
Meskipun jarang ada kebutuhan untuk melacak pengaturan secara terpisah untuk salinan aplikasi yang berbeda dalam satu profil pengguna, sangat tidak mungkin bahwa Anda ingin semua penggunaan yang berbeda dari DLL untuk berbagi konfigurasi satu sama lain. Karena alasan ini, ketika Anda mengambil objek Konfigurasi menggunakan metode "normal", objek yang Anda dapatkan terkait dengan konfigurasi App Domain yang Anda jalankan, bukan pada rakitan tertentu.
App Domain terikat ke rakitan root yang memuat rakitan di mana kode Anda sebenarnya. Dalam kebanyakan kasus ini adalah rakitan utama .EXE Anda, yang merupakan apa yang memuat .DLL. Dimungkinkan untuk memutar domain aplikasi lain dalam suatu aplikasi, tetapi Anda harus secara eksplisit memberikan informasi tentang apa rakitan root dari domain aplikasi itu.
Karena semua ini, prosedur untuk membuat file konfigurasi perpustakaan khusus tidak begitu nyaman. Ini adalah proses yang sama yang akan Anda gunakan untuk membuat file konfigurasi portabel sewenang-wenang yang tidak terikat pada perakitan tertentu, tetapi Anda ingin memanfaatkan skema XML .NET, bagian konfigurasi dan mekanisme elemen konfigurasi, dll. Ini mencakup pembuatan ExeConfigurationFileMap
objek. , memuat data untuk mengidentifikasi di mana file config akan disimpan, dan kemudian memanggil ConfigurationManager
. OpenMappedExeConfiguration
untuk membukanya menjadi Configuration
contoh baru . Ini akan memotong Anda dari perlindungan versi yang ditawarkan oleh mekanisme pembuatan jalur otomatis.
Secara statistik, Anda mungkin menggunakan pustaka ini dalam pengaturan internal, dan sepertinya Anda tidak akan memiliki banyak aplikasi yang memanfaatkannya dalam satu mesin / pengguna. Tetapi jika tidak, ada sesuatu yang harus Anda ingat. Jika Anda menggunakan satu file konfigurasi global untuk DLL Anda, terlepas dari aplikasi yang mereferensikannya, Anda perlu khawatir tentang konflik akses. Jika dua aplikasi yang mereferensikan pustaka Anda berjalan pada saat yang sama, masing-masing dengan Configuration
objeknya sendiri terbuka, maka ketika satu menyimpan perubahan, itu akan menyebabkan pengecualian saat Anda mencoba mengambil atau menyimpan data di aplikasi lain.
Cara paling aman dan paling sederhana untuk menyiasatinya adalah dengan mengharuskan majelis yang memuat DLL Anda juga memberikan beberapa informasi tentang dirinya sendiri, atau untuk mendeteksinya dengan memeriksa App Domain dari rujukan referensi. Gunakan ini untuk membuat semacam struktur folder untuk menjaga file konfigurasi pengguna terpisah untuk setiap aplikasi yang mereferensikan DLL Anda.
Jika Anda yakin ingin memiliki pengaturan global untuk DLL Anda di mana pun itu direferensikan, Anda harus menentukan lokasi Anda untuk itu daripada. NET mencari yang tepat secara otomatis. Anda juga harus agresif dalam mengelola akses ke file. Anda harus melakukan cache sebanyak mungkin, menjaga Configuration
instance hanya HANYA selama yang diperlukan untuk memuat atau menyimpan, membuka segera sebelum dan membuang segera setelah. Dan akhirnya, Anda akan memerlukan mekanisme kunci untuk melindungi file saat sedang diedit oleh salah satu aplikasi yang menggunakan perpustakaan.