Roy's Config Hell
... 'Write' functionality on config files is just as logical as reading from them. If you want us to steer away from ini files, or registery values - give us something that replaces this functionality at the simplest level.
When i first saw the appSettings thing- i was pretty excited (even though its a small thing). "Yoohoo! No need to write plumbing to save and read simple settings anymore!" . wrong. you can read - but not write. c'mon! give me a break!
My take on this issue is that config files are used by .NET for .NET - they threw us developers a bone with the appsettings, but that's about it. I totally understand the .NET designer's worries about allowing programmatic write access to the config files - corrupting them could easily bring down the whole box, not to mention that the same file also holds security settings. If you want something which you have complete control over, do it yourself. It would have been nice to have gotten some basic tools for that, but hey- If BillG let me manage their development team for a day, that feature probably wouldn't have been high on my list.
I heard (somewhere) that MS is thinking about the problem but with a different spin - they might actually allow some assemblies to be writable. This would allow you to include whatever files you want as resources inside your assembly, and dynamically update them as needed.
There are a lot of security issues involved -would those assemblies need to be resource assemblies only (to preserve code integrity)? How would a strongly-named assembly reference one of those (which obviously can't be signed), etc.
God knows if or when this will see the light of day but if it does, it would improve both deployability (is that a word? ) and easy-of-development when working with configuration files.
BTW, how cool is this? I hate the VS built-in Schema inference - it always trys to map my XML into a dataset.
Comments
- Anonymous
April 08, 2003
The comment has been removed