Using User Settings in Partial Trust

In my previous post on ClickOnce custom install steps, I talked about how to read and write custom settings from Isolated Storage. One thing I purposely avoided mentioning there (because I needed to get confirmation on some facts from the product team at Microsoft) was the use of the new User scoped settings in .NET 2.0 and Visual Studio 2005.

If you are not already aware, the approach to config files has changed quite a bit in .NET 2.0. When you create a project in Visual Studio 2005, you can add custom settings through the project property pages (Settings tab), and those will be persisted in your config file and available to you at runtime. Additionally, strongly typed properties are added to a Settings class that is created by the designer so that you can access those settings programmatically with code like this:

string myCustomString = Properties.Settings.Default.MyCustomString;

The Settings class is declared in a child namespace of your project namespace called Properties, and the Settings class has a singleton property called Default that you use to get a reference to the one and only one instance of the Settings class for your app. From there, you just access the settings in your config file through named strongly typed properties.

That on its own would be a big win from a design time and compile time perspective, but the full story is even better. For one thing, you can designate whether settings are scoped to the application or to the user. If scoped to the application, then the settings go in your application configuation file as usual (.exe.config or web.config as appropriate). If scoped to the user, the settings go into a slighly obfuscated directory under the user’s profile, under \Local Settings\Application Data.

The other thing about user settings is that all the properties for them that get exposed through the Settings class are both read and write. So you can set the properties, call Save on the settings class, and your changes will be written out to the user config file:

Properties.Settings.Default.MyCustomString = “SomeNewValue”;

Properties.Settings.Default.Save();

So for the scenario I was describing in the previous post about writing out a flag to indicate when it is no longer the first time you application has run, a boolean user setting is cerrtainly a prime candidate for a place to put that. And if you read the docs for user settings, you will see that it says that you can write to user settings in partial trust, so it should be a winner for ClickOnce deployed apps as well. The reason I held off on mentioning it in the other post is a typical story:

User Settings do not work in partial trust in Beta 2.

If you try to write out user settings (call Save) in a partial trust environment in Beta 2, you will get a FileIOPermission security exception thrown. The thing I was waiting for confirmation on was that this will be fixed for RTM, and the answer was yes. So for production apps releasing after RTM, you can do all your ClickOnce custom settings through user settings, and not have to write explicitly to IsolatedStorage. There may still be some scenarios where you want more explicit control over the I/O process, in which case Isolated Storage is still your best option for a ClickOnce app to minimize your permission requirements.