I'm trying to use application settings with a C#.NET project I am working on. But I can't seem to get it to return anything other then the default values. Through the project properties I've added a single setting, DBConnectionString, and set its value to a connection string I want to use. Its scope is set to "application".
Doing this created a number of files including Settings.settings, Settings.Designer.CS, and app.conifg. From what I understand the two Settings.* files define a custom Settings class that derives from ApplicationSettingsBase. The Settings class then has custom, type safe, properties that can be used to set and retrieve each setting. The app.config file is a XML file that stores the actual settings values.
When I build my project it looks like the app.config file is copied to the target directory as MyApplication.dll.config. My program runs fine and is able to use the default connection string.
Next I tried to edit the MyApplicaiton.dll.config file to change the connection string. I ran my program again, but it continued to use the default value. I noticed that in my Settings.Designer file there is a DefaultSettingValueAttribute with the original default string. I tried removing this attribute, but then when I tried to retrieve the connection string setting it just returned null.
This is the code I'm using to read the connection string.
string conn = Properties.Settings.Default.DbConnectionString
What am I doing wrong? How can I get it to return the value in the settings file and not the default value?
Update:
Sorry I should have mentioned this. I'm actually writing a plug-in for another application through a public API. So my project is a DLL not an EXE.
You cannot read settings from *.dll.config files. If you library needs any special settings you need to put them in your app.config or web.config files.
EDIT: You can include the external config files in the main application or web config file. Look here for details.
This question discusses how to manage configuration files for large projects.
Settings files and .config files are different things (I do not know why VS automatically added a .config when you created a Settings file). But, the settings file is compiled into a class and is referenced like you said. If you decompile the dll with .NET reflector the Settings class will be in there. It is used for holding constant values or external resources. For example: error message strings, icons, or images.
The config file is for settings which can change frequently or between environments (dev, test, prod). For a connection string you should use the <connectionStrings> section of the config file. And the property can be referenced using System.Configuration.ConfigurationManager[ "connectionStringName" ].
However, from your original post it looks like your .dll is going to be used in a larger project (either an .exe of web project). One thing to note is that all projects only use one .config file. And that is the config file for the main project. Websites the web.config file, and exe's use XXX.XXX.XXX.exe.config (as you saw, *.exe.config files are renamed copies of the app.config files). dll's do not have usable config files. All dll's will look at the main project's .config file to retrieve information.
If your connection string is never going to change then by all means use the Settings file. Otherwise, use a config file and let the developer of the main project determine what to populate the connection string with.
Related
I'm trying to understand Application Settings / AppSettings.
My understanding is that AppSettings (which are within the app.config file) are accessed via ConfigurationManager.AppSettings, and this is considered deprecated functionality.
I understand Application Settings are accessed via Properties.Settings.Default, and are usually created as .settings files (in Visual Studio this can be done in Project Properties).
If this is correct (please confirm), my question is why do all projects in Visual Studio automatically create an App.config file? Can / should I delete this file and create a Settings.settings file instead? Should I use both? (why?) Can I access the app.config file using Properties.Settings? If so, how?
Also, if Properties.Settings.Default accesses the "default" settings file, how / why would you access a file other than the default one?
Edit: This question is not answered by the AppSettings vs Application Settings threads, because my specific question is why I need an App.Config file.
ApplicationSettings are preferred over AppSettings as they are strongly typed, but there are times (such as in Azure) where AppSettings are preferred as they can be set from the Azure control panel on an instance by instance basis.
That said, let's look at the other part of your question relating to Settings.Default vs. App.Config.
I would not remove the App.Config from every project, as it gets automatically updated when you update your settings. The settings file has the default values in code, but the App.Config file can override those at runtime. This is nice to be able to copy the relevant sections to new applications (into their app.config or web.config) that are going to consume a library.
The only app.config file from your projects that gets executed is the startup project, and the values in that app.config (or web.config as it may be) are the ones used at runtime.
Hopefully this clears up some confusion around the relationship of the files.
Sample Structure of Configuration Files:
ProjectA
- ProjectA.Settings
- App.Config // VS syncs with Settings file
ProjectB
- ProjectB.Settings
- App.Config // VS syncs with Settings file
ProjectC (Startup Project
- ProjectC.Settings
- App.Config
// Can contain override settings for ProjectA.Settings and ProjectB.Settings
In several C# projects I have been using an app.config file to pass various settings to my program, settings like connectionstrings, power levels etc.
However sometimes I have come in situations where the settings aren't updated as expected and I have concluded that I am not that well informed with the proper use of app.config file.
Example:
Replacing the .exe file with a new version (where settings are different) to the output directory without changing the exe.config, results in the program seeing the hard-coded settings and not the settings of the existing .exe.config
So my Questions are:
What is the exact role of exe.manifest file
Every time I create a new .exe do I have to paste in the output folder anything else except the .exe file?
Whats the difference in obtaining the setting value by: ConfigurationManager.'settingName'... rather than:
Properties.Settings.Default.'settingName'?
What is the role of app.config build action?
Sorry If I am asking too much in a single Question.
The app.config file is a file that gets a special treatment when running the associated application. If you executable is named MyApp.exe the app.config file should be named MyApp.exe.config. The role of the app.config build task is to copy the file named app.config in your project to MyApp.exe.config in the output directory.
.NET provides ways to read the contents of the file (it is in XML format) and various parts of .NET will look for different sections in this XML to provide configuration.
A widely used section is the settings section you refer to as Properties.Settings.Default. This section plays together with Visual Studio that provides an editor for application settings. The settings are accessed in the code by using a generated class. Adding a setting will add a property to this class and this property is initialized from a value in the app.config file.
In the Visual Studio editor you can set a value for the setting and you can think of this as a default value for the setting. However, if you overwrite the value in the app.config file the later will take precedence. This allows you to modify the app.config file after installation and rerun the application with a modified setting.
You can also access application settings the app.config file using other methods, but in my oppinion using the Visual Studio editor and the code generated class is the best way to do that.
I am not sure I fully understand the problem that you experience. If you update MyApp.exe and leave MyApp.exe.config intact you should not see a change in the settings used by the application (unless of course you have renamed or changed some settings).
The manifest file provides information about side-by-side assemblies and can be used to request elevated privileges among other things. This is not related to the app.config file.
There quite a few resources about that.
See http://msdn.microsoft.com/en-us/library/ms229689%28v=vs.90%29.aspx
and the (better) overview: http://msdn.microsoft.com/en-us/library/k4s6c3a0%28v=vs.110%29.aspx
app.config is a very powerful tool. It addresses many issue like versioning, migration, upgrading etc. but this requires some in-depth reading from the links above.
Maybe one thing you could do, if you want to copy only .exe file every time you build your app, is make a settings.ini or settings.txt file, put your parameters in this file (that are not secret of course) and read all your settings from there when you start your app.
You can put all your connection string logic in your login form if you have one...
Kind of a two part issue.
I developed an app which reads from and writes to an App.config.
The application is installed in Program Files by my MSI installer.
It works fine on my Win7 computer but I have users on Win7 that get Access Denied when writing to this App.config.
I am writing to the app.config using the below code:
Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
config.AppSettings.Settings["Endpoint"].Value = endpointTxtBox.Text;
config.Save(ConfigurationSaveMode.Modified);
Why don't I get this issue on my development pc? I have tried both with a local admin and normal local user account.
How do I relocate the App.config to an unprotected directory?
Cathal,
You should not have to move the app.config in order to let your users save their application settings; .NET already has support for saving user-scoped app settings in user-writable storage baked in! You can even specify the default user settings in the app.config file.
Check this link for details:
http://msdn.microsoft.com/en-us/library/8eyb2ct1(v=vs.110).aspx
Note that making use of a strongly-typed .NET Settings class rather than the raw, more weakly-typed AppSettings NameValueCollection. (The settings can still stored in the app.config, though.)
You can create a Settings file in VS (the template is called "Settings file" in VS).
A couple of things confused me about Settings files at first, so I thought I would point them out to you:
1) First: the .settings file. The VS designer lets you define your app settings, their types, and their scopes (i.e. user or application). This is the file the designer modifies when you user the designer, but runtime configuration changes will never be written to this file. It defines your app settings and their default values. That's it. I didn't get that at first when I was trying to wrap my head around Settings files.
Also, notice that the build action on the .settings file is set to SettingsSingleFileGenerator.
2) The .designer.cs file. VS/MSBuild generates this file at build-time for you because the build action on the .settings file is set to SettingsSingleFileGenerator. The class that it generates is a strongly typed wrapper for your configuration properties, and you can use it equally well for your application-scoped and user-scoped properties.
3) The runtime settings that your Settings class wraps are still stored in the app.config.
4) User settings are stored underneath that user's AppData\Local directory so that they have full read/write permissions.
I had a couple of other ideas, if what you need to do really is let the user modify the global application settings for all users.
Externalize some of your configuration by using the configSource attribute. You store the entire
appSettings section, for instance, in a separate file by doing this:
<appSettings configSource="....\file.config" />
Here are the docs for that feature: http://msdn.microsoft.com/en-us/library/ms228154(v=vs.85).aspx
I believe you can manually load a config file anywhere you want using the System.Configuration.ConfigXmlDocument class. Construct one using the no-arg constructor and then call its Load(String filename) method.
Store your configuration in the registry rather than the filesystem by implementing a custom SettingsProvider.
I am confused about how the app config file is used. I have a program that connects to a SQL server database , retrieves data from a specific table. I am using LinqToSql classes to do this. When I follow the wizard at the end the connection string gets placed in the app.config file.
I then plan to use that program as a class library so I add a reference to that exe from a different executable which is a wpf application. On that wpf application I have to place an app.config file containing the connection string in order for the program to work.
So far I understand everything. Now the part I am confused is why I do not have to copy also the settings located in the app.config file as well in order for the program to work? which settings are OK to be on the referenced executable and which ones are not. For example I know that the connection string should be on the app.config file of the wpf application. But the user settings :
app.config:
can be on the app.config of the referenced executable.
In summary why did I have to move content from the referenced executable's app.config file to the app.config file of the wpf application and I did not had to move other content from the referenced executable app.config file?
By default, the config file that is used is that of the executing process/program. Since your WPF app runs as its own executable, the config settings need to exist in its config file.
As for the other settings, your WPF app probably doesn't need them.
As a side note, it's usually a better practice to have a WPF/client app hit a service instead of going directly to the database itself. That would mean that the connection string would go in the config file of the service at that point. And the WPF app would just ask the service for the information.
In my application I would like to persist a variable for configuration as part of the the project (I could do it with an accompanying file but that would be evil), so that a change can be made while the application is running and saved such that it can be closed and re-opened and keeping the same value.
What is the recommended or best practice approach to this in a Visual Studio 2010 C# project?
Use App.config or Web.config.
Example: here
Which is the recommended best approach.
You could also save your settings in the Database (if you're using one) and load them at runtime, if you don't want to use "an accompanying file" (although having said that it is still an accompanying file). However you'd have to hard code the connection string to your DB which might be troublesome if the connection string is changed.
Also note that connection strings are usually saved in the .Config file under the tag <connectionStrings></connectionStrings>
Make use of .Config file for saving setting. Developers can use configuration files to change settings without recompiling applications.
Configuration files contain elements, which are logical data structures that set configuration information. Within a configuration file, you use tags to mark the beginning and end of an element.
Configuration Files
and
Configuration Settings File for providing application configuration data