Best practices for using WSCF.blue and other WCF bindings?

Feb 7, 2012 at 8:03 PM

Since the basicHttpBinding is the only binding that WSCF.blue will generate into the WSDL, what are you other developers doing if you need to provide a different binding, for example WSHttpBinding ?

I can think of only two options:

  1. Add config settings for the WSHttpBinding and allow .NET to generate the WSDL
    (although, this is not completely Contract First because the WSDL contract is being generated)
  2. Add config settings for the WSHttpBinding and have .NET generate a WSDL, then save the WSDL to a file.  Next, disable the .NET generated WSDL and point the service to the saved WSDL file using serviceMetadata externalMetadataLocation attribute.
    (The extra step of saving the WSDL is manual and would have to be done each time a schema or binding was changed, but then the service is still Contract First and based on a non-changing contract)

A few questions come to my mind:
What best practices are there for using WSCF.blue and other WCF bindings?

Am I unaware of an existing capability of WSCF.blue to automate this for me? 

Can thinktecture add support for additional bindings into the tool (for example, some of the System-Provided Bindings like WSHttpBinding and NetTcpBinding)?

Any feedback will be greatly appreciated!

        ~WJ

Jul 23, 2014 at 2:47 PM
Bump is there any way out of this?
Jul 23, 2014 at 4:34 PM
Ultimately, we decided to use WSCF.blue to generate the service code, then we modify the config settings to the WCF binding we want, and just let .NET generate the WSDL. It isn't a fully Contract First solution, but it is a simple process that works.