Howto create a read/write application setting?
Hi!
I'm trying to create a writeable application setting with VS 2005 Express beta-2.
When I open the Settings tab in the application properties I have a designer that allows to create a new setting (say "MySetting" of type String). I can specify a default value and I can use the properties window to enter a description etc.
In the code file Settings.Designer.cs a property "public string MySetting .." is generated automatically. But this property doesonly have a getter method, no setter!
Somewhere I found mentioned that only read/write properties would have a setter generated. But I did not find how I specifiy this!!
Does anybody know:Where do I specify that MySetting shall be a read/write setting?
Thanks for your help!
Karlo
[780 byte] By [
Karlo] at [2007-12-16]
I believe the rationale for this is that application settings
are usually readonly, being configuration options specified by the developer.
Any settings that can be changed by the end user are stored as user settings, which can be modified.
You define user settings by changing the scope dropdown in the settings designer.
You can define them using the properties list (Application Settings) for any properties that you want to store, or add them manually using the designer for other settings.
You access them using something similar to:
myForm.WindowState = MyNamespace.Properties.
Settings.Default.window_state;...Default refers to the profile (VS adds all this for you if you define properties as settings). The settings are written to a separate section of the app.config.
I haven't looked into how you store settings on a per-user basis yet...it probably requires some manual intervention.
HTH,
R.
Yes, application scoped settings are intentionally generated as read only since they are not intended to be changed by the application itself.
And yes, the way to make the setting read/write is indeed to make it a user scoped setting.
However, MyNamespace.Properties.Settings.Default do not correspond to the default profile's value it corresponds to the default instance for this settings class. There can be multiple instances of the same settings class (consider a class library that contains a user control that stores some settings - you can add multiple instances of the user control onto your form, and you may want each of the user control instances to have it's own set of settings) You can use the SettingsKey property to identify different instances of the same settings class.
The setting profiles were intended to solve the problem of having a different set of settings for different environments (i.e. have one connection string for your developer environment and another for the deployed application) Unfortunately we discovered many issues with the current implementation of settings profiles, so the feature will be cut for the final release of the product.
User scoped settings are written to a user.config file that is located under your My Documents folder, so there is absolutely no manual intervention required to store settings on a per-user basis.
Best regards,
Johan Stenberg
Thanks for the clarification - I've obviously convinced myself that I knew how it was working! Your explanation makes a lot more sense.
My confusion over the location of the per-user settings came about because on a quick test (eg. storing the windowstate) the settings were written to the app.config file under a usersettings key:
<configuration>
...
<appSettings>
<userSettings>
<Mynamespace.Properties.Settings>
<setting name="window_state" serializeAs="String">
<value>Maximized</value>
</setting>
...
I can't see a user.config anywhere, so what's happening there?
Thanks,
R.
When the application reads the settings, it will first check the user.config, which is located under the running user's Documents And Settings folder, to see what the value should be. If it can't find a user.config file, or if it can't find the value in the file, it will check the app.exe.config file. If it can't find it in the app.exe.config file, it will fall back to the value baked into the settings class as a default value attribute. If it still can't find it, it will try to create an "empty" value (normally by creating a new instance from a constructor that takes no arguments)
The user.config files are not part of your project.
The values for user scoped settings in the app.config file makes it possible for an administrator to change the initial value for the setting, but still let the user override it.
Now, if you use another settings provider than the LocalFileSettingsProvider to store your settings, the story may be different. (If are not familiar with the concept of settings providers, you are using the LocalFileSettingsProvider 
)
Best regards,
Johan Stenberg
Johan, I am having problems doing this in C#. I see that you are in the VB group. I read that VB automatically handles settings while C# does not. I have a hard time believing this. The IDE exposes a way to automacally create the settings, yet it is not persisting them at the end of the session. I can't find a way to tell it to persist them either, at least without going through a lot of work creating a wrapper for ApplicationSettingsBase and telling it all the pertinent info about my settings.
What am I missing? Please help!
Thanks :)
Ingram Barclay
The reason that this works in VB is VB's new (and may I say very cool) My application framework. Using this, you can get a notification when the application is about to shut down, and this is the point where the My application framework automagically saves your settings if so instructed.
Since the My application framework isn't available in C#, there is no way for us to figure out exactly when the application is exiting, so there is no way for us to automatically save the settings.
The problem is to figure out exactly where you want to save. If your application has a main form, then the FormClosing or FormClosed events is usually a good bet.
Saving your settings should be as simple as calling Save on the instance of your settings class. The IDE will already have created a class that derives from ApplicationSettingsBase, and which exposes your settings as properties. From VB, you can access these using My.Settings. In C#, you can use the (in my opinion) slightly less elegant Properties.Settings.Default to access the default instance of your settings class.
Best Regards,
Johan Stenberg
I'm currently working under Beta 2.
It doesn't look like the my.settings class supports groups of settings yet. Will this feature be added or should I just plan on manually implementing a settings class for use with the property grid.
If this feature is already available, can you point me towards documentation for it?
Since the default for my.settings shows in the property grid as 'Misc' settings, the property grid looks a bit 'un-finished.' I'd like to group related attributes to help the user find settings and to create a more polished application.
Thanks
I'm not 100% sure if you are referring to the SettingsGroupAttribute (which allows users to override the "group name" for the attribute - if not specified, the group name is the namespace qualified name of the settings class) or to System.ComponentModel.Category attribute.
Either way, you are correct, the settings designer/my.settings does not support groups of settings, and there is currently no plan to do so.
Please feel free to add a suggestion to http://msdn.microsoft.com/productfeedback/
Best regards,
Johan Stenberg
I was reading through forum about application settings but didnt find solution about it.
If we have following situation:
* Systemwide - oneuser application
* User will be able to configure application - read/write settings
* Store configuration file/files in same diractory as application exe
how to aprouch the problem?
Regards
Gamb
The LocalFileSettingsProvider doesn't support this scenario. You would need to implement/use another settings provider...
On a side note, from a security perspective, it is usually not a good idea to let users have write access to the program files folder.
Why do you want to do this?
Best regards,
Johan Stenberg
Hi Johan
At the moment i`m developing software for the industry. I need to simplify application and let software user/operator to be able to change some settings in application. It will simplify things more if I have those settings in same directory as application.
Any ideas?
In the mean time, I will check out "SettingsProvider Class " and see what i can do
Regards
Gamb
Hi Johan!
I find the new Settings API very useful. However, I would like to be able to update the application scoped setting using a windows application (some kind of adminstrative config tool), thus not having to edit the app.config file manually!
I started out with a very simple GUI based on a propertygrid displaying my custom settings (appsettingsbase derived) and all works just fine as long as I use user scoped settings...
My point is that I think this is a common scenario: you build an app using the settings API, but you would like to also provide the "adminstrator" with a tool to configure the application (not the user preferences in this case). This is, I belive, not possible without having to write your own SettingsProvider.
I would like some simple way to either "override" the LocalSettingsProvider or tell it to be nice to the adminstrator.
Any ideas?
Regards,
Peter Svahn
I agree with Peter and I'd also like to add the following suggestion.
I'd like to be able to use various layers (or hierarchial levels) in the propertygrid control, but this isn't supported by the SettingsProvider. Currently, all settings for an application are lumped together with little control over order and grouping.
Thanks,
Jason
PSvahn,
we did discuss enabling this very scenario for the LocalFileSettingsProvider, but decided against implementing it. The main reasons (other than scheduling constraints) were that:
1) We didn't want to encourage people to have their application read/write in the program folder. While the admin scenario that you describe certainly is valid, the most common argument that I've heard for being able to do this has been that people don't like to have the files "hidden" in the current user's folder, and that they don't have any issues with letting "normal" users write to the app.config file (something that has serious security implications)
2) The way that the LocalFileSettingsProvider is set up, you would have to have the administrative application run in the same context (application) as the application that consumes the settings. In many cases, you want to be able to point an admin tool to a specific configuration file to edit.
I would suggest that you take a look at the classes in System.Configuration.Configuration (System.Configuration.dll) if you want to create a separate admin tool.
Best regards,
Johan Stenberg
RFGuy,
You can use multiple .settings files (which means multiple settings classes) in order to group your settings. I agree that this may not be the perfect solution, but it has proven to be good enough in most cases.
Best regards,
Johan Stenberg
Hi Johan,
Making app.config writable is useful in such application using scenario: app is sitting on the flash-drive and user runs it on different computers. But user needs to take app configuration with him always.
So storing user-specific configuration on the computer depended directory isn't good.
Johan
I am developing server backend software which is run by a special user account which is no human user - sometimes even the system account. Thus I am seeing application settings more abstract as belonging to the app, not a certain user. I would very much appreciate if the app settings could be written. Besides, that the LocalSettingsProvider.Save Function does not throw an error should be reconsidered - in the old times of COM the behaviour would have been E_NOT_IMPLEMENTED which is clearer than simply ignoring a request. I understand that MS wants the developers to implement only the best practises but in this case I feel patronized by you guys. Until then I'll use user specific settings.. And remember windows services have emotions too ;-)
Gerhard
