is it good design to have a separate config file for a dll?

Is it good design to have a separate config file for you dll?

I noticed when the dll is invoked from the application, it doesn't read it.

what the dll is able to开发者_运维技巧 read is the machine.config file.

---

Making a dll dependent on a config file is not ideal and can become a real pain when you start unit testing or moving it about.

A better solution is pass any values from config settings in from the calling application e.g. WebApp or Windows App etc. and store any settings required in the app or web config.

---

It looks like you have two separate questions.

1. The users of your program aren't going to think in terms of configuring both your application and any associated DLLs. It seems to me that having a separate config file for a DLL might be confusing for users. It's not bad design to have a separate config file, but it's not necessarily good design either.

2. DLLs certainly can read files. Check that the DLL is reading the file from the correct location (check the current working directory, for example).

---

This really depends on usage. For a DLL that is simply part of a primary application, no. For certain plugin scenarios, however, it can be cleaner to include a library-specific configuration, whose loading you then have to provide for in the assembly itself. You can also do this by modifying the application's own config file, if it has one.

So for example you might have the following plugin-specific setting:

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

or you might use a subsection in an app.config, something like

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

Either will work, the former is a little simpler to maintain in some cases but more pain to load at runtime, the latter requires a little more configuration and maintenance but can be accessed more simply at runtime.

---

Maybe not a separate config file but you could easily set up a separate config section for each dll. Then it is easy to use in multiple sources.

---

I would tend to pass configuration options down to each layer that needs them. The config file would then serve as the passing convention for the uppermost layer. That makes the most sense to me.

In this scenerio, a DLL would not need to read the config file.

My reasoning for this boils down to separation of concerns. Unless the point of a DLL is to read files on your hard drive, it shouldn't be reading any files on your hard drive.