Config-based Shared Libraries (DLL's)

Question

I work in a company where we have a lot of small ASP.Net/C# apps. I've been making efforts to centralize as much of the functionality as possible by creating shared libraries for common functions (like Active Directory lookups, FTP, etc).

I'm trying to create an email dll that will perform SMTP interactions. I'd like to make this config-based so it's dynamic but I don't have to put a SMTP Server name, port, etc in every web.config.

Is there a best practice to make a shared library that is config-based but doesn't rely on each app's web.config? I'd also prefer not to have it tied to the machine.config so it's portable.

I want each app to be able to call methods without having to pass in the parameters:

EmailLib.SendEmail("[email protected]", "This is the subject",....);

Thanks.

Answer 1

You have to store the configuration somewhere . . . a database might be an option. Something like an application specific configuration table. You could use reflection to determine the name of the calling application, and use that to lookup a row in a database table. But then how do you configure the database connection? Chicken? Egg? First?

GW has a good Idea below, but at some point you will have "hard code" some reference to the data you need (config file, database connection) Even with a webservice, you will still, assuming that each application will do something like send emails from a different domain, have to tell the webservice what domain to send from.

Answer 2

You could put your email functionality in a web service or WCF service. This will keep the config settings in a single place.

Answer 3

I created a "Settings" library that was essentially just a namevaluepair library that reads/writes to a db table. It's flexible enough to hold lots of data types and is reusable. You could easily implement such library in each of your other libraries. Call some sort of function like:

AgileSetting.SetSetting("EmailSubject", "All your base are belong to us");
string emailSubject = AgileSetting.GetSetting("EmailSubject");

You could also take it to another level and create some sort of grouping of settings to help organize them.

Answer 4

I would argue that in the long-term you're not going to want to use a whole set of hard-coded things like that anyway. All your apps will probably have a different email address for support, and probably want to be using different subjects (to have a proper description of the problem, rather then a generic 'error with foo-corp app').

But as to the general problem, well, you could have a '.properties' file, that a generic NAnt build will process appropriately in some fashion.

Answer 5

I'd say the best practice is to store config information in the web.config (or application config) file for each app.

If you really don't want to do that, you are likely in "roll your own" territory. In particular, I would write something that does not look anything like a normal .NET config file so future maintainers don't get confused about what you are doing.

Config files for DLLs are always awkward. You run into significant deployment, maintenance, source control, and unit testing issues as soon as you want different apps to have different settings for the DLL's config file (which is one of the main reasons the settings are in a config file in the first place, right?).

In general, config settings belong to the application, not to the component(s).

Answer 6

I peronally prefer creating configuration class that are populated from an external file (e.g. xml, dsl) stored in an IOC container then injected into the service that is using it. The process is described well here configuration in conjunction with an IOC container

The advantage of this is i can have multipule configurations per server, and just inject the configuration into the class for my unit tests. Plus everything is strongly typed so i should have to worry about converting ints to string or anything once the application starts.