none
Namespace mangling in WCF RRS feed

  • Question

  • I've got two related questions:

    (1) Let's assume I've got two WCF services with the contracts

    Company.Product.ServiceModule.IService01
    Company.Product.ServiceModule.IService02

    Now I'll have the svcutil building client code and client configuration for me. If I specify my service namespace "Company.Product.ServiceModule" also for the client namespace and have *only one* client namespace that *exactly matches* the service namespace, all is well.

    Now I want to reference my second service "IService02". Svcutil now forbids me to specify the *same* namespace "Company.Product.ServiceModule". So for more than one service to be referenced, I am forced to use client namespaces that are *different* from the service namespaces, let's say

    Company.Product.ClientModule.IService01
    Company.Product.ClientModule.IService02

    This is seemingly legit as far as svcutil is concerned, because it doesn't object any more. But now, the contract generated by svcutil in the client endpoint configuration is "Company.Product.*ClientModule*.IService01", which - of course - doesn't match the service contract. So now when running my application I'm getting the error "Could not find endpoint element with name 'BasicHttpBinding_IService01' and contract 'Company.Product.ClientModule.IService01' in the ServiceModel client configuration section."

    Which is utterly plausible to me, because the server obviously *doesn't have* such a contract.

    How is this supposed to work?

    (2) If I specify a client namespace different from the service namespace, svcutil *concatenates* the namespaces when generating the client code to "Company.Product.ClientModule.Company.Product.ServiceModule.IService01", which is unwanted, breaks the rest of my code and thus is *manually fixed* by me. Manually fixing this may be an error, but I don't get the logic by which svcutil operates, so I'm short of a better idea.

    So again: how is this supposed to work?

    (I'm using VS 2013 with .NET 4.0 on Win 7)

    <object data-extension-version="0.5.0.161" data-install-updates-user-configuration="true" data-supports-flavor-configuration="true" id="__symantecPKIClientMessenger" style="display:none;"></object>
    Tuesday, May 9, 2017 2:12 PM

Answers

  • Hello Ingbert Jüdt,

    Let me know if I misunderstood your post but this is what I think you are looking for:

    Keep in mind that the server is the law so the clients must adhere to the server.  So get your service definition correct first (as you have done).

    What you are after then is good looking contracts in your clients.  The problem is svcutil has limited support in generating these contracts.  It prevents classname collision by generating a unique namespace.  The datacontracts themselves are correct (if you view them).  So you have three ways to approach this.

    1. Attempt to get svcutil to generate the contract correctly (using /reference and/or specifying the services at the same time)
    2. Use svcutil to generate the contracts and then update them to have the same namespace.  This works but everytime the contracts change you have to repeat this step.
    3. Create a shared assembly with the contracts in it.  Then both the service and the client reference the same assembly.  No need for svcutil then.

    Hope this helps.


    Cheers, Jeff

    • Marked as answer by Ingbert Jüdt Wednesday, May 10, 2017 10:03 AM
    Tuesday, May 9, 2017 9:54 PM

All replies

  • Hello Ingbert Jüdt,

    Let me know if I misunderstood your post but this is what I think you are looking for:

    Keep in mind that the server is the law so the clients must adhere to the server.  So get your service definition correct first (as you have done).

    What you are after then is good looking contracts in your clients.  The problem is svcutil has limited support in generating these contracts.  It prevents classname collision by generating a unique namespace.  The datacontracts themselves are correct (if you view them).  So you have three ways to approach this.

    1. Attempt to get svcutil to generate the contract correctly (using /reference and/or specifying the services at the same time)
    2. Use svcutil to generate the contracts and then update them to have the same namespace.  This works but everytime the contracts change you have to repeat this step.
    3. Create a shared assembly with the contracts in it.  Then both the service and the client reference the same assembly.  No need for svcutil then.

    Hope this helps.


    Cheers, Jeff

    • Marked as answer by Ingbert Jüdt Wednesday, May 10, 2017 10:03 AM
    Tuesday, May 9, 2017 9:54 PM
  • Hello Jeff,

    thanks a lot for your advice! Manually correcting the service yields a positive result most quickly, but I will consider refactoring the contracts into a separate assembly later on. Most important for me is that I now know what I can expect from svcutil and what not.

    Best regards

    Ingbert<object data-extension-version="0.5.0.161" data-install-updates-user-configuration="true" data-supports-flavor-configuration="true" id="__symantecPKIClientMessenger" style="display:none;"></object>
    Wednesday, May 10, 2017 10:03 AM