Does a good design have a separate configuration file for dll?

Does a good design have a separate configuration file for your DLL?

I noticed when the DLL is called from the application, it does not read it.

what the dll can read is the machine.config file.

+4
source share
5 answers

Creating a dll depending on the configuration file is not ideal and can be a real pain when you start unit testing or move it.

The best solution is to pass any values ​​from the configuration settings from the calling application, for example. WebApp or Windows App etc. And save any settings needed in the application or web configuration.

+5
source

It sounds like you have two separate questions.

  • Users of your program are not going to think about setting up both your application and its associated DLLs. It seems to me that having a separate configuration file for a DLL can confuse users. A good design has a separate configuration file, but it is not necessarily a good design.

  • DLLs can certainly read files. Make sure the DLL is reading the file from the correct location (for example, check the current working directory).

+3
source

It really depends on the use. For a DLL, which is just part of the main application, no. However, for some plugin scenarios this may be cleaner to include a library-specific configuration whose loading you then need to provide for in the assembly itself. You can also do this by changing your own application configuration file, if any.

So, for example, you might have the following setting for the plugin:

<IPluginConfiguration> <PluginSpecificSetting name="PluginName">Value</PluginSpecificSetting> </IPluginConfiguration 

or you can use the subsection in app.config, something like

 <configuration> <PluginSettings> <Plugin1> <PluginSpecificSetting name="PluginName">Value</PluginSpecificSetting> </Plugin1> </PluginSettings> </configuration> 

Either it will work, the former is slightly simplified to support in some cases, but there is more pain for loading at runtime, the latter requires a bit more configuration and maintenance, but it can be accessed more simply at runtime.

+2
source

It may not be a separate configuration file, but you can easily configure a separate configuration section for each DLL. Then it is easy to use in several sources.

+1
source

I would like to pass configuration options for each layer that they need. The configuration file will then be used as the sending agreement for the highest level. It matters to me the most.

In this scenerio DLL you will not need to read the configuration file.

My reasoning about this comes down to delimiting problems. If the DLL point is not intended to read files on your hard drive, it should not read any files on your hard drive.

+1
source

Source: https://habr.com/ru/post/1316591/


All Articles