Quote:Application-scoped settings can be used for information such as a URL for a Web service or a database connection string. These values are associated with the application, so users cannot change them at run time. User-scoped settings can be used for information such as remembering the last position of a form or a font preference. Users can change these values at run time.That's all nice and dandy, but this app happens to have application wide settings that should be the same for all users on a machine, while any user may change them at runtime. I did some digging and it seems that VS Settings won't work for this though. I know I could just change the scope from app to user, but as I understand that means each user would need to configure these settings seperately, which is quite an inconvenience in this case (multiple non-tech users per machine, lots of tech settings). I can't imagine that this rather common scenario isn't supported, so am I missing something here? Perhaps user-scope just means user-changable, but not isolated per user?
[.net] VS Settings, persisting Application scoped settings not possible?
Author
Instead of stubornly coding my own stuff like I usually do, I decided to give the Settings feature in Visual Studio a try for a little standalone app of ours. It works quite well, but I found it doesn't seem to store any changes to Application scoped settings. This seems to be expected behavior according to this MSDN page:
Author
For future reference, I decided to just use an XMLSerializer to persist the app scoped settings objects to a little XML file in the CommonApplicationData folder. These objects are stored in a List<> subclass in my app settings, so as the first thing on the Form.Load event I Clear() this list from the original settings and plug in the ones I loaded manually. For saving them, I just have the XMLSerializer dump out the XML file in an overidden OnClosing. This way one can still use the settings 'infrastructure' and persist app settings without much extra work.
I wonder though, isn't anyone else using this Settings stuff? I dug around a bit and there may be some more pitfalls with persisting settings. Specifically it seems to store user scoped settings in a subfolder specific to the build & revision numbers, which might mean a new build/revision will break user settings(?). Does anyone have any experience with this, or was everyone smart enough to steer clear of the Settings? [smile]
I use the settings stuff. It works for what it's indended for. It's not very flexible nor scalable, but settings shouldn't be that anyways :) and yes, the commonappdatafolder is the right target for you.
I'm not sure if it's possible to somehow get a settingsfile to store at a userchosen target so you could use it for your case. I guess not (but it would be cool to get the editor to use there :))
I'm not sure if it's possible to somehow get a settingsfile to store at a userchosen target so you could use it for your case. I guess not (but it would be cool to get the editor to use there :))
Author
Thanks for your reply Dave, good to hear I'm not the only one that ventured into this quagmire at least [smile] For it's intended purposes it does work like it should, but I can't help thinking that my scenario isn't that uncommon and that built-in support for it would be nice. I could try posting it on Connect, but even if the powers that be agree I doubt they can get it in any time soon. So I guess I'll stick with my hacky solution.
The user scoped config file goes into the LocalApplicationData folder, in a subfolder based on the info in the AssemblyInfo.cs file. Basically it becomes
I fear having the full version including build/rev numbers in the path will still break the user settings when deploying an update to the program. I'm only using non-critical user settings, so it's not a big deal but it seems weird if it really works this way. I guess I could just hardcode these numbers instead of using *, but that kinda defeats the purpose of versioning.
Ah well, at least it works for now [wink]
The user scoped config file goes into the LocalApplicationData folder, in a subfolder based on the info in the AssemblyInfo.cs file. Basically it becomes
C:\ Users \ [Name] \ AppData \ Local \ [company] \ [executing assembly + some hash] \ [full version] \ user.configI fear having the full version including build/rev numbers in the path will still break the user settings when deploying an update to the program. I'm only using non-critical user settings, so it's not a big deal but it seems weird if it really works this way. I guess I could just hardcode these numbers instead of using *, but that kinda defeats the purpose of versioning.
Ah well, at least it works for now [wink]
Actually you can directly read and write to the Application settings file if you want.
You can access the XML application settings file doing this.
So you can still use all the settings goodies and write to the application wide settings when you need to.
And as for the versioning breaking the settings, that should be handled by your installer.
theTroll
You can access the XML application settings file doing this.
Configuration config = ConfigurationManager.OpenExeConfiguration(System.Configuration.ConfigurationUserLevel.None);System.Xml.XmlDocument xmldoc = new System.Xml.XmlDocument();xmldoc.PreserveWhitespace = true;string filepath = config.FilePath;xmldoc.Load(filepath.Trim());So you can still use all the settings goodies and write to the application wide settings when you need to.
And as for the versioning breaking the settings, that should be handled by your installer.
theTroll
Author
Ah ok, thanks! I'd rate you both up if I could, but you both seem to have been extremely helpful and/or friendly already [smile]
I still disgruntled about them not supporting this in the first place though :p
Quote:Original post by TheTroll
Actually you can directly read and write to the Application settings file if you want.
You can access the XML application settings file doing this.
*** Source Snippet Removed ***
So you can still use all the settings goodies and write to the application wide settings when you need to.
And as for the versioning breaking the settings, that should be handled by your installer.
theTroll
does that still work in Vista? you can't write to the program folder there without elevation to admin. or does it store in the all user app data folder?
I don't believe the settings file is in the Program Files folder. I believe they store it in the Documents and Settings folders. Not at my dev computer right now so you would have to test it.
theTroll
theTroll
it should be in the programs folder, as the global application settings are what should be configurable by some administrator and then xcopy deployable by f.e. login scripts.. => it's all in the same folder..
but i'd have to try it out laters, too :)
but i'd have to try it out laters, too :)
i think the solution would be, to per-config-option allow readwrite or readonly. the default is in the programs folder, and any global change gets into the all users\appdata folders. certain settings are not good to be user-changable at all on a global nor local scale (per user) => this should be chosable.
so i propose this scheme:
a setting is
global, readonly (only in program files\)
global, per user changeable (default in program files\, user change in currentuser\appdata)
global, globally changeable (default in program files\, user change in allusers\appdata)
there would even be the possibility to have a
global, globally changeable, AND per user changeable, too..
this would fit the original posters needs.
so i propose this scheme:
a setting is
global, readonly (only in program files\)
global, per user changeable (default in program files\, user change in currentuser\appdata)
global, globally changeable (default in program files\, user change in allusers\appdata)
there would even be the possibility to have a
global, globally changeable, AND per user changeable, too..
this would fit the original posters needs.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
