I have an application that gets compiled into an executable. It relies on an app.config file (which gets turned into a MyApp.exe.config file).
I needed to make an update to the application, so made the change, recompiled, and then replaced the application.exe file. But it wouldn't work...until I also copied up the new app.config file with it, even though the app.config hadn't changed.
Can someone explain this? Does the app.config become a dependency that is versioned like any other dll? I thought since it is a config file (essentially a text file), it wouldn't be versioned and depended on in this way.
The app.config file is just an xml configuration file. There's no versioning like with assemblies.
Is it possible some of the changes you made added some config to the app.config that's in the original app.config. For example, adding service references will change the app.config with endpoints and config needed for web services.
what error do you get?
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
I have a web project that references a dll project that uses an app.config value. Is there a way to put the app.config values in the web.config so when the web project is run it pulls the values from the web.config? I've heard of this happening but I'm not 100% sure of it.
You can use the configSource attribute/property of each config element - this allows you to put sections of your configuration in an external file.
Once in an external file, you can reference this file from both your web.config and app.config files.
I dont think there is a wasy - but to open manually the app.config file ( if your start entry point is the web...)
so youll have to open each section and analze it.
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.
I have a class library, which has an app.config and when built it put the app.config along with the dll in the output directory I have chosen.
I don't want it to be name app.config though, if I have another component that has it's own dll, I can see confusion happening.
I've been looking at another project, that does exactly that, but I can't see why it outputs dllname.dll.config and mine always app.config.
Any ideas?
Thx
You probably have set the Copy to output directory setting of the app.config.
BUT: In a class library, an app.config is useless.
Note, that you can only have one config file per application. The configuration is being read (at execution time) from <executing assembly file name> + ".config".
I have a config file in my C# class library called MyLibrary.config, in vs 2008.
I created another project, say a simple console app, add reference by "Browsing" the MyLibrary.dll in the bin directory of the class library project, and when I compile, the MyLibrary.config is not including in the bin directory of the output in the console app.
How can I set it so I can include it when I reference the dll?
Cheers
You can't. Your console application is expecting to find a config file with prefix the same as the name as the console application (MyConsoleApplication.exe -> MyConsoleApplication.exe.config.).
In some situations you can share a config file by using the file attribute on the appSettings element:
<appSettings
file="path">
</appSettings>
Note that path is relative to the executing assembly.
As a side note, DLLs do not even use the config file that you've defined in the project. Again, configuration information is read from the a config file with prefix the same as the executing assembly. Thus, even when MyLibrary.dll tries to yank configuration information out of a config file, it will be reading the config file for the executing assembly, not MyLibrary.dll.config.
For more on how config files work, see MSDN.
The standard way to use a config file is to have it the same as the executable, adding a reference to a dll will not include its config file and as far as I know dll's don't load config files on their own, rather they rely on the executable that reference them.
Beyond not being able to do this, I would also advise against this approach.
Rather than trying to tighly couple your settings to the DLL library, consider more of a "Dependency Injection" type approach - i.e. where you pass in the value dependencies (i.e. settings) to the code you are calling (i.e. the library).
The advantage in this is you are not tied to a single method of storing settings. You can then use a database, different config file formats... even hard-coding. It also makes unit testing easier by removing the external file dependency.
There are different ways to implement this, however one example is to pass the configuration settings into the constructor of the class(s) that uses them.