WS-MetadataExchange is a wonderful thing. WCF implements this spec and provides support for it over several different transport protocols including HTTP(S), TCP, and named pipes. All you have to do is choose the appropriate MEX binding.


If you’re familiar with how bindings work in WCF, this all makes perfect sense. However, if you pull out .NET Reflector and begin looking for the various System.ServiceModel.Channels.Binding-derived classes, you might be surprised when you don’t find any.


I was surprised because when you specify MEX endpoints in configuration, there is a separate binding name for each supported MEX transport (mexHttpBinding, mexHttpsBinding,  mexNamedPipeBinding, and mexTcpBinding). The trick is these binding element names don’t map to individual classes but rather to a single class named MetadataExchangeBindings, which provides four public static methods: CreateMexHttpBinding, CreateMexHttpsBinding, CreateMexNamedPipeBinding, and CreateMexTcpBinding, as illustrated here:


public static class MetadataExchangeBindings


{


    // Methods


    public static Binding CreateMexHttpBinding();


    public static Binding CreateMexHttpsBinding();


    public static Binding CreateMexNamedPipeBinding();


    public static Binding CreateMexTcpBinding();


   


}



If you inspect the implementation of any of these methods, you’ll notice they just create one of the built-in bindings, adjusting some of the defaults, and then they override the binding name and namespace as illustrated here:


public static Binding CreateMexHttpBinding()



{


    return CreateHttpBinding();


}


private static WSHttpBinding CreateHttpBinding()


{


    WSHttpBinding binding = new WSHttpBinding(SecurityMode.None, false);


    binding.Name = “MetadataExchangeHttpBinding”;


    binding.Namespace = “http://schemas.microsoft.com/ws/2005/02/mex/bindings”;


    return binding;


}



In the case of CreateMexHttpBinding, they use the WSHttpBinding but set the security mode to SecurityMode.None. Because they’re basically just using the other built-in bindings, they probably figured it wouldn’t make sense to define completely new binding classes just for the MEX scenarios…they’re really just slightly different configurations.


Obviously this also means that you don’t have to actually use the MEX binding element names (or MetadataExchangeBinding) when configuring endpoints to use MEX. Instead you can use the corresponding built-in binding directly as long as you configure it properly for the MEX scenario (like in the example above, I have to set the security mode to SecurityMode.None when using WSHttpBinding).