I've used these two configuration files many times before, but I've never taken the time to fully understand how they really work. As most people do, I understand the basics in how to call WebConfigurationManager.AppSettings["key"] to get config values.
Here are some questions I came up with:
What happens when you reference a configuration value within a class library, and the library is part of a bigger solution? Does the app.config need to be copied to the output directory in order for the variables to be found? (I assume yes)
Can you directly use a configuration value from an app.config in another class library?
Assuming question 3 is "yes", what happens if there are multiple app.config files from different libraries containing configuration values with the same key?
What happens when you reference the web.config, but in a class library?
What happens when you reference the app.config, but in a website or web application project?
The underlying answer to all of your questions is the same: Unless you set up something unusual, all assemblies in your project will read from the same configuration file. In a web app, they will all read from "web.config". In any other project type, they will read from the starting assembly's config file.
The app/ web.config that is used is the one that starts the process. Easier if I give an example:
Assume all projects in a solution have an app or web.config.
A test in project A calls code in project B that calls a web service in project C which calls code in project D.
In this case code in project A and B will use the app.config in project A. Code in project C and D will use the web.config in project C.
Related
I'm new in .Net and working with two projects in c# a class library project(dll) and a website asp project.
I need to read some properties from a file .resx that is in the App_GlobalResources folder of the website.
Is there a way to read these properties in the .resx website file from a dll assembly more specifically in the method onPreRender??
Thanks for you attention
It sounds to me that you are having some problems with structuring and dependencies in your solution. (Trying to reference the website from a DLL)
Generally speaking, your DLL should not need to access the resources of the website on its own - you should only pass them in through as parameters when calling various methods that are contained in the DLL itself.
Have you thought about migrating the resource file to the DLL?
That would allow both DLL and the website to read from it.
Another option would be to migrate the setting you need to the .config file which you can read by using the ConfigurationManager class ( MSND Link )
You should be able to use it like this, even from your Code repository project:
string settingValue = ConfigurationManager.AppSettings["YouSettingNameHere"].ToString();
However, if you really want to keep your current solution structure you can follow the answer that Pavel Chuchuva gave on a similar question here.
Warning: I am an IIS/ASP/Razor newb. I am using VS2013.
I have a solution with 2 web projects, let's call then Main and Methods. Main is a Razor MVC project, and Methods is just a generic web project. Methods references Main. I am attempting to add and use connection strings to the web.config file for Methods.
However, when I attempt to access the strings in a function, they are not available. I have discovered that this is probably because the web.config file that is being loaded is the one for the Main project, instead of Methods (according to AppDomain.CurrentDomain.SetupInformation.ConfigurationFile).
Why might this be?
This is because Main is the program that runs - so its the web.config that gets loaded. I suspect you may have the projects setup slightly wrong...
Do you need two web projects? Would Methods ever be run independently from Main - if not make Methods a Class Library, keep all your config in the web.config of Main. You will be able to reference all the config from either project (as Methods would be hosted in Main)
I have a Class Library project containing some basic logic.
The DLL created by this project will be used in a few other projects.
I have a app.config file in the Class Library project with a couple of values the DLL uses.
When each consumer project will use the DLL, it has to change the values in the app.config
For example, if my DLL's app.config contains 3 settings: A, B, C, then:
The first consumer of the DLL will have A="a", B="aa", C="aaa" .
The second consumer of the DLL will have A="t", B="tt", C="ttt" .
and so on...
From design point of view, what is the most clean way to achieve this scenario?
(It seems to me that the app.config should reside at the project that uses the DLL)
Thanks for your attention! :)
EDIT:
Most of my code in the DLL is consuming ASMX web service which includes it's .config . Each application that will use the DLL, has it's own WS address (the contract is identical). How can I inject the address of the service from the application into the DLL?
EDIT #2:
Now I have 2 config files:
1. In the class library project - contains the WCF client config.
2. In the application that uses the DLL - contains the config with the values for the DLL.
How can I inject values from the application's config into the DLL's config (for example the address of the endpoint) ?
Only applications have a .config file, so having a .config file in your class library is useless.
That means that the values should come from somewhere else
The options I can think of are:
Use the .config file of the application - disadvantage: The person that write the application need to know about your config values and add them. Most of the time he/she will find out about these setting when they will get exceptions for missing values.
Save values to a DB (or some other web service) if all your applications use the same DB this can be a good idea. Works nicely when you have a very limited number of applications. I use this for different values for production/test environments
Make every class that needs these values to get them in a contractor. advantage: no hints needed, the application programer will be aware to data. This is a clean interface. I would use this option if it's a customer specific project. disadvantage: lots of work for the applications programer
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Reading dll.config (not app.config!) from a plugin module.
I have two different projects, say A and B. I need to use some classes of A in B. So I added a reference to A in B. When I tried to run the application, I stated getting Object reference set to null exception. On investigation, I found that when I access classes of A from B, control goes to project A, but C# still uses config file of project B instead of using project A's config file. How do I get around this? How can I "include" A's config file in the dll?
I have gone through this blog but I feel it is a very dirty way of doing it. There ought to be an easier way!
Let me know if the question is unclear..
I believe .NET will always load the app.config file associated with the application rather than any libraries. There are complicated ways of specifying your own locations for config files - or just using your own configuration framework instead of the built-in one - but I don't think you can just ask .NET to load a config file per DLL.
Why don't you just all the necessary settings into the config file from project B? If you use some tools and libraries from an external vendor you just do the same stuff to configure it.
If you abstracted the configuration good enough you should be fine. Using another configuration file than the default one - well i would consider this as bad practice.
As I understand this you want integrate a app.config into your dll. Check this out:
How do you load the app.config file into a DLL
You can copy the relevant sections of A's config into the B config file and it'll work properly, but it's a bit tedious to say the least. I suppose you could automate it with a custom tool though.
In running my VS2008 unit integration tests against my DAL, I have found that the assembly is reading machine.config instead of the assembly's app.config.
Here's the rundown on the call stack:
Unit Test Project has method calling into a DataLayer Project
MyDataLayer class inherits from a base class. Method is called GetStuff()
Base class is using System.Configuration . All good.
calling this property in code: ConfigurationManager.ConnectionStrings["MyConnStr"] actually returns null because it's not found apparently.
checking the MyDataLayer class, yep, MyConnStr is there.
checking the collection ConnectionStrings, yes, it has one connection string. It's the one in machine.config that's over in C:\Windows\Microsoft.NET\Framework\v2.0.50727\Config\machine.config
I am not sure why my DAL's app.config is being superseded by the machine.config
Any help is appreciated!
Not sure if this applies to you, but you need to make sure the configuration string is in your Unit Test Project's app.config, not your DataLayer project.
This might help to some people dealing with Settings.settings and App.config:
Watch out for GenerateDefaultValueInCode attribute in the Properties pane while editing any of the value (rows) in the Settings.settings grid in Visual Studio (VS2008 in my case).
If you set GenerateDefaultValueInCode to True (True is the default here!), the default value is compiled into the exe (or dll), you can find it embedded in the file when you open it in a plain text editor.
I was working on a console application and if I had defaults in the exe, the application always ignored the config file placed in the same directory!
Quite a nightmare and no information about this on the whole internet.