I use a settings file in my project in addition to a configuration file, and I wish to move away from using the settings file in preference to the configuration file.
The settings file is the default .net application setting mechanism (ApplicationSettingsBase), and my configuration file is a custom class that I serialize and deserialize manually.
I have successfully in the past applied the NeedUpgrade/Upgrade() logic to keep settings from previous versions, but somehow it seems settings are lost non-the-less.
The difference with this project in regards to earlier projects, is that it is deployed using Click-Once.
To work around the problem, I wish to move away from the settings file all together and rather use my configuration file which is stored in a static folder (Environment.SpecialFolder.LocalApplicationData), but I do not know how I best would proceed in managing this migration/change.
Any advice is appreciated.
Related
Situation
I'm creating a project in WPF where I want to store some data in config files. Like menu Items, tree items and some other data. The ways I could implement this was by using:
XML Files
Ini Files
Integrated Settings
Databases
What is the problem
I chose the ini file approach with this library.
But if a user removes a config file I should have a default back up of my settings, so my program can run without any problem. The options to restore to the default settings that came up to me where:
Getting the default settings from the server
Creating a class that stores the default settings, when a file gets removed this class can restore it.
I think this is a dirty solution because these classes are mostly unused but are included in the project. And if I follow the SOLID and DRY approach I will end up whit +- 7 more (unused) classes.
By doing this I will also ruin the idea of getting the settings
out of my code.
Using the integrated settings from visual studio that has this already build in
I don't think this is meant for storing large amounts of data, like
tree items, menu items.
Question
How should I restore my data to default (by recreating the config file whit the default settings) when a user removes the config file? What approach should I take, or are there any that I missed?
You could include the default fallback settings in a file that you compile into the assembly as a resource.
The user won't be able to remove this one like they can remove a file in the output directory of the executable.
We have 1 settings file with the customer settings for each costumer, but the problem is that we have to change lots of settings values when releasing a new version for each costumer, as we develop using the test settings. So, its a totally mess.
Whats the best solution for this?
Having one settings file and app.config for each costumer?
Saving the configurations into the database?(we would still have the connection string settings)
Each costumer cant see the settings from the others..
We use a Configuration Transformation for this and have multiple Build (Release) configs like
Release-Internal
Release-CustomerA
Release-CustomerB
You can have one "base" config file and just replace the values you need for the specific configuration.
Your file structure would look like this afterwards
app.config
app.Release-Internal.config
app.Release-CustomerA.config
app.Release-CustomerB.config
We usually use this for the connection strings and some specific view settings.
Visual Studio only has nativ support for ASP.NET projects (for whatever reason), but there are multiple Plugins to enable this for other .NET projects.
I can recommend Configuration Transform (I like this one better) or SlowCheetah.
This may sound like a trivial question, however I have looked over the web briefly and what I found was that app.config is basically an older mechanism for storing Application key/pairs of data for the application.
What I want to know is there any reason we (as .NET developers) would opt to use app.config over a Settings file ?
-Can someone please provide some pros and cons on both so we can use them properly.
thanks again
App.config for desktop applications and Web.config for web applications are part of .NET configuration system. Primarily they are used to control .NET framework settings in respect to our application. These are such configuration settings as substitutions of versions of assemblies (section <assemblyBinding>), substitution of .NET framework version (<startup>) etc. (see msdn for the full app.config schema.) One section is dedicated for custom settings of application developers (<appSettings>). There is also a possibility to create custom sections. So, when we need to store settings we can either piggy-back on the app.config or create our own separate configuration files.
Here are pros and contras of using app.config:
Pro: There is already a standard API in .NET to read settings from appSettings section. If you only need just a couple of config settings, it is much easier to use this ready API than to develop and test your own class to read your config files. Also, app.config file is already included in VS project for you.
Pro: There is a standard hierarchy of machine.config/app.config. If you plan such settings that can be set machine-wide and overridden or left as-is for individual applications, you should use app.config.
Pro/Con: App.config is cached in run-time. If you anticipate updates of it while your application is running, you need to specifically request refresh of certain section of config file. For web.config the web app is automatically restarted when something is changed in the file. This is quite convenient.
Con: app.config is stored in the same directory as your .exe file. Normally it will be in a subfolder of C:\Program Files. This directory is extra protected in Windows 7 from writing. You need to be member of Administrators group to write there and if your UAC (User Access Control) level in Control Panel is not set to 0 (which normally is not), you will be asked by the OS to confirm writing to c:\Program Files. So, users without Administrator rights will not be able to change configuration in app.config. Same goes for changing your settings programmatically: your application will get exception when attempts to write app.config if it runs not under an admin user on Windows 7. Your own config files usually go to C:\ProgramData\ or c:\Users subfolder (on Windows 7). These locations are friendlier to writing by users or programs.
Con: If user edited your app.config file and accidentally corrupted it, the whole application will not start with some obscure error message. If your separate config file is corrupted, you will be able to provide more detailed error message.
In conclusion: app.config gives you easier (faster development) approach, mostly suitable for read-only settings. Custom settings file gives you more freedom (where to store file, validation/error handling, more flexibility with its schema) but requires more work during development.
You have it backwards, the settings file (or ini file as they were originally called) was the mechanism used to hold application settings (key/value pairs) prior to Windows 95. With the release of Windows 95 it was recommended that application settings be moved into the Windows Registry (which proved problematic since if you screwed up your registry your Windows may no longer be able to start).
The .config file came into play with .Net. The XML format allows more dynamic and complex settings configurations than simple key/value pairs.
The modern user/settings file is an XML extension of the .config file (settings that can override certain settings in the .config under specific conditions).
My ClickOnce app includes an app.config file, which the app does modify according to the user's preferences. It appears, though, that every time my clients get a new version of the app, the app.config file gets reset to its original state.
Is there any way to preserve the app.config file between ClickOnce updates?
The app.config is used to store application configurations. For user custom configurations you should be using a .settings file.
The only way I know to keep the user app config is to save a copy of the file before publishing and, post publishing, replace the
publish_dir/version_dir/app.config.deploy
with the copy.
I would separate the configuration settings from the application cache. We rolled our own class for storing and updating config values rather than use the built-in ones.
http://robindotnet.wordpress.com/2009/08/19/where-do-i-put-my-data-to-keep-it-safe-from-clickonce-updates/
I am working on a component/assembly that is to be distributed to other developers and included in their systems.
In order to minimize the work they have to do, all configuration is done in a seperate file (my.config).
My current problem is that a library I am using requires configuration to be added to the app.config file of the application. I have no way of modifying this, so that it reads my custom config file.
Is there any way to add a section/setting to the current config, so that it behaves as if it was read from the app.config?
I can add to the app.config, so it must work at runtime only.
Thanks, Jonas
I don't think you can update the configuration without changing the underlying file. It's a read-only thing.