Question

I recently wrote a DLL in C# (.Net 2.0) which contains a class that requires an IP address. A co-worker of mine altered the class to retrieve the IP from a ‘.dll.config’ (XML) file — This apparently is automatically generated by the ‘Application Settings’ file he created (Settings1.settings). The benefit of this was to allow the end-user to change the IP address in the XML/config file at will.

Unfortunately, when I check his code out of the tree and try to compile (or use) this new code, any application calling this DLL only gets the default value, rather than the value from the file.

The constructor that calls the config file looks like this:

    public class form : System.Windows.Forms.Form     {         public form()         {             // This call is required by the Windows Form Designer.             InitializeComponent();             IP = IPAddress.Parse(Settings1.Default.IPAddress);         }     } 

I found a reference to this problem on the MSDN forums where a user said:

the ‘old’ values (the ones you define at development time) are hard coded. If the franework isn’t able to access or open the config file it will use the defaults instead. This will always happen if you use settings in a dll.

1. Does this mean that I cannot store an external value for a DLL in a config file? (My co-worker has somehow made this work…)

2. Since my framework appears to be unable to access or open the config file, how do I figure out why it’s failing? Or even detect when this happens?

Decker: That helps a bit. Unfortunately, I am writing this DLL to a specification, so I don’t actually have access to the Application’s config file. As you’ll note above, my co-worker created a ‘Settings1.settings’ file. I didn’t understand this at the time, but it seems now that adding the ‘1’ keeps it out of the settings space of any application that calls it.

I guess what I’m trying to figure out is why the DLL doesn’t seem to find the config file sitting next to it in the same directory. Tracing thru the code step-by-step reveals nothing.

As an aside, I can change the ‘Output Type’ of my assembly from ‘Class Library’ to ‘Windows Application’ and add the following lines at the beginning of my DLL code:

    [STAThread]     public static void Main(string[] args)     {         System.Windows.Forms.Application.Run(new form());     } 

When I run this, it generates a different config file (a ‘.exe.config’) and that one I can alter and have it pull the new data from the file. So I’m a bit confused. Any ideas?

Answer 1

I’m addressing this exact issue in an application I’m in the midst of prototyping. Although Decker’s suggestion of hacking the config files together should work I think this is a pretty inconvenient manual hack to perform as part of a build cycle. Instead of that I’ve decided that the cleanest solution is to just have each library parse its own library.dll.config file. Its still not perfect and it requires some extra boiler-plate code, but it seems to be the only way to get around the byzantine way that .Net handles these app.config files.