none
WCF: svcutil mangles mex URL RRS feed

  • Question

  • I want to update a WCF Service Reference, which is configurated for the mex URL "net.tcp://localhost:8007/MyService/mex". This fails because svcutil somehow deduces an invalid mex URL.

    The error message in VS 2013 reads: "Error 74 Custom tool error: Failed to generate code for the service reference 'MyServiceNamespace.MyService'.  Please check other error and warning messages for details."

    A lookup in svclog reveals the real error behind the above one: "The message with To 'net.tcp://localhost:8007/MyService/mex/mex' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher.  Check that the sender and receiver's EndpointAddresses agree."

    As can be seen, svcutil somehow has mangled the IMetadataExchange URL by adding an additional "/mex" to it.

    I can fix this by just removing and adding the service reference again, but I'd rather have a working update procedure. Is there any chance to get that behaviour fixed or will I have I put up with the circumstance that svcutil is again buggy?

    <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>
    Friday, July 7, 2017 9:26 AM

Answers

  • Seems that I found out the workaround myself: the referencing project missed a reference to a dependent assembly, in this case "Microsoft.Practices.EnterpriseLibrary.Common", which inhibited the necessary reflection background process. This is nevertheless treacherous, because the project wouldn't need that reference to compile. I had to add it only to avoid the respective error. Also misleading is the svclog error message: why would a missing assembly result in a mangled-up mex URL?

    So I resolved my problem in practice, but without really understanding the background.<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>
    • Marked as answer by Ingbert Jüdt Friday, July 7, 2017 10:53 AM
    Friday, July 7, 2017 10:53 AM

All replies

  • Postscriptum: trying to add the service reference completely new now also fails. The mex endpoint is recognized in the "Add Service Reference" dialog, and the interface is correctly read, but no code will be generated when hitting "OK", with the same error message as above.<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>
    Friday, July 7, 2017 9:46 AM
  • Seems that I found out the workaround myself: the referencing project missed a reference to a dependent assembly, in this case "Microsoft.Practices.EnterpriseLibrary.Common", which inhibited the necessary reflection background process. This is nevertheless treacherous, because the project wouldn't need that reference to compile. I had to add it only to avoid the respective error. Also misleading is the svclog error message: why would a missing assembly result in a mangled-up mex URL?

    So I resolved my problem in practice, but without really understanding the background.<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>
    • Marked as answer by Ingbert Jüdt Friday, July 7, 2017 10:53 AM
    Friday, July 7, 2017 10:53 AM
  • Another remark: the double mex URL error ('net.tcp://localhost:8007/MyService/mex/mex') seems completely unrelated to the problem, as it persists beyond fixing the code generation problem, and without causing discernable problems in itself.<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>
    Friday, July 7, 2017 11:00 AM
  • Hi Ingbert,

    Thanks for sharing the working around.

    If there is any other issue related with WCF, please feel free to post in this forum, and we will try our best to help.

    Best Regards,

    Edward


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, July 10, 2017 2:13 AM