Where to hold config files

Question

I created a new C# Project (non-web) for our PayPal implementation. I have a bunch of config strings such as the following that I need to figure out the best way to store. Various wrapper classes that I created are using these strings. Also, this is a project that can be used in any web project or even back-end. So I need a nice way to sore these so that the other applications don't need to, and centralized all these string keys in my PayPal C# Project to maintain them there. The other apps using my wrapper project should know nothing about these strings or need to...my project takes care of storing them.

With that, where? Do I use a Web.Config in my C# non-web Project? Do I use an App config? Do I store them in the DB (no, bad idea). OR do I store them as constants in for example a Constants.cs class?

I also don't know if storing them in a Constants class is safe? Seems to me my best options here are add a web.config or some kind of config to my non-web project and just store them there.

Answer 1

The "standard" .NET way to do this is to create an app.config and place them there. These will need to be copied into the web.config or app.config of any project calling the library project you're writing.

Answer 2

Just use the .NET configuration system (System.Configuration) and don't worry about where the configuration settings are stored.

If your code is used from a non-web application, these setting can be configured in the application's .config file. A web application would use web.config.

Despite dissimilar names, app.config and web.config use the same API.

Answer 3

Your configuration will depend on your overall architecture. If your consuming applications are expected to know nothing specific about the settings, then it might be best to create a class that is responsible for retrieving these settings and outputting them as explicit properties. It is probably always best to put them in some version of a web.config because this allows you to modify them without having to recompile and redeploy your application. You may also have considerations of any source control or managing different levels of configuration (development, test, production, preproduction, et al).

I employed a web.config method that creates my own config sections and connection string sections based on the level or type of server that is accessing it. I then constructed my own "ConfigurationManager" class that accesses them in a manner nearly identical to the built in ConfigurationManager (so its usage would be transparent to other developers). Then my web.config can have any settings in it and the class itself can be used identically across the enterprise in a manner consistent with ASP.Net configuration standards. Anyone needing a setting would call the myConfigurationManager.AppSettings(key) and receive the appropriate setting based on the level of the server in question, and the source control for the configuration file would not have to be different between servers.

Similarly an app.config can be configured in this way to provide extended configuration support.

Answer 4

We did a PayPal implementation a while ago. What we ended up doing is storing these sensitive strings as encrypted strings in web.config. I think for your scenario you might consider doing something similar (storing as encrypted strings in web.config), but centralizing it by wrapping it with an intranet only web service and only giving access to one domain account. This ensures no one except the one domain account can call the webservice to get the credential or other PayPal specific objects.

Answer 5

You could just make a simple class that holds them, xmlSerialize the class to wherever you want to be read back into the same class by your other apps.

Answer 6

If the strings are determined at compile time and never change, use a resources file.

If they need persistent storage, you can also use the system registry - I am dabbling in this myself, also using resource files to reduce critical typos:

// Get key
RegistryKey appKey = Registry.CurrentUser.CreateSubKey(Resources.keyAppPath);

// Read from key
string _configStr = (string)appKey.GetValue(Resources.keyConfigStr, string.Empty);

// Write to key
appKey.SetValue(Resources.keyConfigStr, _configStr);

Resources.keyAppPath is like "Software\[Company]\[App]"

Resources.keyConfigStr is the name of the key.

As others have mentioned, add a layer of encryption if security is an issue with the particular data!