Ido Flatow's Blog

Veni Vidi Scripsi

: mex

Calling a WCF service from a client without having the contract interface

Ido Flatow — Fri, 10 Feb 2012 05:47:00 GMT

I was asked yesterday in the Hebrew C#/.NET Framework MSDN forums a tough question – is it possible to dynamically call a WCF service using only the contract name, operation name, and metadata address?

At first I agreed with the answer given in the forum – move from SOAP bindings to WebHttpBinding (“REST”). This of course makes things a lot easier, only requiring you to create a WebHttpRequest and parse the response. However the question remains - is it possible to do this in the case of a SOAP-based service endpoint?

The short answer is – YES!

The full answer is – YES, but you’ll need to do a lot of coding to make it work properly, and even more coding for complex scenarios (who said passing a data contract?)

How is it done you ask?

First let’s start with the contract – you have a simple contract that looks like so:

   1:  [ServiceContract]

   2:  public interface ICalculator

   3:  {

   4:    [OperationContract]

   5:    double Add(double n1, double n2);

   6:    [OperationContract]

   7:    double Subtract(double n1, double n2);

   8:    [OperationContract]

   9:    double Multiply(double n1, double n2);

  10:    [OperationContract]

  11:    double Divide(double n1, double n2);

  12:  }

At this point the implementation doesn’t matter, but you can assume the service compiles and loads successfully.

Second, make sure your service has either a MEX endpoint or metadata exposed over HTTP GET. Read here for more info about the difference between the two.

Third – do the client coding!!! to create the client code I took some ideas from the following links:

http://msdn.microsoft.com/en-us/library/ms733780.aspx – generating client-side type information for WCF contracts

http://www.codeproject.com/Articles/42278/Call-a-Web-Service-Without-Adding-a-Web-Reference – the same concept of dynamic calls, but for ASP.NET web services (ASMX).

   1:  using System;

   2:  using System.Collections.Generic;

   3:  using System.Linq;

   4:  using System.ServiceModel;

   5:  using System.ServiceModel.Description;

   6:  using System.Globalization;

   7:  using System.Collections.ObjectModel;

   8:  using System.CodeDom.Compiler;

9:

  10:  namespace Client

  11:  {

  12:      class Program

  13:      {

  14:          static void Main(string[] args)

  15:          {

  16:              // Define the metadata address, contract name, operation name, and parameters.

  17:              // You can choose between MEX endpoint and HTTP GET by changing the address and enum value.

  18:              Uri mexAddress = new Uri("http://localhost:8732/CalculatorService/?wsdl");

  19:              // For MEX endpoints use a MEX address and a mexMode of .MetadataExchange

  20:              MetadataExchangeClientMode mexMode = MetadataExchangeClientMode.HttpGet;

  21:              string contractName = "ICalculator";

  22:              string operationName = "Add";

  23:              object[] operationParameters = new object[] { 1, 2 };

24:

  25:              // Get the metadata file from the service.

  26:              MetadataExchangeClient mexClient = new MetadataExchangeClient(mexAddress, mexMode);

  27:              mexClient.ResolveMetadataReferences = true;

  28:              MetadataSet metaSet = mexClient.GetMetadata();

29:

  30:              // Import all contracts and endpoints

  31:              WsdlImporter importer = new WsdlImporter(metaSet);

  32:              Collection<ContractDescription> contracts = importer.ImportAllContracts();

  33:              ServiceEndpointCollection allEndpoints = importer.ImportAllEndpoints();

34:

  35:              // Generate type information for each contract

  36:              ServiceContractGenerator generator = new ServiceContractGenerator();

  37:              var endpointsForContracts = new Dictionary<string, IEnumerable<ServiceEndpoint>>();

38:

  39:              foreach (ContractDescription contract in contracts)

  40:              {

  41:                  generator.GenerateServiceContractType(contract);

  42:                  // Keep a list of each contract's endpoints

  43:                  endpointsForContracts[contract.Name] = allEndpoints.Where(

  44:                      se => se.Contract.Name == contract.Name).ToList();

  45:              }

46:

  47:              if (generator.Errors.Count != 0)

  48:                  throw new Exception("There were errors during code compilation.");

49:

  50:              // Generate a code file for the contracts

  51:              CodeGeneratorOptions options = new CodeGeneratorOptions();

  52:              options.BracingStyle = "C";

  53:              CodeDomProvider codeDomProvider = CodeDomProvider.CreateProvider("C#");

54:

  55:              // Compile the code file to an in-memory assembly

  56:              // Don't forget to add all WCF-related assemblies as references

  57:              CompilerParameters compilerParameters = new CompilerParameters(

  58:                  new string[] {

  59:                      "System.dll", "System.ServiceModel.dll",

  60:                      "System.Runtime.Serialization.dll" });

  61:              compilerParameters.GenerateInMemory = true;

62:

  63:              CompilerResults results = codeDomProvider.CompileAssemblyFromDom(

  64:                  compilerParameters, generator.TargetCompileUnit);

65:

  66:              if (results.Errors.Count > 0)

  67:              {

  68:                  throw new Exception("There were errors during generated code compilation");

  69:              }

  70:              else

  71:              {

  72:                  // Find the proxy type that was generated for the specified contract

  73:                  // (identified by a class that implements the contract and ICommunicationbject)

  74:                  Type clientProxyType = results.CompiledAssembly.GetTypes().First(

  75:                      t => t.IsClass &&

  76:                          t.GetInterface(contractName) != null &&

  77:                          t.GetInterface(typeof(ICommunicationObject).Name) != null);

78:

  79:                  // Get the first service endpoint for the contract

  80:                  ServiceEndpoint se = endpointsForContracts[contractName].First();

81:

  82:                  // Create an instance of the proxy

  83:                  // Pass the endpoint's binding and address as parameters

  84:                  // to the ctor

  85:                  object instance = results.CompiledAssembly.CreateInstance(

  86:                      clientProxyType.Name,

  87:                      false,

  88:                      System.Reflection.BindingFlags.CreateInstance,

  89:                      null,

  90:                      new object[] { se.Binding, se.Address },

  91:                      CultureInfo.CurrentCulture, null);

92:

  93:                  // Get the operation's method, invoke it, and get the return value

  94:                  object retVal = instance.GetType().GetMethod(operationName).

  95:                      Invoke(instance, operationParameters);

96:

  97:                  Console.WriteLine(retVal.ToString());

  98:              }

  99:          }

 100:      }

 101:  }

