Web References how to config to read URL from config?

[Bob]

It's great that VS.NET makes it so effortless to add a web reference to a
web service. The problem is, I haven't figured out a way to configure the
URLs (or simply switch the references to another web reference) easily when
I move my app from development, to staging, to production, as I have
corresponding environments for the web services too. So far what I have
done is copying the Reference.cs file out and creating a separate class by
modifying it, letting it read the URL from say, my app config file. This is
manual and if I have a change to the service, I have to manually modified
these proxy classes too. I just keep thinking if VS.NET made it this far,
allowing a dynamic config of the web reference shouldn't be too difficult.
Yet I can't figure out how to do this. Could anyone give me some
suggestions?

Thanks
Bob

 

[Mickey Williams]

There are many reasons to go down the road of manually crafted proxies, but
this isn't one of them. Change the URL Behavior property for the web
reference to Dynamic - a app settings entry will be created and added to
your config file - changing the URL in the app settings value will direct
the client proxy to the new endpoint.
(Click the web reference in the solution tree and press F4).

 

[Jerry Goldin]

I actually set it as static, such that there is no binary difference between
any of the files on my development machine and the production version.
Having different versions of the config file seems to me to be just one more
source of potential problems when creating the set of distribution files.

Instead, I add an entry in the HOSTS file for the URL when I want to run the
service locally.

Just an alternative solution, I thought I would share.

 

[Bob]

Jerry, could you elaborate a little more on what you said? Isn't it true
that the development machine would almost always have newer binary than the
production if new features are being added frequently?

Keeping the config file different on dev vs. production is definitely a pain
but I'm not sure it can be avoided, different database connection strings
would be a very common reason for them to be different.

I'd definitely like to know more about what you do to reconcile these
things.

Thanks
Bob

 

[Jerry Goldin]

Bob, it is true that the files during development typically are newer than
the currently released version, but my concern is keeping my working copy
identical to what I have under source-control. I have a setup with
SourceSafe's working directory mapped to my development directory and I
would like to avoid a case where I accidentally get the wrong file checked
in (or accidentally have it replaced with the production version).

I am not in all cases and all projects able to do this, but to the extent
that I can, I try to keep archived files identical to the files I use during
development.

 

[Bob]

Thanks Mickey. That's what I was looking for.

Since I have the proxy classes in my data layer class library assembly,
changing it to dynamic created an app.config file in my project. I guess I
can add the same app settings entry to the web.config of my web project that
will ultimately use the assembly. What are some of the examples you think
manually crafted proxy classes are necessary? I have been struggling with
some of the things that I'm not sure whether to edit the proxies or create
another layer.

Thanks
Bob

 

[Mickey Williams]

What are some of the examples you think

manually crafted proxy classes are necessary? I have been struggling with
some of the things that I'm not sure whether to edit the proxies or create
another layer.

Manually created proxies are useful when:
- Sharing types among multiple endpoints
- You want to subclass the client proxy (instead of
SoapHttpClientProtocol)
- You don't care for the current method implementation, or you want a
different set of methods - maybe you want to get rid of the pseudo-asynch
methods in the auto-generated proxy, or you want to inject logging or
validation code.

We typically use manual proxies once we leave the prototyping stage, but
that's partially because we tend to be fairly stable along our interfaces.
The largest problem you'll face is keeping the manual proxy synchronized
with the proxy target.

 

[Saravana [MVP]]

You can check out following article's to know more about dynamic webservices
http://www.codeproject.com/useritems/DynamicWebServices.asp?print=true
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/ht
ml/vxwlkwalkthroughredirectingapplicationtotargetdifferentxmlwebservicedurin
ginstallation.asp