I have a several MVC project's (all the same) and I'm wondering where to place the Application Configuration? Right now I have the following options:
Store them in a central database
Store them in the application database
Store them in the appSettings (web.config)
Store them in a configsection
Store them in a custom configuration file
I wonder what the best practice is for a situation like this
I think you must store them in application databse. Cuz,
It will be different for every application, e.g. If one application light theme and the other wants dark theme.
It is better to save in databse, cuz you can update the configuration by application itself or by running a query. So, its very to simple to change the settings rather than keeping it in Web.Config.
You can create a class to acces the configuration values from database. use Indexer so that you can use it like Configuration["Theme"] makes the access more easier. I have used it in my project.
But, if its database related, you need to store it in web.config
Hope, it helps you lil bit. Have a nice day. :)
I don't know if there is really a common 'best practice' for where to store settings. You would have to take into consideration all the variables for a given situation. Some thoughts I had:
Storing settings in a database could be useful if you require central storage between different applications. Would have fewer concurrency issues. Depending on the type of settings stored, you could find database schemas being inefficient. It also brings in a dependency on another server/service for the application.
Storing in web.config is nice and simple. Not really useful for settings that need to be changeable from the application. Also, any change to settings in web.config will initiate an app restart.
Custom configuration file would give more flexibility for setting storage. You will of course have to write additional code to read/write the settings. Serialisation could handle this in a lot of cases.
If it's low-level application settings that are changed rarely and only by you, I'd probably go for just web.config. If you're talking about settings that are changed through the application (e.g. user preferences), I'd go for database storage.
You should store default values in web.config and other settings in your database.
For example if your application has a mailing system, than smtp settings should be stored in your database, but the culture in which mails are sent should be stored in web.config
Also, there is a way to store application settings in your Visual Studio environment, as follows
Right click on your project > Properties > Settings tab > Create
but I've never used this. You can also update your settings by calling .Save() method. Read more about it here
In my case :
I store settings in my database
I store default values in web.config
Configuration is something which one should quickly locate, that is why there are configuration files in projects irrespect to platform. Every platform sdk now comes with SDK which ensures their community follows practices they recommend.
If you want to secure configuration files, you can encrypt it which i believe not needed if the software development follows subversion workflows and other development practices.
Related
Every .NET project I've worked on uses an app.config file for its configuration. Fair enough.
Today I am asking, "is there a better way?" (in the spirit of continual learning of course)
I guess my specific questions are:
Does it matter either way if I use app.config or settings file?
Are there any scenarios where settings files should not be used e.g web sites where you should use a web.config instead?
Other than not having to edit xml, are there any other benefits gained by using settings instead of app.config, e.g. its easier to deploy or maintain apps etc.
Clarification:
I'll put this question another way:
Can I completely ignore app.config files if I want to and keep all the configuration in a settings.cs file and interact with configuration via the designer only?
IMO, the main advantage of settings files is scoping (for client apps at least) - that is, that you can have different values of the same setting for a different user. It also allows you to easily edit and save user-scoped settings. And yes, if you don't like editing XMLs - then settings have the advantage of a designer too :)
I don't think it really matters either way, as long as it works for you.
I wouldn't use settings files in situations where values are going to change after an application has been set up.
I tend to use a mixture of custom settings in the web.config and settings within a database.
Custom settings in the web.config are based on this here http://msdn.microsoft.com/en-us/library/2tw134k3.aspx These settings will be things that are not likely to change once the project has been set up, but allow for you to easily share class libraries with other projects.
The database settings are things that are likely to be updated at times during the project, e.g. email addresses
Im reading 2 books about WCf and one of them is showing Configuration as App.Config and the other is showing via Code in C#
I want to know which approach should i use and what are the benefits for each other.
Does the Wcf Configuration Wizard supports also the c# code behind configuration ?
thanks for the answers.
Configuration files can be changed without a rebuild (handy, say, to add a custom inspector or serializer), is pretty easy to copy/paste between client/server, has support from the IDE tooling.
Code is handy if you are configuring the system at runtime (i.e. getting the information from another server), or are running as a library (dll) and can't guarantee that a configuration file will a: exist, or b: have your configuration. Code also has intellisense / static checking to avoid brain-dead errors (typos in the xml etc).
I'd use a file until you know you have a scenario that doesn't work well with a file.
Also consider: how hard is it for you to deploy a code change vs a configuration change? for me they're about the same, but that might not be the case for you. Maybe it is easier to just change the config on the machines? maybe not.
I guess it depends on your needs. I personally tend to configure wcf with code, especially for things that are unlikely to ever change. That might include error handlers/logger, behaviors, authentication modules, service host factories, etc
For more dynamic stuff, like connection strings, passwords, file paths, etc are configured in .config files.
One of the biggest advantages of using code is that your code now can support things like IOC/Dependency injection, compile time checking, etc.
I don't buy into the idea that everything should be in a config file because it's easier to change it. In most cases I've seen it never changes in production.
The configuration file approach is better, it gives more flexibility. For example i change the authentication type (username password/windows) by changing config files.
I'm currently working on a Winforms app created by someone else. I've noticed that all the configurations are stored in the registy. This includes connection strings and so on.
Is this good or bad practice? If bad, then what is the better alternative?
A better option for you and the user is to use configuration files stored in the per-user application data directories. Look at the documentation for the System.Configuration namespace. Version 2.0 of the framework added a lot of functionality beyond the per-application config files.
I think a better option would be to store them in an app.config. This gives better visability and frankly is easier to change.
If you want to hide your app settings, most users aren't savvy enough to go hunting through the registry for keys relevant to an application. Also, as other answers have pointed out, back in the days before XML configuration file standards, the registry was the recommended place.
The recommended option is an XML config file nowadays; it won't add data to a file that's loaded at startup, meaning you're not contributing quite as much to the problem of a computer with a lot on it getting an inflated registry. It's more easily changeable (provided your user has admin access, and in any case, your program will need special permission to access the file to make programmatic changes).
If you kind of want to keep the data away from the casual user, a SQLite database is a relatively lightweight way to store small amounts of data, like user settings, in a manner that isn't easily changeable without access to SQLite. Just remember that if you can get in, so can others, no matter how hard that may be.
It's mostly an old practice from pre .NET days (VB6 comes to mind), when there were no standard configuration files and Microsoft recommended storing configuration in the registry.
These days, the registry is a good place to store information that is used by several applications, but if this is not the case, you should prefer the application configuration file.
Why is it better to store data inside an appSettings element (or inside a custom section) of a web.config file than to store it in a class?
One argument would be that by using custom sections we don’t have to recompile code when we change data, but that’s a weak argument, especially if we’re using Web Sites, which get recompiled automatically whenever code changes!
Thank you
Because you can change it on the fly and use it without regard to class structure. Your configuration can vary from each developers machine to staging to deployment environment by changing and maintaining a single file independently of the code, and you can take advantage of *.config masking with different areas of your site.
Hard coding anything configurable is a recipe for failure and it absolutely will bite you - this is just a matter of experience, if you don't believe it then you have but to wait a little while!
By putting settings into web.config, you have them all in a centralized location.
Also when deploying a web site, you might want to precompile it once. So you won't be able to change the source afterwards (without another recompilation).
It's not really a concern of just recompiling the code, it's more about re-deploying the code. Normally, you don't deploy code to the web server, you just deploy the binaries and aspx/html files. If you hard-code your config data in the code, you'll have to rebuild and redeploy the library or application to get the change up to the server, which is a lot more work than just updating the web.config.
Putting data in the web.config file also allows the same code to be run in different environments with different environment-dependent data. This can mean running the same website code in staging with a test database connection string and in the production environment with the production database connection string. Or it could mean allowing the developers to configure the data for their own tests without changing any code, as 'annakata' mentioned.
It's just a WHOLE lot easier to manage and update the settings.
If you're using Notepad to do your development and putting the code out on the server, I would agree that there is little benefit, but if you're using Visual Studio and you build your website and publish it, you're publishing the pre-compiled dlls and not just updating text source code (.cs or .vb files) on the server. So when it comes time to update a setting at that point, anything in the web.config can be updated by simply modifying the text file, where as with other changes, you have to re-compile t whole web site and publish it.
And from experience, that becomes tricky when taking over after other developers that weren't careful about ensuring everything needed to make a web site work is in source control. I'm now stuck with a web site where we can't update huge chunks of it because of (kindly putting it) non-standard practices in the past.
Being able to update something without re-publishing the site is a huge blessing in my situation, and you never know who the poor maintenance programmer will be that takes over on your code.
Be nice to him or her. Make it easy to make simple changes.
This question describes my problem exactly, except I'm using a custom configuration section in app.config with ConfigurationManager, so the solution presented there doesn't apply...
Basically, my problem is that when ClickOnce updates the application, it installs into a different directory with the new app.config, thereby erasing any changes made. My application uses app.config to persist application settings, so this is very bad... a merged update would be excellent (similar to what is achieved in the other question), but just about anything automated would be good at this point.
Or should I just use a set location for my app.config file rather than try to use the default location?
ClickOnce should maintain user settings between updates but I have had this fail once or twice for unkown reasons (and with bad results). I haven't tried a custom configuration setting but I've lost confidence in ClickOnce's ability to not overwrite settings.
The approach I'm planning to use is to manually handle ClickOnce updates rather than allowing the app. to check for updates and prompt the user to install. I've also had a couple of users who didn't accept the update and that's a pain to recover from. By manually handling the update, I hope to be able to read user settings into memory before updating, then write them back out after the update is completed. There's an ApplicationUpdated event that should serve this purpose.
Perhaps this approach could work for you as well.
Edited to add references:
How to: Check for Application Updates Programmatically Using the ClickOnce Deployment API
ApplicationSettingsBase.Upgrade Method
ApplicationDeployment Class
Googling for ApplicationDeployment should also help.