.NET 3.5 DLL using its own configuration file

Question

I need the .NET 3.5 DLL to have its own configuration file. This DLL can be called from many different applications, so the information (for example, connection strings) stored in the configuration file must be stored in the configuration file, which can reference the DLL. I want that when the DLL is used, I need to "switch" the configuration file, which is used to refer to information in the DLL configuration file. Then, when the DLL is executed using the configuration information, the switch reverts to the standard ones. The DLL is written using .NET 3.5. I was looking for how to do this, and what I keep finding is how to combine the information with the exe app.config file. In my case, I do not know how this DLL will be used to modify any exe app.config files. This solution must be self-contained. However, my base classes used to create DLLs (which contain business objects) expect to find the connection string and other information in the configuration file, so I need to "switch" to my DLL configuration file while it is and then switch it so that I don't mess up the exe application that caused the DLL.

Answer 1

The configuration system. NET 2.0 and higher provides you with options - you can, for example, download a specific configuration file on demand. This is a bit more work, but it works.

You will need to do something like this:

// set up a exe configuration map - specify the file name of the DLL config file ExeConfigurationFileMap map = new ExeConfigurationFileMap(); map.ExeConfigFilename = "ConfigLibrary.config"; // now grab the configuration from the ConfigManager Configuration cfg = ConfigurationManager .OpenMappedExeConfiguration(map, ConfigurationUserLevel.None); // now grab the section you're interested in from the opened config - // as a sample, I'm grabbing the <appSettings> section AppSettingsSection section = (cfg.GetSection("appSettings") as AppSettingsSection); // check for null to be safe, and then get settings from the section if(section != null) { string value = section.Settings["Test"].Value; } 

You also need to make sure that the configuration of the class library DLL is built and copied to a place where you can get it. In the worst case, you need to specify a specific configuration file and make sure that it is copied to the output directory by setting its Copy to output directory property in the Visual Studio properties window.

You should also check out the Jon Rista three-part series on the .NET 2.0 configuration on CodeProject.

• Puzzles for .NET 2.0 Configuration
• Decryption Secrets of .NET 2.0 Configuration
• Breaking Secrets of .NET 2.0 Configuration

Highly recommended, well written and very helpful!

Mark

Answer 2

You cannot use the built-in .Net configuration system. It is designed (as it should be) to configure application processes, and not for individual DLLs. The right way to do this is to add configuration parameters for the dll to the app.config system for each executable application that "uses" (has a link) this DLL. (or in machine.config file)

• Just make the settings available for ALL applications that use its dll can be achieved by putting them in Machine.config (in C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG for .Net2.0

If you don’t want to do this, you will have to write your own code to open, read and write frm your own Xml file (or any other format that you decide to use) to exclude these settings,

Answer 3

Usually, when you have settings at the application level, you need to generate these parameters at the application level, and then percolate them through your libraries. It adds a few more lines of code to your initialization for dependency injection, but you are essentially trying to do this.

You will encounter more problems than it costs if you try to include the dll-only configuration file side by side with each deployment of your library, and it just doesn't make much semantic sense.

Take System.Data, for example ... when you create a connection, you specify a connection string, and do not create a separate configuration file just for the connection string for deployment next to the System.Data library. [and this will cause a lot of problems, as it is likely to reside in the GAC on your system]

Answer 4

The simplest answer to this question is to put the values ​​in the machine.config file. Thus, all applications using the DLL will be able to access information through the .net application configuration classes. With this, too, if you absolutely need to override the value for a specific application, you can override it in the main application app.config file.

Answer 5

I know this post is a little old, but I wanted to drop my 2 cents. Although in cases, I would agree that the application should provide the settings, not the dll. I found one situation while dll configurations specifically look more desirable.

We are using the scheduling / task Quartz.NET application. We have developed an interface for creating and monitoring jobs with the Quartz server. One of the great things about Quartz.NET is that you create your own “working” programs and compile them into DLLs, and then just drop them into the Quartz.NET server folder, and thanks to reflection and the like, Quartz can start using the new DLL without any additional settings to the Quartz server ... if there is no information that should be stored in the configuration files.

With the Quartz server, if you have any specific configuration information that should be stored in the configuration file, you should put it in the Quartz.NET configuration file. We created several job applications, each of which has its own bits of configuration information, so now our Quartz.NET configuration file is littered with all these unrelated settings. Having a configuration file with dll will significantly reduce the clutter on the Quartz.NET server. The only other option that I see is to add all these individual settings to the settings table, but for our consolidation and maintenance of the code, separate configuration files are preferred for our purposes.

Just drop it to think.