Kapan - dan mengapa - Anda harus menyimpan data di Windows Registry?

Sebagai pengembang, alat yang menyimpan konfigurasi / opsi dalam registri adalah kutukan dalam hidup saya. Saya tidak dapat dengan mudah melacak perubahan pada opsi-opsi itu, tidak dapat dengan mudah memindahkannya dari mesin ke mesin, dan itu semua membuat saya benar-benar merindukan masa lalu yang baik dari file .INI ...

Saat menulis aplikasi saya sendiri, apa - jika ada - yang harus saya pilih untuk dimasukkan ke dalam registri daripada di file konfigurasi kuno, dan mengapa?

• Awalnya (WIN3) konfigurasi disimpan dalam file WIN.INI di direktori windows.
• Masalah: WIN.INI tumbuh terlalu besar.
• Solusi (Win31): file INI individu dalam direktori yang sama dengan program.
• Masalah: Program itu dapat diinstal pada jaringan dan dibagikan oleh banyak orang.
• Solusi (Win311): file INI individu dalam direktori Window pengguna.
• Masalah: Banyak orang mungkin berbagi folder windows, dan itu seharusnya hanya-baca saja.
• Solusi (Win95): Registri dengan bagian terpisah untuk setiap pengguna.
• Masalah: Registri tumbuh terlalu besar.
• Solusi (WinXP): Blok besar data individual dipindahkan ke folder Data Aplikasi milik pengguna sendiri.
• Masalah: Baik untuk sejumlah besar data, tetapi agak rumit untuk jumlah kecil.
• Solusi (.NET): sejumlah kecil data tetap, hanya-baca yang disimpan dalam file .config (Xml) dalam folder yang sama dengan aplikasi, dengan API untuk membacanya. (Baca / tulis atau data khusus pengguna tetap di registri)

Datang pada ini baik dari perspektif pengguna dan perspektif programmer saya harus mengatakan sebenarnya tidak ada alasan yang baik untuk memasukkan sesuatu ke dalam registri kecuali itu seperti asosiasi file, atau pengaturan mesin spesifik.

Saya berasal dari aliran pemikiran yang mengatakan bahwa suatu program harus dapat dijalankan dari mana pun ia diinstal, bahwa instalasi harus sepenuhnya dapat dipindahkan di dalam mesin, atau bahkan ke mesin lain dan tidak mempengaruhi jalannya.

Setiap opsi yang dapat dikonfigurasi, atau dll yang diperlukan dll, jika tidak dibagikan harus berada di subdirektori direktori instalasi, sehingga seluruh instalasi mudah dipindahkan.

Saya menggunakan banyak utilitas yang lebih kecil seperti program, jadi jika tidak dapat diinstal pada usb stick dan dicolokkan ke komputer lain dan jalankan, maka itu bukan untuk saya.

Kebijakan Microsoft:

• Sebelum windows 95, kami menggunakan file ini untuk data aplikasi.
• Di era windows 95 - XP, kami menggunakan registri.
• Dari windows Vista, kami menggunakan file ini meskipun sekarang berbasis xml.

Registri tergantung pada mesin. Saya tidak pernah menyukainya karena semakin lambat dan hampir tidak mungkin menemukan hal yang Anda butuhkan. Itu sebabnya saya suka ini sederhana atau file pengaturan lainnya. Anda tahu di mana mereka berada (folder aplikasi atau folder pengguna) sehingga mudah dibawa-bawa, dan dapat dibaca manusia.

Kapan - Anda dipaksa karena integrasi warisan atau karena sysadmin pelanggan Anda mengatakan "harus begitu" atau karena Anda berkembang dalam bahasa yang lebih lama yang membuatnya lebih sulit untuk menggunakan XML.

Mengapa - Terutama karena registri tidak portabel seperti menyalin file konfigurasi yang duduk di sebelah aplikasi (dan disebut hampir sama).

Jika Anda menggunakan .Net2 + Anda punya file App.Config dan User.Config dan Anda tidak perlu mendaftarkan DLL di registri jadi menjauhlah dari itu.

File konfigurasi memiliki masalah mereka sendiri (lihat di bawah), tetapi ini dapat dikodekan sekitar dan Anda dapat mengubah arsitektur Anda.

