Jaa

Storing configuration settings for your DLL to use

  • Artikkeli

One common complaint about the .NET framework is that there is only one config file for the application, even if there are many assemblies (exes and dlls).  This post contains advice for how the author of a DLL can keep the configuration settings for that DLL seperate.

The config file gets its name from the .EXE, not the DLLs.  Therefore, if your U/I is the EXE (which it usually is), then your dlls will be getting their settings from the config file for the EXE.

It is often the case, however, that the DLL provides services that can be configured, and that you would want to configure those services differently for each application that uses the DLL.

On the other hand, if you want to provide a set of "common services" using your object layer, then you can create an XML file that the DLLs will use. So, how does the dll find it's XML file?

I've answered this question many different ways in different apps, trying things out to see what works.  I've got three answers:

  1. Put the name of the XML file into the registry during install.  The DLL looks to the registry to get the config file name.  This is useful if you are writing a DLL that needs to run from Biztalk or Sharepoint, since you cannot control either their executable or the directory in which they are installed.
  2. Give the XML file a fixed name, hardcoded into dll itself.  Have the DLL look into the application directory (where the EXE lives) to find the XML file.
    • Variation: in the app.config for the EXE, provide a seperate section for the DLL to use.  That section will contain the name of the XML Config file.  If no name is given, use the hardcoded name.  If neither is found, use basic default settings or raise an error in the constructor of your classes.
  3. During install of your app, create a specific directory where nothing but the XML config file will live.  When it comes time to go looking for the file, take the first XML file that you find that lives in that directory.
    This is convenient when transferring your app from dev to test to production, because you can have three files: dev.cml, test.cml, and prod.cml (I renamed xml to cml on purpose). 
    When you install the app, all three are placed in the directory.  The next step in the install is to ask the person doing the install "what environment is this" and, using their response, rename the proper file to the "xml" extension.

In all three cases, loading an XML is not as difficult as it first appears.

Take a look at the XSD.EXE tool that is delivered with the .NET SDK (a free download from Microsoft).  Using the XSD tool, you can point at an XML and the tool will generate a class that the XML will deserialize into. 

Using this class, and the XML deserialization methods built into the framework, you can very easily load the entire XML file into an object that contains other objects.  Now, you can use that object "tree" to inspect your settings very easily. 

In fact, if you change the values in the settings, it is very easy to save those changes back to the XML config file by simply using the serialization functions (something that is a bit more difficult with the config files).

I hope this provides useful information.

Comments

  • Anonymous
    November 25, 2004
    Very reassuring (I have been doing 1 and 2)... Number 3 doesn't feel right (a whole directory for a config file?) but has a lot going for it with the profile/environment approach.. Cheers!
  • Anonymous
    November 25, 2004
    I think that your option #2 variation is the best idea. .NET definitely has moved to a model of using the app.config or web.config for application configuration. Using these files is also dynamic and easily scripted for updates and deployment.

    Good ideas!
  • Anonymous
    November 25, 2004
    Although I appreciate this post, I didn't find anything new. However, there is one thing I have noticed in Whidbey. When you create a Class library project (DLL project) and you create App.config file within the project and you compile it, the IDE (or compiler?) creates DLLProjectName.dll.config, which VS .NET 2003 doesn't do. I tried to read configuration data out of the config file, but it seems it still reads the config data from executable config file. I'm wondering if Microsoft has a plan to actually allow DLL to read config data from its own config file?
  • Anonymous
    November 25, 2004
    Similar to the previous poster, I write a config file for the DLL that uses the same name as the DLL plus a ".config".

    The DLL itself then can figure out where it is located and load the .DLL.config file from the same location.
  • Anonymous
    November 29, 2004
    When you say that the DLL itself can figure out where the config is located, you are left with one of my three alternatives: it has to exist either in an easily guessed folder (the install folder, or the user's application settings), a hard-coded folder, or a link has to be provided (like in the registry). This is really what I was trying to get at. The name of the config file is not really important outside these options.