Generating Service Client Proxy

To consume a service you generally need a client side proxy of the service being consumed to talk to your application. Most of the time the simpler approach is to add a reference to the service in VisualStudio and let it work its magic. Eventually there will be situations where this approach is not sufficient and need more manual intervention. SvcUtil.exe (ServiceModel Metadata Utility) is a command line tool which comes as a part of the .NET Framework and does this job. In fact VisualStudio itself use this utility behind the scenes with all the right switches.

There are usually two steps involved with creating the client proxy, namely Get the Service metadata and Generate code from the metadata.

There might be two scenarios you might encounter when dealing with external Services, i.e.

1.      Hosted or Running Services. (should expose a MEX endpoint)

2.      Service assembly or library.

To generate client proxy and configuration from a compiled service assembly required two steps:

1.      Extract the service metadata as:

SvcUtil.exe /t:metadata serviceassemblyname.dll

This step would produce the WSDL and the XSDs from the assembly.

2.      Generate proxy from the metadata as:

SvcUtil.exe /t:code [path]*.wsdl [path]*.xsd /out:[path]Proxy.cs /config:[path]App.config

Now in case of a hosted/running service both steps 1 & 2 are usually combined as one as below:

SvcUtil.exe /t:code [Service URL] /out:[path]Proxy.cs /config:[path]App.config

I ran into an interesting problem when I tried to execute the above command against an IIS hosted service which exposes the MEX binding over https. ScvUtil failed to pull the service metadata and threw a “WS-Metadata Exchange Error. Could not establish trust relationship for SSL/TLS secure channel. The remote certificate is invalid according to the validation procedure.”

Now I know this is cause of the fact that the server certificate is not signed by a TrustedRootCA or installed in the trusted store. This is not unusual for development and test environments.

One option is to install the server certificate in the trusted store but I am trying to find if there is an option to override the validation procedure that the underlying protocols use to establish a secure channel. I know VisualStudio gives a warning in this case but you can still proceed if you choose to. I don’t know if there is way around with just using SvcUtil directly from command line, however for your Client side there is a work around explained below.

When a client applications trys to connect to a URI, it requests a System.Net.ServicePoint class instance through System.Net.ServicePointManager class. Each ServicePoint maintains its connection to the URI for specific time and then recycles. The ServicePointManager class has callback property (which is our hook-in point): public static RemoteCertificateValidationCallback ServerCertificateValidationCallback { get; set; } which basically verifys the remote SSL certificate used for authentication.

The sample below demonstrates how.

public class CustomCertificateValidation
    {
        CustomCertificateValidation()
        {
            System.Net.ServicePointManager.ServerCertificateValidationCallback +=
            new System.Net.Security.RemoteCertificateValidationCallback(CertValidate);
        }
        bool CertValidate(object sender,
        System.Security.Cryptography.X509Certificates.X509Certificate cert,
        System.Security.Cryptography.X509Certificates.X509Certificate.X509Chain chain,
        System.Net.Security.SslPolicyErrors error)
        {
            //Put your validation logic here
        }
    }