• Masalah: Aplikasi membutuhkan pengaturan yang dapat dikonfigurasi.
• Solusi: Simpan pengaturan dalam file (WIN.INI) di folder Windows - gunakan judul bagian untuk mengelompokkan data (Win3.0).
• Masalah: File WIN.INI tumbuh terlalu besar (dan menjadi berantakan).
• Solusi: Simpan pengaturan dalam file INI dalam folder yang sama dengan aplikasi (Win3.1).
• Masalah: Perlu pengaturan khusus pengguna.
• Solusi: Menyimpan pengaturan pengguna dalam file INI khusus pengguna di direktori Window pengguna (Win3.11) atau bagian khusus pengguna dalam file INI aplikasi.
• Masalah: Keamanan - beberapa pengaturan aplikasi harus hanya-baca.
• Solusi: Registri dengan keamanan serta bagian khusus pengguna dan bagian mesin (Win95).
• Masalah: Registri tumbuh terlalu besar.
• Solusi: Registri khusus pengguna dipindahkan ke user.dat di folder "Data Aplikasi" milik pengguna dan hanya dimuat saat masuk (WinNT).
• Masalah: Di lingkungan perusahaan besar Anda masuk ke beberapa mesin dan harus menyiapkan SETIAP SATU.
• Solusi: Bedakan antara profil lokal (Pengaturan Lokal) dan roaming (Data Aplikasi) (WinXP).
• Masalah: Tidak dapat xcopy menyebarkan atau memindahkan aplikasi seperti sisa .Net.
• Solusi: APP.CONFIG file XML dalam folder yang sama dengan aplikasi -, mudah dibaca, mudah dimanipulasi, mudah dipindahkan, dapat dilacak jika diubah (.Net1).
• Masalah: Masih perlu menyimpan data khusus pengguna dengan cara yang serupa (mis. Xcopy deploy).
• Solusi: USER.CONFIG file XML di folder lokal atau roaming pengguna dan sangat diketik (.Net2).
• Masalah: File CONFIG peka huruf besar-kecil (tidak intuitif bagi manusia), memerlukan "tag" buka / tutup yang sangat spesifik, string koneksi tidak dapat ditetapkan pada saat run-time, proyek setup tidak dapat menulis pengaturan (semudah registri), tidak dapat dengan mudah menentukan file pengguna.config dan pengaturan pengguna ditiup dengan setiap revisi baru diinstal.
• Solusi: Gunakan anggota ITEM untuk mengatur string koneksi saat runtime, tulis kode dalam kelas Installer untuk mengubah App.Config selama instalasi dan gunakan pengaturan aplikasi sebagai default jika pengaturan pengguna tidak ditemukan.

Apakah dunia akan berakhir jika Anda menyimpan beberapa posisi jendela dan daftar item yang paling baru digunakan dalam registri Windows? Sejauh ini itu berhasil bagi saya.

HKEY-CURRENT-USER adalah tempat yang bagus untuk menyimpan data pengguna sepele dalam jumlah kecil. Itu untuk apa. Tampaknya konyol untuk tidak menggunakan untuk tujuan yang dimaksudkan hanya karena orang lain telah menyalahgunakannya.

Pengaturan yang ingin Anda miliki di profil roaming pengguna mungkin harus masuk dalam registri, kecuali Anda benar-benar ingin pergi ke upaya mencari folder Data Aplikasi pengguna dengan tangan. :-)

Registri membaca dan menulis adalah threadsafe tetapi file tidak. Jadi itu tergantung pada apakah program Anda satu threaded atau tidak.

Jika Anda sedang mengembangkan aplikasi baru dan Anda peduli tentang portabilitas Anda harus TIDAK PERNAH menyimpan data di windows registry karena OS lain tidak memiliki (windows) registry (duh note - ini mungkin jelas tetapi sering diabaikan).

Jika Anda hanya mengembangkan untuk platform Win ... cobalah untuk menghindarinya sebanyak mungkin. File konfigurasi (mungkin dienkripsi) adalah solusi yang jauh lebih baik. Tidak ada keuntungan dalam menyimpan data ke dalam registri - (penyimpanan terisolasi adalah solusi yang jauh lebih baik misalnya jika Anda menggunakan .NET).

