One slight problem I’ve discovered is that the C# types we use in the ReceiveRequest activity are generated from a custom XSD and the WSDL generated by the workflow service doesn’t reference that schema but generates a new one. Normally this isn’t that much of a problem, simply create a custom WSDL and set the externalMetadataLocation option in the web.config:

<behavior name="MyServiceBehavior">
   <serviceDebug includeExceptionDetailInFaults="true" />
   <serviceMetadata httpGetEnabled="true" externalMetadataLocation="../MyService.wsdl" />
</behavior>

Contrary to popular belief, this doesn’t work! The workflow service still gives it’s WSDL as being MyService.xamlx?wsdl instead of the custom WSDL. After some Google-ing (is that a word?) I found that there was something missing: a binding. More specific: a mexHttpBinding. It seems that without specifying the Metadata Exchange the workflow service will continue to provide it’s own idea of the WSDL and ignores the WSDL specified in the externalMetadataLocation.

Fortunately the fix is easy. Add a new endpoint to the service configuration that uses the mexHttpBinding:

<service name="MyService" behaviorConfiguration="MyServiceBehavior">
   <endpoint binding="mexHttpBinding" contract="IMetadataExchange" address="mex" />
</service>

After adding this and refreshing the workflow service in the browser it now correctly shows the custom WSDL!