I'm really confused by the various configuration options for .Net configuration of dll's, ASP.net websites etc in .Net v2 - especially when considering the impact of a config file at the UI / end-user end of the chain.
So, for example, some of the applications I work with use settings which we access with:
string blah = AppLib.Properties.Settings.Default.TemplatePath;
Now, this option seems cool because the members are stongly typed, and I won't be able to type in a property name that doesn't exist in the Visual Studio 2005 IDE. We end up with lines like this in the App.Config of a command-line executable project:
<connectionStrings>
<add name="AppConnectionString" connectionString="XXXX" />
<add name="AppLib.Properties.Settings.AppConnectionString" connectionString="XXXX" />
</connectionStrings>
(If we don't have the second setting, someone releasing a debug dll to the live box could have built with the debug connection string embedded in it - eek)
We also have settings accessed like this:
string blah = System.Configuration.ConfigurationManager.AppSettings["TemplatePath_PDF"];
Now, these seem cool because we can access the setting from the dll code, or the exe / aspx code, and all we need in the Web or App.config is:
<appSettings>
<add key="TemplatePath_PDF" value="xxx"/>
</appSettings>
However, the value of course may not be set in the config files, or the string name may be mistyped, and so we have a different set of problems.
So... if my understanding is correct, the former methods give strong typing but bad sharing of values between the dll and other projects. The latter provides better sharing, but weaker typing.
I feel like I must be missing something. For the moment, I'm not even concerned with the application being able to write-back values to the configuration files, encryption or anything like that. Also, I had decided that the best way to store any non-connection strings was in the DB... and then the very next thing that I have to do is store phone numbers to text people in case of DB connection issues, so they must be stored outside the DB!
If you use the settings tab in VS 2005+, you can add strongly typed settings and get intellisense, such as in your first example.
string phoneNum = Properties.Settings.Default.EmergencyPhoneNumber;
This is physically stored in App.Config.
You could still use the config file's appSettings element, or even roll your own ConfigurationElementCollection, ConfigurationElement, and ConfigurationSection subclasses.
As to where to store your settings, database or config file, in the case of non-connection strings: It depends on your application architecture. If you've got an application server that is shared by all the clients, use the aforementioned method, in App.Config on the app server. Otherwise, you may have to use a database. Placing it in the App.Config on each client will cause versioning/deployment headaches.
Nij, our difference in thinking comes from our different perspectives. I'm thinking about developing enterprise apps that predominantly use WinForms clients. In this instance the business logic is contained on an application server. Each client would need to know the phone number to dial, but placing it in the App.config of each client poses a problem if that phone number changes. In that case it seems obvious to store application configuration information (or application wide settings) in a database and have each client read the settings from there.
The other, .NET way, (I make the distinction because we have, in the pre .NET days, stored application settings in DB tables) is to store application settings in the app.config file and access via way of the generated Settings class.
I digress. Your situation sounds different. If all different apps are on the same server, you could place the settings in a web.config at a higher level. However if they are not, you could also have a seperate "configuration service" that all three applications talk to get their shared settings. At least in this solution you're not replicating the code in three places, raising the potential of maintenance problems when adding settings. Sounds a bit over engineered though.
My personal preference is to use strong typed settings. I actually generate my own strongly typed settings class based on what it's my settings table in the database. That way I can have the best of both worlds. Intellisense to my settings and settings stored in the db (note: that's in the case where there's no app server).
I'm interested in learning other peoples strategies for this too :)
I think your confusion comes from the fact that it looks like your first example is a home-brewed library, not part of .NET.
The configurationmanager example is an example of built-in functionality.
I support Rob Grays answer, but wanted to add to it slightly. This may be overly obvious, but if you are using multiple clients, the app.config should store all settings that are installation specific and the database should store pretty much everything else.
Single client (or server) apps are somewhat different. Here it is more personal choice really. A noticable exception would be if the setting is the ID of a record in the database, in which case I would always store the setting in the database with a foreign key to ensure the reference doesn't get deleted.
Yes - I think I / we are in the headache situation Rob descibes - we have something like 5 or 6 different web-sites and applications across three independent servers that need to access the same DB. As things stand, each one has its own Web or App.config with the settings described setting and / or overriding settings in our main DB-access dll library.
Rob - when you say application server, I'm not sure what you mean? The nearest thing I can think is that we could at least share some settings between sites on the same machine by putting them in a web.config higher in the directory hierarchy... but this too is not something I've been able to investigate... having thought it more important to understand which of the strong or weak-typed routes is 'better'.
Related
As I transfer my application in C#.net from one computer to another, I have to change the connection string every time as the location of the Database file has changed.
How can I can I prevent this,so that I don't have to change the connection string again and again?
When location of the database changes, something has to change somewhere. Back in the ODBC days, you could define a system-wide connection and specify the just the name in the connection string. But if the server moves you would have to change the ODBC anyway.
I can think of a few solutions here. One is that if your database runs on the local machine, use the localhost instead of the machine name.
In case it is a file, create a network share and put it on that so that you use \\localhost\shareName\file.db.
If it is a server database and could be on other machines, use a DNS name by using a host file and assign a common name so that you could do that in different networks.
This one is an old one that comes up from time to time.
Visual Studio has the ability to support multiple build environments and will allow you to specify environment specific values (i.e. databse connection strings) so that you may test wherever you want.
Pulled this from the Gu's blog and full post may be seen here:
It turns out you can easily automate this configuration process within the Visual Studio build environment (and do so in a way that works both within the IDE, as well as with command-line/automated builds). Below are the high-level steps you take to do this. They work with both VS 2005 and VS 2008.
Use ASP.NET Web Application Projects (which have MSBuild based project files)
Open the VS Configuration Manager and create new "Dev", "QA", "Staging" build configurations for your project and solution
Add new "web.config.dev", "web.config.qa", and "web.config.staging" files in your project and customize them to contain the app's mode specific configuration settings
Add a new "pre-build event" command to your project file that can automatically copy over the web.config file in your project with the appropriate mode specific version each time you build the project (for example: if your solution was in the "Dev" configuration, it would copy the web.config.dev settings to the main web.config file).
In VS 2010 I believe most of the setup for this is done for you when you make your new application, but the principles are still the same. You can skip the pre-build event in favor of pulling the connection string in via code if you're comfortable with that way of doing things. There is an example of this on StackOverflow here on this answered question
The start of the answer (or at least how I'm more likely to implement this) is to store each connection string value in a separate connections.config file with a name unique to the environment. This will only contain the values from connectionStrings portion of the web.config file. I like doing this because it means adding a new environment doesn't mean a developer touching the main web.config file and you can also do some server-side trickery to remove the database connection strings from the site's webroot making it a bit more secure.
Method for removing the connectionStrings to another fole may be seen here: http://www.bigresource.com/Tracker/Track-ms_sql-cberGbNT/
I would also look into having a network accessible version of the database instead of making each developer have one in their environment. If you have to have disconnected work being done that makes sense, but from a management standpoint there should really only be one database for each stage of the project (Development, Staging, and Production).
Hope that's helpful, and feel free to ask follow-up questions on anything that doesn't make sense.
Use a relative path. For most scenarios, you can just use the built-in |DataDirectory|, which translates to the base directory you're running from (or App_Data in ASP.NET scenarios).
If you are using a client-server database, like SQL Express, then you should also set the server name to something like .\SQLEXPRESS - which will use the local instance.
what I usually do is having a configFile.txt that can be modified.
I can easily read it from the program and since it's path is fixed (relative path), I don't need to change the code anymore.
I don't know if this is a good or bad habit but it works fine.
Here it takes the first line :
public string pathConfig = "../../myProject/configFile.txt";
string yourDBPath = File.ReadLines(pathConfig).Skip(0).Take(1).Split(':')[3];
I am creating an app that reads some info from a scale via RS232 serial port connection. There are a couple of types of scales that are in use, so I would like to store specific settings for the scale in my program. What is the best way to do this? Via app.config? Or should I put the values in a database?
It really depends on where will these configurations be used?
If you are working on a distributed huge system, which means these configurations are probably shared/used by other systems. You'd better store it in the database, with a common protocol which other related systems agree with.
On the other hand, if these configurations are used for a small application, storing them in a config file(or an xml file whatever you like) is suggested because, you don't need a gun in order to kill a mosquito.
app.config would be the easiest option for you. I think a database might be a bit overdoing it for just some settings, but if you wish to use something outside of what is offered by VS (namely app.config) then you could always whip up a quick custom XML settings file. All depends on what you wanna do with it and how comfortable you are with the other technology.
Is the information chaging ? that means when you ran ur app , would it be the case that information is updated ?
if the information is static and do not change frequetly , you can store in the app.config.
or in a xml file and you can read that information lately.
but if the information is dynamic then you need to create a model and expose scale information through model's peroperty.
Do not forget the registry.
Use the registry when:
You need your settings to be accessible for a domain admin
you need to secure some settings (using Windows security)
(You can make some settings read-only)
There are a lot of small settings that change very often
If it's simple and straightforward than app.config is the way to go - you don't need to set up a database and you get to use simple built-in interfaces.
If you choose to go with a database check out mysql for a simple file based database that has a simple deployment scheme.
I have a Windows Service written in C# (.Net 3.5) and I need to store some state somewhere so that next time the service starts up, it knows where it left off.
What is the recommended store for this type of thing? The registry? What if I just put some user settings in a Settings.settings file? Where would the user profile be for a service executing as LocalSystem or NetworkService?
Personally, I prefer the registry for server state storage, provided it isn't a large amount of information.
If you're storing a large amount of information, a local database is another option. Services have the advantage of running under elevated privelidges, so you can typically use local file storage, as well.
If it's a small, fairly simple chunk of data, you can create an XML serializable class and very easily write it to disk on shutdown and read it back on startup. For a simple enough class, you can just add the [Serializable] attribute, and the XmlSerializer will automatically know how to serialize/deserialize it.
If you have enough data that a SQL database would be a better fit, look into SQL Server Compact Edition or the System.Data.SQLite binding for SQLite.
Both will let you create a database as a single file, without having to install any extra Windows services or configure anything. System.Data.SQLite doesn't even need to be installed - it's contained entirely with the .dll that your project references.
In either case, the best location for the file is probably SpecialFolder.CommonApplicationData - I think this ends up being C:\ProgramData\ on Vista, but avoids having to hardcode the exact path.
I would go with a .settings file, since its properties are type safe. This is of course assuming that the service is not going to store a large amount of information. Does it really matter where the system chooses to store the settings file?
I hate to say this, but the best answer is that it depends. Without knowing the purpose of your service, a correct answer can't be given. Having said that... the world is your oyster, so to speak.
I've noticed that when using the Settings object that's created by a Windows Forms application, any spaces in the "Company Name" field of the assembly info are replaced by underscores in the path of the user.config file. For example, in XP the path to the user.config file will be something like:
\Documents and Settings\user\Local Settings\Application Data\Company_Name_Here\App\Version\user.config
But this only seems to be happening to my own applications. I've got lots of .NET applications installed on my machine, but none of the other directory names under Application Data contain underscores (the spaces are preserved).
What gives? It's not a big deal, but I'm just wondering why this only seems to be happening to my applications, and if there's a way to change this behavior that I'm not aware of.
Quoting someone who worked at Microsoft
<Company Name> - is typically the string specified by the AssemblyCompanyAttribute (with the caveat that the string is escaped and truncated as necessary, and if not specified on the assembly, we have a fallback procedure).
and
Q: Why is the path so obscure? Is there any way to change/customize it?
A: The path construction algorithm has to meet certain rigorous requirements in terms of security, isolation and robustness. While we tried to make the path as easily discoverable as possible by making use of friendly, application supplied strings, it is not possible to keep the path totally simple without running into issues like collisions with other apps, spoofing etc.
The LocalFileSettingsProvider does not provide a way to change the files in which settings are stored. Note that the provider itself doesn't determine the config file locations in the first place - it is the configuration system. If you need to store the settings in a different location for some reason, the recommended way is to write your own SettingsProvider. This is fairly simple to implement and you can find samples in the .NET 2.0 SDK that show how to do this. Keep in mind however that you may run into the same isolation issues mentioned above .
might give some hint of explanation.
So other applications might have used an individual settings provider that supports whitespaces.
The restrictions of the default .NET settings provider are also mentioned here:
Each application setting must have a unique name; the name can be any combination of letters, numbers, or an underscore that does not start with a number, and cannot contain spaces. The name can be changed through the Name property.
The way I currently handle this is by having multiple config files such as:
web.config
web.Prod.config
web.QA.config
web.Dev.config
When the project gets deployed to the different environments I just rename the corresponding file with the correct settings.
Anyone have suggestions on how to handle this better?
EDIT:
Here are some of the things that change in each config:
WCF Client Endpoint urls and security
Custom Database configs
Session connection strings
log4net settings
Scott Gu had an article on this once. The solution he presented was to use a Pre-build event to copy the correct config into place depending on the build configuration chosen.
I also noticed that there already is a similar question here on SO.
Transforms seem really helpful for this. You can replace certain sections with different rules.
http://msdn.microsoft.com/en-us/library/dd465318(v=vs.100).aspx
The way we've been doing it is to override the AppSettings section:
<appSettings file="../AppSettingsOverride.config">
<add key="key" value="override" />
...
</appSettings>
This only works for the appSettings section and so is only useful to a degree. I'd be very interested in more robust solutions.
Edit Below
Just watched this:
http://channel9.msdn.com/shows/10-4/10-4-Episode-10-Making-Web-Deployment-Easier/
VS2010 has config transforms which look pretty awesome, should make multiple configurations a complete breeze.
In Visual Studio, I create xcopy build events and I store all the config files in a /config folder. You only need one event for all configurations if you name your files after the build configuration: i.e. overwriting web.config with /config/web.$(Configuration).config
My favorite way to tackle this is with the configSource attribute. Admittedly I only use this on one element (<connectionStrings>) but it does provide an easy way to swap in and out different segments of a web.config (which I do during install time via a WebSetup project).
I also use the web.DEV.config, web.TEST.config, web.PROD.config etc.
I find this way the most easiest, simplest and straight-forward way if your projects are not complex. I don't like making things more complicated than neccessary.
However, I have used NAnt and I think it works well for this. You can set up builds for your different environments. NAnt takes some reading to learn how to use it but it's pretty flexible.
https://web.archive.org/web/20210513225023/http://aspnet.4guysfromrolla.com/articles/120104-1.aspx
http://nant.sourceforge.net/
I used it along with CruiseControl.net and NUnit to perform automatic daily builds with unit test validation and thought they worked well together.
It really depends on what the difference is between the environments that is causing you to use different web.config files. Can you give more information as to why each environment currently needs a different one?
We have a few workarounds (not all of them are done with web.config but the same idea)
We include multiple configuration files in the packaged deployment. During installation we specify environment that we are installing on.
Migrate all environment specific settings to the Database server for that environment. WebServer provides its environment when requesting server name
Provide multiple settings (1 per environment) and using code request different settings.
Combination of 2 and 3 (Override a part of the settings based on the environment - for example application server name)
Through most different version management software (subversion, git, etc) you can ignore specific files.
Thus, in subversion, I'd have:
configure.template.php - This file is versioned and contains templated configuration data, such as empty DSN's
configure.php - This file is ignored, so that changes to it do not get tracked.
In subversion, the way to do this is:
svn pe svn:ignore .
It'll open your editor, then you type
configure.php
Save, exit, checkin your changes, and you're good to go.