Agak di luar topik, tetapi karena saya melihat orang-orang khawatir tentang portabilitas, pendekatan terbaik yang pernah saya gunakan adalah kelas QSettings Qt. Ini abstrak penyimpanan pengaturan (registri pada Windows, file preferensi XML pada Mac OS dan file Ini di Unix). Sebagai klien kelas, saya tidak perlu menghabiskan siklus otak bertanya-tanya tentang registri atau apa pun, itu Hanya Bekerja (tm).

http://doc.trolltech.com/4.4/qsettings.html#details

Biasanya, jika Anda tidak meletakkan pengaturan dalam registri, Anda menggunakannya sebagian besar untuk mendapatkan pengaturan Windows saat ini, mengubah asosiasi file, dll.
Sekarang, jika Anda perlu mendeteksi apakah perangkat lunak Anda sudah diinstal, Anda dapat membuat entri minimal dalam registri , itulah lokasi yang dapat Anda temukan kembali dalam konfigurasi apa pun. Atau cari folder dengan nama yang diberikan di Data Aplikasi.

Jika saya melihat folder Dokumen dan Pengaturan saya, saya melihat banyak perangkat lunak menggunakan notasi Unix dot untuk folder pengaturan:. .jindent .jogl_ext (dll.)

dan dalam Data Aplikasi, berbagai folder dengan nama editor atau nama perangkat lunak. Sepertinya menjadi tren saat ini, setidaknya di antara aplikasi portabel ...
WinMerge menggunakan pendekatan yang sedikit berbeda, menyimpan data dalam registri, tetapi menawarkan Impor dan Ekspor opsi dalam dialog konfigurasi.

Secara pribadi saya telah menggunakan registri untuk menyimpan jalur instalasi untuk digunakan oleh skrip instalasi (tidak). Saya tidak yakin apakah ini satu-satunya pilihan yang mungkin, tetapi sepertinya solusi yang masuk akal. Ini untuk aplikasi yang hanya digunakan pada Windows saja.

Dalam. NET benar-benar TIDAK pernah ada kebutuhan.

Berikut adalah 2 contoh yang menunjukkan cara menggunakan projek Proyek untuk melakukan ini.

Contoh-contoh ini melakukan ini oleh Properti Proyek Pengguna Windows, tetapi hal yang sama dapat / dapat dilakukan oleh Aplikasi juga.

Lebih banyak di sini:

http://code.msdn.microsoft.com/TheNotifyIconExample

http://code.msdn.microsoft.com/SEHE

(terlambat ke diskusi tetapi) Jawaban Singkat: Kebijakan Grup.

Jika departemen TI pelanggan Anda ingin menegakkan pengaturan terkait dengan Windows atau komponen yang Anda tulis atau bundling, seperti kecepatan tautan, atau pesan kesalahan khusus, atau server database untuk terhubung, ini biasanya masih dilakukan melalui Kebijakan Grup, yang menjadikan manifestasinya sebagai pengaturan yang disimpan dalam registri. Kebijakan tersebut diberlakukan sejak Windows mulai atau pengguna masuk.

Ada alat untuk membuat templat ADMX khusus yang dapat memetakan pengaturan komponen Anda ke lokasi registri, dan memberi administrator antarmuka umum untuk menegakkan kebijakan yang perlu ditegakkan sambil menunjukkan hanya pengaturan yang bermakna untuk menerapkan cara ini.

Saya percaya bahwa Windows Registry adalah ide yang bagus, tetapi karena penyalahgunaan hebat dari pengembang aplikasi dan kebijakan standar yang tidak didorong / diamanatkan oleh Microsoft tumbuh menjadi binatang yang tidak terkendali. Saya benci menggunakannya karena alasan yang Anda sebutkan, namun ada beberapa kesempatan yang masuk akal untuk menggunakannya:

• Meninggalkan jejak aplikasi Anda setelah aplikasi Anda dihapus instalasinya (mis. Ingat preferensi pengguna jika aplikasi diinstal lagi)
• Bagikan pengaturan konfigurasi antara berbagai aplikasi - komponen