How can another developer know that the class library uses app.config? Or should I just exclude app.config?

Question

As an example, I created a class library (Email.DLL) that sends an email. To send an email, SmtpClient needs credentials that are currently read from app.config.

So, now I created a separate console application (SendStuff.exe) that sends an email, so I added Email.dll as a link. Being the one who created both the DLL and the console application, I know that I need to add the appropriate keys in the console application appSettings app.config in order to send an email.

Now let's say that someone else is using a DLL. How does he know that his application must include the appropriate appSettings so that my Email.DLL can send an email?

Or would it be better to just exclude app.config from the class library and find another way to set credentials?

Answer 1

Using a local configuration file is a completely standard approach. You should usually include this information in the documentation that came with the library. Often there is a Getting Started or Tutorial page.

With that said, I would also implement clear and effective exceptions that occur when these configuration values ​​are missing. Sort of:

Could not find SMTP credentials in App.config. See the documentation for more information.

Finally, if you distribute your library using NuGet , you can automatically enable the default configurations that will be set when the library is added through the package manager.

Answer 2

I can think of two high-level approaches, depending on the answer to one question ...

• Does this library describe its implementation details from the consumption code?

If yes, then I would give the library a sample app.config to demonstrate how to configure it. When the library loads, it can check the configuration values ​​and throw an exception if they are not available. This can be useful in the case of, for example, a universal messaging interface in which the consumer code does not need to know if it is sent by email:

 public class Messenger : IMessenger { public Messenger() { // maybe confirm config values here } public void Send(string message, User recipient) { // implementation details } } 

Make the exception very explicit so that it is obvious that the problem is.

If, on the other hand, the answer is “no,” and the “SMTP version” of the library does not need a more abstract interface, then the library can just as easily require configuration when you use it:

 public class Messenger { public Messenger(string smtpServer, int port) { // set the local class values from the supplied values } public void Send(string message, string recipientEmail) { // implementation details } } 

This completely disconnects the library from the configuration details and forces the consumption code to provide these values. For a developer using a library, this is much more obvious. However, this requires implementation details to be exposed to static code to reduce abstraction. Pros and cons anyway.

Answer 3

In my opinion, it’s better not to read the credentials from your library at all. Allow the caller to pass credentials to the smtp client.

eg:.

 SmtpClient client = new SmptClient(string username, string password); 

This allows the consumer to understand what he needs to do so that he can use the class. The consumer can still decide to save the username / password in app.config or pull out the credentials from another place (for example, a database).

I agree that using app.config is not unusual, but I would only suggest if the data cannot be easily passed to the component from within the code.

Even if the data structure is complex (for example, configuring a registrar), you should still provide the consumer with the opportunity to use your component exclusively from code. So, for example, log4net is usually configured using a configuration file, however you can always use the Configure () method to get around it.

 log4net.Config.XmlConfigurator.Configure(XmlElement element)