I had a maddening day yesterday, all thanks to .NET configuration files and webservices.

Basically, I have an application has an ASP.NET front end that talks to webservices, and the front end also references a library that in turn references webservices. Nothing too bizarre here. It would be nice to only be referencing the webservices from the library, but that's not the point and it doesn't solve the problem.

If you try to set something like this up in Visual Studio 2005, you'll notice that the library get's a little pretend app.config file. Inside the app file is the endpoint address for the webservice. This all seems perfectly normal until you realise that libraries can't have configuration files.

When you bundle this sucker up and deploy it, the only endpoint you can change is the endpoint used by the webservices, as that's the endpoint in the web.config file.

So what does the library use? Well, it uses the setting it was compiled with. If you dig through the setting related files, you'll notice that there's an attribute that specifies a default value for the setting, and this default value will be whatever endpoint you were pointing at when you added the reference to your project.

And what's the fix?

Well, there's two ways (there's probably actually more, but I can't be bothered) you can go about fixing this. In the top of the web.config file is the configSections tag, which will contain at least one group, which has a section that points to the node in the config file containing the endpoint for the website. Following so far?

Copy the section tag and change the name to the qualified type name of the library web reference. Once you've done that, you can duplicate the existing endpoint configuration section at the bottom of the file and swap out the type names and endpoint values for those of the library.

The other way is to use the configSource attribute to point to an XML file that contains the relevant configuration for the library endpoint. Add this attribute to both the web.config and the libraries app.config. Then link this file to both projects and make sure it's included in the distribution for the website. If you work this way, you can still change the value through the project settings tab in the project properties and it will correctly change the value in the linked configuration file.

They'd be the two different ways I'd consider doing it. So, this could be a trap for young players, and it had me uttering the F word more times per minute than should be humanly possible while I was trying to figure out why the endpoint was wrong even though the config file was right...