when building a desktop app in wpf can you read documentation of problems and safely subsititute 'app.config' when people's answer's refer to 'web.config'?
if so are there any glaring GOTCHAS you have to look out for?
tnx
Read the Documentation:
Web.config and App.config
The choice of the
configuration file name is determined by the hosting environment you
choose for the service. If you are using IIS to host your service, use
a Web.config file. If you are using any other hosting environment, use
an App.config file.
In Visual Studio, the file named App.config is used to create the
final configuration file. The final name actually used for the
configuration depends on the assembly name. For example, an assembly
named "Cohowinery.exe" has a final configuration file name of
"Cohowinery.exe.config". However, you only need to modify the
App.config file. Changes made to that file are automatically made to
the final application configuration file at compile time.
In using an App.config, file the configuration system merges the
App.config file with content of the Machine.config file when the
application starts and the configuration is applied. This mechanism
allows machine-wide settings to be defined in the Machine.config file.
The App.config file can be used to override the settings of the
Machine.config file; you can also lock in the settings in
Machine.config file so that they get used. In the Web.config case, the
configuration system merges the Web.config files in all directories
leading up to the application directory into the configuration that
gets applied.
Web.Config is used for asp.net web projects / web services.
App.Config is used for Windows Forms, Windows Services, Console Apps and WPF applications
Your question isn't providing all the information as to where the gotcha's may lie for you.
Can you give us more info on what you are trying to do in terms of these config files?
Here's a link...
Problems with Web.config and App.config
Related
Set & settings:
I use Entity Framework 5 and have a dll project with edmx file. In this project I have App.config with connection string for the EF model. I have also second project, ASP.MVC 4 web application which is a startup project. It references the database project. Important thing is - db is Oracle and EF uses Oracle custom providers.
Problem:
If I place my connection string in the ASP.MVC startup project is works fine. It's common advice to do this. But I don't want to. I don't see reason why I should. How can I force MVC/EF to find the connection string in App.config of the external library (which as a matter of fact is a data access layer)?
App.Config is used by WinForms, WPF and executable applications.
Web.Config is used in IIS (and is able to set IIS environment specific configurations)
It seems no App.Config will ever be merged to the Web.Config (source):
In using an App.config, file the configuration system merges the
App.config file with content of the Machine.config file when the
application starts and the configuration is applied. This mechanism
allows machine-wide settings to be defined in the Machine.config file.
The App.config file can be used to override the settings of the
Machine.config file; you can also lock in the settings in
Machine.config file so that they get used. In the Web.config case, the
configuration system merges the Web.config files in all directories
leading up to the application directory into the configuration that
gets applied. For more information about configuration and the setting
priorities, see topics in the System.Configuration namespace.
Perhaps you'll find a solution more appropriate to your needs by using Application Configuration Files.
Finally, after facing multiple issues, I've decided to move connection string of DAL into the Web.config of the web application. I was convinced by some arguments you can read here in the post of Chris Ammerman.
Suppose a project has both App.config and Web.config files with some conflicting information. Are there any rules which of the files has higher priority? Or an application has to disregard both of them and throw an exception?
From MSDN for .NET 4.5:
When configuring a service in Visual Studio, use either a Web.config file or an App.config file to specify the settings. The choice of the configuration file name is determined by the hosting environment you choose for the service. If you are using IIS to host your service, use a Web.config file. If you are using any other hosting environment, use an App.config file.
In Visual Studio, the file named App.config is used to create the final configuration file. The final name actually used for the configuration depends on the assembly name. For example, an assembly named "Cohowinery.exe" has a final configuration file name of "Cohowinery.exe.config". However, you only need to modify the App.config file. Changes made to that file are automatically made to the final application configuration file at compile time.
In using an App.config, file the configuration system merges the App.config file with content of the Machine.config file when the application starts and the configuration is applied. This mechanism allows machine-wide settings to be defined in the Machine.config file. The App.config file can be used to override the settings of the Machine.config file; you can also lock in the settings in Machine.config file so that they get used. In the Web.config case, the configuration system merges the Web.config files in all directories leading up to the application directory into the configuration that gets applied. For more information about configuration and the setting priorities, see topics in the System.Configuration namespace.
Here's also a great post for those using MS Azure, explaining the differences b/w ApplicationSettings, appSettings (app.config/web.config) and ConfigurationSettings (.csdef / .cscfg):
http://haishibai.blogspot.com/2012/09/windows-azure-cloud-service.html
Is it possible, through code, to copy settings from one Web.config file to another (except AppSettings and ConnectionStrings)?
I have a situation where a single MVC3 project has been deployed to multiple servers in different locations. There is an auto-updater on all of these that will pull in the latest version. Typically when this would run, it would only overwrite the application folders and NOT the Web.config file.
I just upgraded the project to MVC4. This changes basically everything in the Web.config file except the AppSettings and ConnectionStrings. All of the installations of this project would have slightly different values here.
How would I go about writing some code that will update the Web.config file, but preserve all of the AppSettings and ConnectionStrings?
.NET provides ways to get configuration from other config file. Refer this article:http://blog.andreloker.de/post/2008/06/Keep-your-config-clean-with-external-config-files.aspx
Basically, you can use "configSource" attribute to define which config file to refer. Note that the configuration file should be in same directory. if not, Refer here to solve the problem. .NET Config Files configSource outside the application directory folder
I have several C# console applications, which need to have the same set of settings. I want to avoid duplicity and avoid separate app.config for each application.
Is there any way to read a common app.config file (say common.config) for applications (app1.exe, app2.exe).
Create one file called app.config. Put it in some place outside of your projects' directories, like up in the solution directory. Add it to your projects as a linked item with a relative path to the file. Set the right build action for this item (application configuration) in each project.
Now when each project builds, the file will be copied to the project's output dir with the right name.
You can load an external app.config using the code below:
config = ConfigurationManager.OpenExeConfiguration(Path.Combine("C:\test\root", "Master.exe"));
string logpath = config.AppSettings.Settings["Log.Path"].Value;
And save settings as so:
config = ConfigurationManager.OpenExeConfiguration(Path.Combine("C:\test\root", "Master.exe"));
config.AppSettings.Settings["Log.Path"].Value = "C:\newpath";
config.Save();
You might have to have a master config within one of the applications and point the rest to this. Typically this method is considered bad practice though. There might be issues with different applications locking the file.
#Ran's answer is an option, but each application will still have its own config file after you build. At compile time they will be the same, but at deploy time they are copies.
You can also open one application's config file from another application using:
ConfigurationManager.OpenExeConfiguration(string)
You can have an external config file that all applications reference using:
ConfigurationManager.OpenMappedExeConfiguration
And there's the option to using the Machine config file using:
ConfigurationManager.OpenMachineConfiguration()
I have an app.config file for a windows service which includes database connection strings and appsettings. when I install the windows service, it gets installed in "C:\program files\" folder and the settings are copied to a file called ".exe.config" in the same folder, which makes it difficult to change the settings after it is deployed to test environment. can I have all settings stored in an external file somewhere on shared network drive, instead of the same folder where the service is installed? is that possible? only alternative I can think of is to create an xml file and read it using the .NET XML API, another issue is I need to watch for the changes in the file and reload the settings in the service.
Linq to XML makes it fairly easy to read an external settings file. You can also use a FileSystemWatcher to watch for changes in the settings file.
You can push some of your config settings out of your core config file, e.g.:
<connectionStrings configSource="connectionStrings.config" />
And:
<?xml version="1.0" encoding="UTF-8"?>
<connectionStrings>
</connectionString>
That way, as long as you don't deploy the connectionStrings.config file, you can safely deploy the app and maintain those settings separately. The good thing about this approach, is you don't need to create a whole new method of getting config data, this is built into the configuration system, just read these settings how you do currently.