Can I change namespace of WCF ServiceContract interface without changing the service?

Is there a way to change the .NET namespace of a WCF ServiceContract Interface yet still make the WCF service backwards-compatible with clients that are using the old (identical except for namespace) ServiceContract? For example, suppose I have (in vb.net):

Namespace MyCompany.MyPoorlyNamedProject
    <ServiceContract(Name:="ThingService")> _
    <CLSCompliant(True)> _
    Public Interface IThingService
        ...
    End Interface
EndNamespace

And I want to change that to

Namespace MyCompany.MyProject
    <ServiceContract(Name:="ThingService")> _
    <CLSCom开发者_如何学Pythonpliant(True)> _
    Public Interface IThingService
        ...
    End Interface
End Namespace

Without changing the service at all.

I tried just doing so, but my xsds referred to from the wsdl show the new namespace name, which seems to be an incompatibility.

Any ideas?

---

As long as the name and (XML) namespace of your service contract don't change - sure! WCF services really don't care about the .NET internals of how they're implemented.

This works as long as the client side attaches to your service using the standard Add Service Reference method (interrogating the service's metadata to create a separate client-side proxy) - in that case, the client-side proxy has no knowledge of any service-side .NET namespaces... you can change those on the service side and redeploy your service files - the client will continue to work.

The only place you'll need to make an adjustment is in the config of your service side (in web.config if you're hosting in IIS, in your hoster's app.config otherwise):

• the <service> tag's name= attribute has the service class' fully qualified .NET type name (including .NET namespace)

• the <endpoint> tag's contract= attribute has the service contract's fully qualified .NET type name (including .NET namespace)

This doesn't work, obviously, if you share a common assembly with the service contract - in that case, the client side will be tied to the .NET namespace of those contract files in a common assembly and if those change, the client won't work anymore..