I'm building out my application and I'm at a point where I've hardcoded a lot of settings at the top of my class files - stuff like ApiSid and ApiKey, SmtpServiceUsername, MyEmailPassword etc. I'm now trying to consolidate these and I see two options:
1) Push them all into web.config. I don't like the thought of muddling up my web.config with tens (almost 100) settings though... I also feel uncomfortable with security here.
2) Build a static class that just contains these settings (Settings.cs) - basically housing a bunch of constants that are referenced throughout the app.
I feel more comfortable with the second approach because I can keep my settings totally isolated and not worry about exposing them via web.config - is there anything inherently wrong with this approach?
is there anything inherently wrong with this approach?
What makes you think putting constants in the code is any more secure than in the config? The compiled DLLs are right there next to the Web.Config, if somebody can examine one of them they can examine the other one. Hard-coded values can be de-compiled pretty easily.
Config files exist for a reason. Specifically, if any value is going to change per environment then it belongs in the config file. That way the same identical codebase can be used in any environment (development, test, production, etc.) and you'd just edit the config values for that environment. Having to re-compile the code just to deploy the same version to a new environment is less than ideal, since it's no longer the same version.
I don't like the thought of muddling up my web.config with tens (almost 100) settings though
Why not? If they're all flat static values, a list of appSettings keys would be fine. If there's more structure to them, create custom config sections.
This is not necessarily the best approach but I'd store these kind of settings in the database. This gives you database security for the settings plus it's easy to update the settings without having to stop / restart the application so you avoid kicking out users.
Once you have your settings in the database, you can load them periodically (like every 15-20 minutes) to detect changes. In the meantime, create a dictionary of the data and either wrap it in a class that provides type-safe access through properties or just use the dictionary directly. Since this is web application, you'll have to use a thread-safe class (like ConcurrentDictionary) to make sure multiple threads can safely access your settings.
If you have so many settings, web.config would be cluttered and every change would force an app pool restart. As #David mentions in his answer, the config file gives you an easy way to have different settings for different environments but this is also easy to do with a database approach where settings may be present once per environment.
Related
I'm wondering if Application Settings are reliable for storing values?
I was thinking of storing my application's XML file path in there so when I run the program, it knows where the XML file is located even if the path was changed during last runtime.
Is there a chance that Application Settings could forget/dispose the file path value? Or maybe anything else related to that?
Are there better ways to accomplish my goal?
Yes, they are reliable. And they will do it very well because they will take under consideration OS-specific conventions and OS user profiles. So, I'd say it's a recommended practice.
There is a small catch: A later version of your application may look for settings for its own version, even if settings for an older version exist. In that case, you'll have to make sure that your app migrates the old settings and converts them to its own, instead of ignoring them. It's quite easy.
There is a bigger catch: Moving the app to another place in the disk will cause it to consider itself a new instance and make its own settings. If you want to avoid this behavior, you'll have to consider making a strongly named assembly (which I find inconvenient, to say the least).
As previously mentioned, yes Application Settings is reliable and well explained by Chatzigiannak. However, I want to share with you some considerations regarding to app settings that happened here.
We are currently using an external file and we load it in the web.config. Pretty simple:
<appSettings file="DIR\Configuration\AppSettings.config"></appSettings>
This code is spread out in our 15 web sites. The file is something like this:
<?xml version="1.0"?>
<appSettings>
<add key="CacheEnabled" value="0"/>
...
</appSettings>
Then we realized that this file was growing and now it has 600 keys, cool isn't it? But this is not the worst part, each server has to have it's own configuration, so we spread this file through 7 servers... And some of them have different keys... Imagine that you have to change the path of one specific key, in all servers... We created a monster =)
Doing a code review we decided to store it in the database. A simple table with the machine IP as key and a key value JSON as the document. Not 600 columns of course.
When I told to my team I was doing that, one guy said: "Are you crazy? You will have to change 1k of this code":
ConfigurationManager.AppSettings["KEYNAME"];
Indeed yes I had to change it, but I thought in a simple way, creating my own ConfigurationManager that has a NameValueCollection AppSettings inside:
public static class ScopeManager
{
private static NameValueCollection _appSettings;
public static NameValueCollection AppSettings
{
get
{
if (_appSettings.IsNull())
{
//GET FROM DATABASE, CACHE OR SOMEWHERE ELSE
}
return _appSettings;
}
}
}
And the changes became:
ScopeManager.AppSettings["KEYNAME"];
I don't think we had reinvented the wheel. But we've done a way much better to deal with lots of keys/websites/servers... Seems more real world.
In my IIS I want to be able to load some variables from an external file.
Reading them from the web.config is a possibility but if I will want to update the variable without restarting, it will require me to edit all the web.config files in the cloud.
Reading them from a centralized db is also an option but some of my apps dont require a connection.
What is a recommended way to manage application variables for IIS.
Thanks.
The recommended way is a Web.config file, that's why there is a built-in appSettings section. Now, as far as updating variables without restarting, you wouldn't have to edit them in the cloud at all. Have a copy of those Web.config files locally, in a testing environment that's like PROD, and then update them there first. Then you can test those changes and upload the entire Web.config file which will cause the application pool to reset automatically.
EDIT
With more information now available because of the OP's comments -another good solution may be to leverage the machine.config instead of the web.config for those settings that needs to be changed across multiple websites on the same server, especially if it's time sensitive that the applications see the change.
Since you don't want to have an application restart (which both web.config and machine.config will do), I would recommend keeping it to custom settings object that can be responsible for updating itself independently. Consider a serializable object with settings that appear in a NameValueCollection (similar to a web.config or app.config file). This would allow you to add settings similarly. Some steps to consider:
Add a shared directory to a common network location so that you only have 1 copy of the file itself for all websites. Something like \\somecommonserver\shared\configuration\.
Add a static application variable to the code base so that each application pool will have a record of the last date/time the file was updated --> Application["CustomConfigLastUpdate"] = configFileInfo.LastWriteTimeUtc; (I recommend using UTC because servers time may differ, but UTC does not)
Each time the settings are accessed may be a bit too heavy, but at some determined interval (each access, every 5/15/60 minutes, whatever) check if the configFileInfo.LastWriteTimeUtc property is greater than what is stored in the application variable, then you need to go get a fresh copy of the settings.
Create your custom object with the [Serializable] attribute and provide it a LoadFromXmlFile method that receives a filename as an argument whose responsibility is to repopulate itself.
I have done this before to achieve a similar goal, but I do not have those code samples here at my office. Here is a good SO question that has a relevant answer with code describing similar behavior: How to Deserialize XML document
I'm using C# .NET.
In my software I'm providing settings dialog through which user can set the application settings which I want to save to a file.
Requirements (typical):
Every class I defined uses some part of these settings. So, these should be global to all classes.
These should be loaded while software is started.
When ever user changes settings and clicks 'save'/'apply'. Current settings should change.
I am wondering what is the best way to do this? Also, what is the best way to save these settings to disk? I mean should I create a Settings class object and serializing it to 'settings.dat' or provide an structured file like XML/JSON
This is required for almost every other software. So, isn't there any design pattern for this?
EDIT:
Well, thats something that I didn't know. Its nice :). But say while user is using the software in the middle he changes the settings then all the other objects that are using these global Properties.Settings.Default.* should be changed. Is there any kind of notification mechanism? Some kind of event?
.Net projects already have the notion of Settings, scoped to either the user or the application, that will meet all of your requirements above. There are classes to read and write the settings. I would highly recommend that you look at these instead of rolling something up yourself.
Using Settings in C#
You can use Settings in a variety of project types, although in certain types of projects like ASP.Net projects, User-level settings may not be available.
The Settings class that comes with .Net is very handy, and I use it for most of my projects. The one gotcha to watch out for is that every new version of the application gets its own settings file, so make sure you have sensable defaults. All the settings will disappear whenever a new EXE is distributed.
Global state is very hard to deal with correctly, so I usually pass the relevant settings to the various objects in their constructors, or in properties. And I usually don't apply settings changes to those objects, since, in many cases, it's very hard for an object to deal with a changing setting intelligently. Rather, I just use the new settings for the new objects as they are created. If a setting needs to be applied immediately, then I just dump the old object and create a new one. It just depends on the details of the application.
If you have an Apply button on your settings screen, then I would recommend reloading and displaying all of the values after saving them. This way the display is sure to contain exactly what is actually saved. This could be important if any settings are parsed. I've had users enter a month and day combination into a particular field, and the format they used was different from what was expected, so the value saved was incorrect. By updating the screen after the Apply, these sorts of errors can be made obvious.
I hope this helps!
You and womp are both right:
You should create a Settings class that is a Facade over the .NET settings. That way you get the best of both worlds: the testability of a hand-rolled solution and the ease of implementation typically associated with Microsoft Silver Bullets.
I personally would go the Properties.Settings route. Add a Settings file to the Properties folder of your app. This lets you easily add items to the app.config file of your application. There is a built in .net class that you can use to read/write values found in the Settings file. You can then write a small wrapper class that encapsulates that functionality or simply use the built in .net one all over the place.
I personally would create a threadsafe Singleton class that uses the small wrapper class over the built in .net one. Yes it's some extra work but it's a small amount and gives you some great power in your app for the little bit of work.
Edit: Sorry forgot to include the MSDN settings link.
http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx
As others have suggested using the Settings feature is the way to go. Settings also provide events when the they are updated so you can handle them and take necessary actions. You can also use the Upgrade method to move the settings from previous version into the newer one. Just make sure that you call it only once (probably from the installer).
Settings can also be bounded to the controls so you will not have to map them manually from controls to settings.
I am looking at ways to make our application more extensible and easier to manipulate without having to alter the web.config (or, in our case, application.config files, which contain the appsettings node).
One way I have thought about is keeping the app settings in the database table that has a sqlcachedependancy. This means that:
Any time a setting is changed in the database, the cache is invalidated, and the settings are retrieved again, thus updating the application in realtime without having to alter files and restart the entire app.
We can create a custom tool which allows us to alter the settings.
The cons as I see it are that this may cause serious logic problems in that, if you have something that checks an appsetting at the start of a process, and it then changes halfway through, you could end up unintentionally altering the process flow, as the requirement for a complete application restart is negated.
Is there a way round this?
Is there a better way to manage appsettings, so that you can alter them on the fly remotely for one, several, or all servers in one go?
I think you've nailed the two major players:
either you have access to the file system and you put all your settings in a plethora of *.config files there
OR:
you don't have access (or only very limited access) to the server's file system and thus you're probably better off putting config settings and user preferences in a database, basically leaving nothing but the connection string to the config file on disk
Both approaches have their pros and cons. I've been trying for a long time to find a way to "materialize" a config section from a database field, so that I could basically just use the config XML, but stored in a database field. Unfortunately, the entire .NET 2.0 config system is very much "locked down" and just only assumes data will come from files - there's no way to plug in e.g. a database provider to allow the config system to read its contents from a database field :-( Really too bad!
The only other approach I've seen is a "ConfigurationService" in the StockTrader 2.0 sample app provided by Microsoft, but for my needs, it felt like overkill and like a really complex, really heavy-weight subsystem.
You could use SQLite, which will be a self-contained DB in a single file. Two birds with one stone?
If you reference an external config file that contains appsettings (leaving everything else in the normal app.config) then I believe editing it only reloads those settings, it doesn't force the whole app to restart.
There's a similar question on the subject here:
Nested app.config (web.config) files
WRT the problem of values changing in the middle of program execution, I guess you could locally cache the values, and raise an event when they change, allowing routines to reach a suitable point before using the updated values.
I think in asp.net we sort of get this for free because each page lifecyle is distinct, so the value is simply applied to new page requests only, not in the middle of an execution.
Edit: A little extra info:
Configuration Changes Cause a Restart of the Application Domain
From MSDN:
Changes to configuration settings in Web.config files indirectly cause the application domain to restart. This behavior occurs by design. You can optionally use the configSource attribute to reference external configuration files that do not cause a restart when a change is made. For more information, see configSource in General Attributes Inherited by Section Elements.
More information on the ConfigurationManager class in the System.Configuration namespace which could be used to modify the config files programatically (ie in a custom tool, if relevant disk read permissions can be provided). If you stick to using the built in configuration classes, I think changing the external configs, would not cause application restart, but would raise events (such as property changed) which you could handle, to ensure your code is not caught out by changing settings.
Is there a way at runtime to switch out an applications app.config (current.config to new.config, file for file). I have a backup/restore process which needs to replace its own application.exe.config file. I have seen this post but it does not answer how to do this at runtime.
Turns out I can swap the .config file for the new one and do a ConfigurationManager.RefreshSection(...) for each section. It will update from the new .config file.
Microsoft .NET's app.config is not designed for your scenario, as well as many others. I often encounter a similar need, so I have spent a lot of effort designing a solution.
Redesign to use app.config only as a configuration bootstrap: specify where to find the rest of the real configuration data. This information should almost never change, so there is no need to handle file watching or application restarts.
Pick an alternate location for the real configuration data: a file, a database, perhaps even a web service. I prefer a database most of the time, so I create a configuration table with a simple structure that allows me to store my data.
Implement a simple library to wrap your configuration access so that you have a simple API for the rest of your application (via dependency injection). Hide the usage of app.config as well as your real configuration storage location(s). Since .NET is strongly-typed, make the configuration settings so--convert each string retrieved into the most-specific type available (URL, Int32, FileInfo, etc.).
Determine which configuration settings can be safely changed at runtime versus those that can't. Typically, some settings need to change along with others, or it simply makes no sense to allow them to change at all. If all your configuration data can safely change at runtime, then that makes things easy, but I HIGHLY doubt such a scenario. Hide the changeability and interdependencies of the configuration settings to the extent possible.
Design the response to the unavailability of your real configuration data. I prefer to treat the absence of any configuration setting as a fatal error that aborts the application, unless I can identify a usable default. Likewise, I abort in the absence of the configuration storage container (file, database table, etc.).
Enjoy, and best wishes.
Are you able to restart the application when you detect that you need to switch files? If so, it's just a matter of switching the files and restarting. Now, the tricky bit is if .NET keeps the app.config file open while the program is running. I suspect it doesn't, but if the most obviously approach fails, I suggest you have a second application (cfgswitcher.exe) which waits for the process with a PID specified on the command line to terminate, then switches config files and relaunches the original process. Then your app would just need to launch cfgswitcher.exe (passing in its own PID as a command line argument) and terminate.
As I say though, it's worth trying the more obvious approach first.
EDIT: If you can't restart the application (or even part of it in a new AppDomain) then various aspects of app.config (assembly bindings etc) can't be changed. If you're only interested in your own configuration sections changing, then I suggest you store them in a separate config file and reload them whenever you want to.
Look at the events available to you on the ApplicationSettingsBase class. There are PropertyChanged & SettingChanging that may give you what you need.
You could also watch the file and if it has changed call the reload method to get the new settings.
I don't think it is possible at all to switch the configuration at runtime without restarting, so if you can't apply Jon's approach, you should try to come up with an other approach.
Anyway, maybe it's just me not having enough information about your scenario, but this kind of feels fishy.
Are you sure that swapping the configuration file is the best way to achieve whatever requirement you need to meet? I mean, this is quite an uncommon thing. If I were you, I would try to come up with some other approach.