I’ve placed comments that describe the code, but basically it imports the WSDL, generates types for the contract (service + data), generates C# code from it, compiles it, and uses reflection to create a proxy and invoke the correct method.

If you want to use this technique to call methods that require a data contract, you will need some extra work to create the correct type and initialize it.

A compiled and running version of this code (+ the service) can be found here: https://skydrive.live.com/redir.aspx?cid=5ef5be1ab30a6056&resid=5EF5BE1AB30A6056!466&parid=5EF5BE1AB30A6056!129

Hope you find this piece of code useful.

Feb-12:

Just found out this great blog post that uses the same implementation only to enable calling WCF services from PowerShell.
http://www.justaprogrammer.net/2012/02/11/using-powershell-to-call-a-wcf-service/

WSDL vs MEX, knockout or tie?

Ido Flatow — Wed, 10 Aug 2011 15:12:47 GMT

When teaching WCF I am always asked about the difference between getting the service’s metadata by using the WSDL’s http get url, and getting the metadata by calling the MEX endpoint.

To answer that question we first need to understand the different parts of the configuration that affect metadata creation.

The ServiceMetadata behavior

This behavior controls whether metadata is created for the service. When this behavior is used, the service is scanned, and metadata is created for the service’s contracts (a list of operations and types exposed by the service).

If the behavior is not used, no metadata will be created for the service, and you will not be able to create MEX endpoints.

The ServiceMetadata’s httpGetEnabled flag

This flag defines whether the metadata will be accessible by an http get request. If this attribute is set to true, then a default url will be created for the metadata (usually the service’s address with the suffix of ‘?wsdl’). The url will lead you to a WSDL file containing the description of the service operations, but without the description of the data contracts – these files are accessible by different urls, usually the service’s url with the suffix of ‘?xsd=xsdN’. The list of these urls are pointed out from the WSDL file.

If you do not set this attribute to true, you will not be able to access the metadata using http get requests. If you prefer using https for the get requests, you can use the httpsGetEnabled attribute instead of the httpGetEnabled.

There are several other settings for the get options – you can read more about them on MSDN.

The MEX endpoint

MEX endpoints are special endpoints that allow clients to receive the service’s metadata by using SOAP messages instead of http get requests. You can create MEX endpoint that can be accessed through http, https, tcp, and even named pipes.

The response that you will receive when calling a MEX endpoint’s GetMetadata operation will include the content of the WSDL and all the XSD files that are linked to it.

So what exactly is the difference between MEX and WSDL?

There is no difference!

MEX and WSDL both output the same thing – a web service description language (WSDL) document, only MEX does it by getting a SOAP message over some transport (http, tcp, named pipes) and returning one message with all the parts, while the WSDL urls use http get requests and require sending several requests to get all the parts.

Don’t believe me?

The following diff diagram was produced by comparing the output of a MEX call to the output of the aggregated results gathered by calling all the WSDL related urls using http get:

As you can see, there are only several sections that are different between the files (marked in red and yellow), while most of the content is identical. Let’s look at one of these parts:

The red lines come from the MEX result, and the yellow lines from the WSDL file. The difference is because when using WSDL files, the rest of the XSD files are linked by using the <xsd:import> tag with the schemaLocation attribute. Since the MEX response includes all the XSD content in it, the import tag doesn’t include the location attribute.

As for the other different sections – they are different because the MEX response wraps each WSDL/XSD part with an xml element that does not appear in the aggregated files. These elements are part of the MEX standard declared by the W3C - surprise surprise, MEX is a W3C standard, it’s not a Microsoft proprietary spec.

So they are the same, still, which one to use?

In most cases there is no need for MEX endpoint – using WSDLs with http get is usually enough.

The “Add Service Reference” option in Visual Studio 2010 will work for both options. The same goes for the svcutil command line tool.

So when would I use MEX?

If you want to make as less calls as possible to your service in order to get its metadata (one call instead of several).
If you don’t want to use HTTP to get the metadata, but prefer using TCP or named pipes (not so common).
If you want people to ask you why you declared a MEX endpoint.

So is it a knockout or a tie? I say tie.