Background: I'm developing a Windows service using C# and .Net 3.5.
The behavior of the service should be controlled by some settings. The settings will varyper host-computerbut will not vary per user (which should be understandable since the settings control behavior of a service.) A GUI panel of sorts must be provided to set-up and modify the settings that control the service behavior.
Secondly, there is a "locally installed application" that has its own settings and those settings also vary per host-computer so all users of that computer would experience the same settings. (Seemingly analogous maybe to a connection string but not a connection string.)
Note that I do NOT perceive any need for Click-once support, web support, and so forth. Translation: I think I need the simplest darn type of settings support, the old "dinosaur" level of requirements not much more sophisticated than INI files used to be.
I've researched using the "built-in" settings that make use of the Settings Visual Designer in VS 2008 and System.Configuration.ApplicationSettingsBase. It seems that:
It seems that what I "really" need is for Application Settings to be writable at run-time, thus permitting an simple GUI control panel to be supplied by the software. Why on earth is there a hole exactly where my requirements sit? Attempting a solution seems to slip rapidly into an enormous rat-hole of complexity. I.e. it's just plain "wrong" to require ten NASA scientists to work for five years on advanced mathematical formulas to accomplish tying a pair of everyday shoes on earth!.
I'm highly tempted to simply roll my own XML file and call it done. But I'm so stunnedthat I haven't found a simple approach that is directly supported by the Framework that I feel compelled to ask and try to locate what I must have overlooked.
Maybe there's a link to the one article that I missed that neatly solves the requirement.?
The behavior of the service should be controlled by some settings. The settings will varyper host-computerbut will not vary per user (which should be understandable since the settings control behavior of a service.) A GUI panel of sorts must be provided to set-up and modify the settings that control the service behavior.
Secondly, there is a "locally installed application" that has its own settings and those settings also vary per host-computer so all users of that computer would experience the same settings. (Seemingly analogous maybe to a connection string but not a connection string.)
Note that I do NOT perceive any need for Click-once support, web support, and so forth. Translation: I think I need the simplest darn type of settings support, the old "dinosaur" level of requirements not much more sophisticated than INI files used to be.
I've researched using the "built-in" settings that make use of the Settings Visual Designer in VS 2008 and System.Configuration.ApplicationSettingsBase. It seems that:
1. Application Settings cannot be changed at runtime. MSFT documentation indicates the software must be shut down and settings must be modified by patching the XML with a text editor (notepad et al.) The framework specifically prohibits application settings from being changed programmatically. I thought this was someone's idea of a bad joke; ha ha aaaaaaa noooo waay.
2. User settings provided by the Visual Designer and corresponding auto-generated code apparently WILL vary per user and are therefore totally inappropriate to use for the purposes that I outlined. There's a lot of apparent ambiguity in the documentation and emperically I see settings being written to an app.config file (not a separate user.config file). But the majority of information seems to say that attempting to use "user settings" would get me in trouble considering that I do not want settings to vary by user.
I noted that there were several "levels" to user settings implemented by ConfigurationManager, but the Visual Designer supplied settings did not seem to expose these or offer "control" to the developer.
3. It might well be close to "living ____" to try to mess with inheriting from the default LocalFileSettingsProvider and trying to override behavior to suit my purposes. It's appears to be written to deter anyone who would dare to think of it.
4. Developing another Provider might also be an unreasonable amount of effort in light of the very simple requirements I have. Writing directly to ConfigurationManager API might not be very efficient either, and would ditch all the convenience that was supposed to be offered by the Visual Settings Designer, auto-generated strongly typed settings and so on.
5. I've found quite a few articles discussing the complexity and intricacies of MSFT configuration architecture but haven't found a "search hit" on an article discussing how to do something as simple as I need to do in the (low) amount of time and effort that is appropriate to the requirements.
It seems that what I "really" need is for Application Settings to be writable at run-time, thus permitting an simple GUI control panel to be supplied by the software. Why on earth is there a hole exactly where my requirements sit? Attempting a solution seems to slip rapidly into an enormous rat-hole of complexity. I.e. it's just plain "wrong" to require ten NASA scientists to work for five years on advanced mathematical formulas to accomplish tying a pair of everyday shoes on earth!.
I'm highly tempted to simply roll my own XML file and call it done. But I'm so stunnedthat I haven't found a simple approach that is directly supported by the Framework that I feel compelled to ask and try to locate what I must have overlooked.
Maybe there's a link to the one article that I missed that neatly solves the requirement.?