Problem is that my settings from "app.config" is not being gotten in class library project.
Can "app.config" be used in applications only and not in class libraries?
You should add the config settings to the project that is using the class project. ie If you have a project 'MyProject' that references 'MyClassProject' then the app.config settings should be placed in the 'MyProject' project
Application configuration files contain settings specific to an application. This file contains configuration settings that the common language runtime reads (such as assembly binding policy, remoting objects, and so on), and settings that the application can read. The config file is optional, if it does not exist environments such as ASP.NET will fall back to the machine.config file stored in the .NET system directories to get machine wide defaults.
Think about it like that. If you class library has some custom settings then it should have a config to deal with it.
By design of .NET framework when you access Application configuration with default means - .NET runtime supplies you with data from app.config of entry assembly (an EXE file that references your class library).
Application Configuration of class library can be accessed in following way (code should be placed in project of class library - in order for Assembly.GetCallingAssembly().Location to return proper path):
ExeConfigurationFileMap classLibraryConfigurationMap= new ExeConfigurationFileMap();
classLibraryConfigurationMap.ExeConfigFilename = Assembly.GetCallingAssembly().Location + ".config";
Configuration classLibraryConfiguration = ConfigurationManager.OpenMappedExeConfiguration(classLibraryConfigurationMap, ConfigurationUserLevel.None);
Related
I have a client project which is referring to an assembly(project 2) for some additional methods which need config settings. I have set these config settings in project 2. However, project 1 does not pickup these config settings and only works if I redefine the config settings mentioned in project 2 into project 1.
It is generally a bad idea to have libraries control configuration settings.
And I think .Net by default reads from the entry assembly's config file. You can create a Custom Settings Provider class for the .dll and then read .dll.config using a static initalizer of that class
Please, can someone clarify to me a loading process? Say, you have app.config file for your UI executable. You add Enterprise Library config sources in that file. Each config source refers to another config file, say, one for logging dll, one for data storage dll and one for services dll. In each aux configs you write sections related to Enterprise Library application blocks and some core sections from .NET System.Configuration namespace (for example, connectionStrings).
Now, when configuration system initialized during UI startup, how this hierarchial configuration will be loaded?
As I understand, Enterprise Library will load it's own configuration sections, and will follow file name links and load external configuration files for each FileConfigurationSource. And after will load it's own configuration sections from each external file, mixing them all together.
What about core .NET sections? Will it be loaded also hierarchially by means of Enterprise Library, or I should use configSource attribute for this purpose?
I have a class library which needs some configuration to function. This class library is referenced by multiple applications (Multiple ASP.Net websites, and Windows Forms applications)
It is my understanding that it is possible to store the configuration in the library's app.config => myDll.dll.config file. See: Putting configuration information in a DLL, and C# Dll config file
My issue is that I don't want to manually handle copying the config file to the bin folder of every host assembly. Is there a mechanism in .Net to handle pairing of the dll to its config file so that the accompanying configuration is copiled along with the dll whereever it is distributed/referenced?
If the config is the same for all instances of your dll, then I'd add it as an embedded resource, so it's part of your dll and not a separate file at all.
TO do this, either add it as a file resource to your Resources.resx file, or just add the file directly to your Project and then set its compile type (in the Properties window) to Embedded Resource.
You can then use Assembly.GetExecutingAssembly.GetManifestResourceNames() to list the names of the resources in your dll, and Assembly.GetExecutingAssembly.GetManifestResourceStream() to get a stream to read the file's data from. I'd probably use a simple homebrew XML format for my data and then an XmlTextReader/XmlDocument to read it very easily back in.
You'l have to deploy this .dll into GAC and put there the config file, all apps will first search the GAC when loanding a reference. Here is how you can deploy the dll + config.
So I'm trying to use a .Net Assembly in my web services project. This assembly requires lots of settings in App.config. But my web service doesn't have an App.config, it has a web.config. It seems that it uses sections that an app.config would have that don't even exist for web projects. Is there any way I can make this assembly work? (make it read another config file maybe?)
You should be able to simply use the same configuration sections in the web.config file that exist in the app.config and it would work.
The way the configuration subsystem works means that it does not matter.
Typically we keep our config values in web.config/app.config and for the environment global config varialbes (and not application specific) in server machine.config file.
When deploying an object to the GAC where is the best location to keep these config type values? It seems that the best location would be a linked resource file.
Does anyone have any experience/recommendation with this approach? (sample code?)
thx
The configuration values need to be in the application configuration of the executing assembly. It is the responsibility of the application to have the configuration values so that your assembly will have access to them when it is loaded into the AppDomain.
I've had a need for assembly-specific config files (as opposed to executing assembly config files) in the past.
For an assembly in the GAC, it is possible (but not recommended) to physically copy a config file to the assembly dll folder.
The solution I've used for creating a config file that can be shared across assemblies regardless of AppDomain is a a simple registry entry for my application that defines a shared config file location. This way, any assembly can retrieve configuration settings from a shared location, regardless of which executing assembly launched it. (especially useful for scripting - otherwise, you'd have to deploy a config file named wscript.exe.config in the windows\system32 folder - UGH!)
if you dont care of having specific configuration for each application using your dll you can place the configuration in the machine.config file inside the framework folder.
%systemRoot%/Windows/Microsoft.Net/Framework/[Version]/Machine.config