views:

48

answers:

2

Hi all,

I have a web reference added to a C# .NET project. The URL for the web reference needs to change depending on whether I'm building for a development, staging or production environment. I've set the web service to be dynamic, which supposedly means it takes the URL from my app.config file.

When I perform a build it overwrites the app.config with the required file which contains the correct URL (different file for each of dev/staging/production.) I then go into the solution properties and make sure the Settings.settings file is updated with the app.config changes. However when I view the properties for the web service, it is still showing the old URL, despite it being dynamic, and supposed to be reading from my settings file (even after closing and reopening the project/solution.) The app.config and the settings file all have the new URL, but the web reference doesn't notice it has changed.

If I do a build it ignores the URL in the settings file and tries to connect to the last URL manually typed into the web reference's properties. Typing a URL into these properties correctly updates the app.config and .settings files, so the link is definitely there.

I'm a bit new to .NET but it seems to me the purpose of setting the service to be dynamic is so that you can change the URL elsewhere, but when I do this it just gets ignored! Am I doing something wrong?

A: 

UDDI might help here: ask an UDDI service for the correct URL and have seperate UDDI servers per environment where you use the name UDDI service name to map to the correct URL for the environment. Then you just have the one .config file for all environments. See MSDN for some examples.

peSHIr
Thanks for the reply. It seems a little overkill to run three UDDI servers for one application! Unfortunately I don't have access to the hosting environment so this probably wouldn't be possible for me anyway.
Malvineous
A: 

Does this work for you? http://stackoverflow.com/questions/2245792/can-you-change-the-location-endpoint-of-a-dynamic-web-reference-at-run-time-in-n

Albert T. Wong
It certainly looks like a valid workaround for the broken behaviour - thanks!
Malvineous