Web Service URL should be a config setting --- it already is!

During today's webcast on web services (Wed Feb 8), there was a question related to moving your web service from your dev box to the production box.  When the web service moves, the URL will change, so what's the best way to protect your client code from this predictable change?  We shouldn't need to re-reference and recompile the client app just because the web service moved.  The answer of course is that the URL should be a .config setting.  The detail I forgot was exactly what property to set at run-time after you read the URL from the .config file. 

Duh, it's the .Url property!  Let me finish this story, and then tell you an even better one :-)  But first, the .Url property.  The client starts by createing the web service object (which is really the proxy), and then sets the URL like this:

this.server = new EmployeeWebService.Employees();

this.server.Url = Properties.Settings.EmployeeWebServiceURL;

This assumes you have defined a .config setting named EmployeeWebServiceURL.  It may seem backwards to create the web service object first  and set the URL second, since don't you need the URL to create the web service object?  Nope, because you're really just creating the proxy --- the web service isn't contacted until you make a method call, and that's when you need the URL. 

So that's the first part of the story:  create .config setting, and set the proxy's Url property before you call it.  So off I got to update my demo code in VS 2005, I bring up the Properties page, click the Settings tab, and behold, the .config setting is already there!  Turns out Visual Studio 2005 automatically defines an application-level setting for the project whenever you add a web reference.  So in my demo code, in the BusinessTierClient project, there's a setting called “BusinessTierClient_EmployeeWebService_Employees“ that contains the URL for the web service.  And the proxy is already coded to read this setting, so if you chance it, the proxy does the right thing.  Very cool.

The only problem is that this .config setting is stored in the component's app.config file, which for a DLL, isn't around at run-time.  So to make this work the way you want it to --- i.e. to expose the .config setting in the client-side .exe's config file --- you have to merge the DLL's app.config file with the client-side .exe's config file.  We've done this already with other settings, e.g. the connection string needed by Data Access Tier has to be merged into web.config (for a web service) or remotingserver.exe.config (for a remoting server host).  I'll update my demo and repost the demo + slides to the webcasts page, in this case app.config file associated with the EmployeeClientGUI has been updated, that's it.

Learning something new every day...  Cheers,