views:

522

answers:

3

I have multiple projects containing multiple WCF service references.

My WCF services are in a state of flux so I frequently have to go around and update all of my service references.

Is there a way to achieve this as a single action?

+4  A: 

Well, rather than use the IDE, you could use svcutil at the command line via a build script? Then all you have to do is re-execute the bat/script/whatever...

Marc Gravell
This is what we do at my shop. We always rebuild all the proxies and references in Visual Build...
Jason Punyon
I'm voting for this as well. Build automation is the way to go!
Terry Donaghe
A: 

I prefer to avoid setting references to WCF services through the IDE mechanism, if I can avoid it. I would much rather simply provide proxies in a separate class library. That way, what will normally happen is that an update from the source code repository will break the local copy's build and it will then be obvious that something needs to change. After all, it should be as painful as any public interface change. I'm not a fan of svcutil.exe.

EnocNRoll
+1  A: 

I don't use generated proxies at all. I just have a shared assembly between my client and server that defines service contract interfaces + the following sleight of hand.

    // this class can be used to instantiate a unidirectional proxy (one that doesn't require callbacks from the server)
    public class UniDirectionalServiceProxy<T> : System.ServiceModel.ClientBase<T> where T : class
    {
        public UniDirectionalServiceProxy()
        {
        }

        public UniDirectionalServiceProxy(string endpointConfigurationName) :
            base(endpointConfigurationName)
        {
        }

        public UniDirectionalServiceProxy(string endpointConfigurationName, string remoteAddress) :
            base(endpointConfigurationName, remoteAddress)
        {
        }

        public UniDirectionalServiceProxy(string endpointConfigurationName, System.ServiceModel.EndpointAddress remoteAddress) :
            base(endpointConfigurationName, remoteAddress)
        {
        }

        public UniDirectionalServiceProxy(System.ServiceModel.Channels.Binding binding, System.ServiceModel.EndpointAddress remoteAddress) :
            base(binding, remoteAddress)
        {
        }

        // new keyword allows us to supercede the inherited protected member and make it public.
        public new T Channel
        {
            get
            {
                return base.Channel;
            }
        }
    }

Looks familiar, right? Construct that object and then you just change your calls to use the Channel member.

You can also use ChannelFactory to get much the same result (I presume they made Channel a protected member of ClientBase to encourage developers to use ChannelFactory), but I prefer this mechanism since you end up with a single object that encapsulates communication control and the calls across the wire. Obviously, this way you lose the async methods from svcutil, but that's pretty easy to do yourself with delegates anyway.

John Ketchpaw