Hello Band,

If I am understanging you correctly, you are not designing your services
first. You are just coding and hoping that they work.

Step one is to define what business function each service is supposed to
perform.
Step two is to define what message that function needs. Both request and
response.
Step three is to create the shell that has those messages.

At that point you can update the web reference and the interface should not
change.

You can then do the underlying coding and test the functionality. With out
changing the messages!

Sorry, for getting on my soapbox, pun intended.

As Michael points out, the goal is to create your services in such a way
that you don't have to change the message interface.

In addition to what Michael suggests, I am finding it much easier to
maintain web services by over-simplifying the service interface itself.
Instead of having several well defined/designed web interfaces, try to
simplify the web interface to be as general as possible and move your well
defined functions/interfaces into helper classes (I think Michael is
advocating this helper class approach also).  In other words, just think of
your web service interface as being a conduit to your helper classes.  You
can turn 10 web method calls into just 1 general method call and handle the
logic in the helper classes.  Just pass in all of the request information
via *one* XML parameter and return responses via XML.  An element inside the
request XML can define the *real* function that you want to perform...your
helper classes can parse this out.  This approach allows you to expand web
service functionality without changing the reference interface.