Connecting legacy WSE client to WCF service... with no changes to client

We have a .NET 2.0 Forms App client, which connects to a asmx web service using WSE.

We'd like to upgrade the service to WCF and utilise VS 2010 and .NET 4, however we're unable to force existing (corporate) customers to update their client software/framework, etc, and so we're in a position whereby the only way to upgrade the service is if we can maintain backwards compatibility.

We can update the app.config at the customer end, but not the executable, meaning we cannot add a new service reference.

We've been unsuccessfully trying to configure the WCF service to accept the call from the client app, without making changes to the client. I'm doubting this can even be done; of course adding a new reference in the client makes开发者_JAVA技巧 it work, but using the existing reference and trying to 'fake' it with the new service doesn't.

The config at the service end looks like this:

<bindings>
  <basicHttpBinding>
    <binding name="OnePointOneBinding" bypassProxyOnLocal="false">
      <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
        maxBytesPerRead="4096" maxNameTableCharCount="16384" />
    </binding>
  </basicHttpBinding>
</bindings>
<services>
  <service behaviorConfiguration="ServiceBehaviour" name="xyz.Services.xyzService">
    <endpoint binding="basicHttpBinding" bindingConfiguration="OnePointOneBinding"
      name="BasicBindingSvc" contract="xyz.Services.IxyzService" />
  </service>
</services>

The error we're getting is:

The message with Action 'http://webservices.xyz.co.uk/xyz/DoTest' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).

Any input gladly received

Some WSE specifics for the above:

From the wse3PolicyCache.config:

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
  <extensions>
    <extension name="usernameOverTransportSecurity" type="Microsoft.Web.Services3.Design.UsernameOverTransportAssertion, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    <extension name="requireActionHeader" type="Microsoft.Web.Services3.Design.RequireActionHeaderAssertion, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
  </extensions>
  <policy name="usernameTokenSecurity">
    <usernameOverTransportSecurity />
    <requireActionHeader />
  </policy>
</policies>

From the clients app.config:

<microsoft.web.services3>
    <security>
        <!-- Specifies the time buffer used by WSE to determine when a SOAP message is valid. -->
        <timeToleranceInSeconds value="7200" />
        <!-- Defines the default number of seconds that a SOAP message is valid after its creation. -->
        <defaultTtlInSeconds value="300" />
    </security>
    <policy fileName="wse3policyCache.config" />
</microsoft.web.services3>

I can't what else could be relevant...

EDIT:

So I did some digging and found that the WSDL of the WCF service contained the name of the interface (which I'd named 'IService') being appended into the Namespace, making it http://x.y.x/IService, when the client is expecting http://x.y.z/productname. So I changed the name of the interface to 'productname' and the Namespace is now correct. This then gave the following (new) error:

Error in deserializing body of request message for operation 'Authorise2'. OperationFormatter encountered an invalid Message body. Expected to find node type 'Element' with name 'Authorise2' and namespace 'http://x.z.z'. Found node type 'Element' with name 'Authorise2' and namespace 'http://x.z.z/productname'

The interface has the following signature:

[ServiceContract(Namespace = "http://x.y.z")] public interface productname { [OperationContract] AuthorisationDetails Authorise2(string username, string password); }

So how is the 'productname' extension being added? and more to the point, how can we get rid of it?