WSDL.exe: Contract first
- Hello together,
I'm developing on .NET 3.0 and especially under WCF. We were discussing the Contract First Design Pattern for services under WCF. I wanted to build a service interface out of an existing WSDL definition (basic profile 1.1 compliant (ws-i)). So I used the wsdl.exe included in the .NET 3.0 SDK like the following:
This generated an ASMX compatible webservice. So I got confused and checked the version of the wsdl.exe included in the .NET 3.0 SDK. The version of wsdl.exe is stated to be for .NET 2.0 Framework. So I wondered if there will be a ported version of wsdl.exe for .NET 3.0 to build services out of the System.ServiceModel namespace?Code Snippetwsdl.exe path_to_my_wsdl /serverInterface
Any suggestions?
Thanks for your help!
Daniel
Answers
- Hello Marlon
I think I found the solution:
https://connect.microsoft.com/wcf/feedback/ViewFeedback.aspx?FeedbackID=124245
But actually this "workarround" is quiet ugly. In my point of view this functionality should be implemented in wsdl.exe...
All the best from Switzerland
All Replies
hi there,
when you program webservices for WCF you do not use the wsdl any more. now there is one tool that is used for all frameworks(remoting, webservice etc...). There is also a plugin for Visual Studio that enables you to right click "Add Service Reference"....
hope it make it more clear- hi there,
when you program webservices for WCF you do not use the wsdl any more. now there is one tool that is used for all frameworks(remoting, webservice etc...). There is also a plugin for Visual Studio that enables you to right click "Add Service Reference"....
hope it make it more clear Hello
The problem is that I use VS2005 with the CTP extension for WCF and WPF. So the visual studio plugin doesn't work correctly.
So which tool is it excatly? You didn't mention the tool.
Maybe I need to clarify that I wan't to build/rebuild a WCF service from a given WSDL service description. So I need to rebuild the datacontracts and service contracts (interfaces) from WSDL. I thought wsdl.exe was for this purpose... Or did I get this wrong?
Thanks
hi there,
sorry i forgot to mention the name of the tool... how stupid of me. Well the tool is called ScvUtil.exe... to create a proxy class from the wsdl....
go to vs command prompt..
enter
scvutil.exe http:/localhost/testwebservice/service.asmx?wsdl /out
rocy.cs
the url is the url of your web service...
this should do it ...hope it helps- Hi marlon,
Yeah I already know this tool. The wizard in VS2005 is actually nothing other than the GUI version of svcutil. But again I specify my question, sorry for being rude but maybe you misunderstood my question:
with svcutil you generate proxy classes or stubs to use in the client (to abstract from the underlying complexity of the serviceimplementation). This proxy handles the call between the client and the server. BUT I don't wan't the proxy classes! I wan't to rebuild the serviceinterface / servicecontract of a service from its wsdl definition.
so your explanation heads towards client proxy generation and believe me I already understand that
But anyway thank you for you time!
So for problem NOT solved...
best regards from switzerland
hi there,
sorry for sending you unwanted info but your post was using wsdl.exe which with wcf is not used to generate the proxy classes...
Maybe I am not understanding what you need to do yet, usually the Contract is implemented in the server app. The contact is the interface that the clients can use to communicate with the server. The clients need to use that contract so I don't understand what you mean by
"I wan't to rebuild the serviceinterface / servicecontract of a service from its wsdl definition."
Regards- Hello Marlon
No problem. Ok imagine the following scenario:
A company has an architecture department and a java and a c# department. The architecture department specifies the service interfaces by directly implementing the service in wsdl conforming to the ws-i basic profile 1.1. This wsdl files containing also referenced schemas for the datatypes / datacontracts used by this service will be sent to the two other departments and they need to build a concrete service in their corresponding programming languages.
You can imagine that building a concrete service for example in c# after this WSDL from the architecture department would require a lot of understand about WSDL and ws-i also for the engineer building the service in the c#/:NET department.
With wsdl.exe and the flags /server or /serverInterface it is possible to build either an abstract class and datacontracts or an serverinterface and datacontracts which later can be inherited or implemented by your concrete service class.
Scenario with code
Architecture department defines:
1. WSDL
Code Snippet<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions name="service" targetNamespace="http://tempuri.org/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://tempuri.org/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsa10="http://www.w3.org/2005/08/addressing" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex">
<wsdl:types>
<xsd:schema targetNamespace="http://tempuri.org/Imports">
<xsd:import schemaLocation="http://localhost:6020/DefinedServiceFromArchitectureDepartment?xsd=xsd2" namespace="http://tempuri.org/"/>
<xsd:import schemaLocation="http://localhost:6020/DefinedServiceFromArchitectureDepartment?xsd=xsd0" namespace="http://schemas.microsoft.com/2003/10/Serialization/"/>
<xsd:import schemaLocation="http://localhost:6020/DefinedServiceFromArchitectureDepartment?xsd=xsd1" namespace="http://schemas.datacontract.org/2004/07/DefinedServiceFromArchitectureDepartment"/>
</xsd:schema>
</wsdl:types>
<wsdl:message name="IService_MyMethod_InputMessage">
<wsdl:part name="parameters" element="tns:MyMethod"/>
</wsdl:message>
<wsdl:message name="IService_MyMethod_OutputMessage">
<wsdl:part name="parameters" element="tns:MyMethodResponse"/>
</wsdl:message>
<wsdl:portType name="IService">
<wsdl:operation name="MyMethod">
<wsdl:input wsaw:Action="http://tempuri.org/IService/MyMethod" message="tns:IService_MyMethod_InputMessage"/>
<wsdl:output wsaw:Action="http://tempuri.org/IService/MyMethodResponse" message="tns:IService_MyMethod_OutputMessage"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="BasicHttpBinding_IService" type="tns:IService">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="MyMethod">
<soap:operation soapAction="http://tempuri.org/IService/MyMethod" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="service">
<wsdl:port name="BasicHttpBinding_IService" binding="tns:BasicHttpBinding_IService">
<soap:address location="http://localhost:6020/DefinedServiceFromArchitectureDepartment"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
2. DataContract MyContract Schema
So as you can see it builds an ASMX compatible webservice to the "OLD" .NET 2.0 standard. But the code it should generate would look like the followingCode Snippet<?xml version="1.0" encoding="utf-8"?>
<xs:schema elementFormDefault="qualified" targetNamespace="http://schemas.datacontract.org/2004/07/DefinedServiceFromArchitectureDepartment" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://schemas.datacontract.org/2004/07/JAPIITest2_Service_WCF">
<xs:complexType name="MyContract">
<xs:sequence>
<xs:element minOccurs="0" name="Content" nillable="true" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:element name="MyContract" nillable="true" type="tns:MyContract"/>
</xs:schema>
I know this would be easy to rebuild by hand but this als only an easy service with one method and one datacontract.
So that's where wsdl.exe should work now. But it generates:
Code Snippet//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:2.0.50727.832
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
using System;
using System.ComponentModel;
using System.Diagnostics;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Xml.Serialization;
//
// This source code was auto-generated by wsdl, Version=2.0.50727.312.
//
/// <remarks/>
[System.CodeDom.Compiler.GeneratedCodeAttribute("wsdl", "2.0.50727.312")]
[System.Web.Services.WebServiceBindingAttribute(Name="BasicHttpBinding_IService", Namespace="http://tempuri.org/")]
public interface IBasicHttpBinding_IService {
/// <remarks/>
[System.Web.Services.WebMethodAttribute()]
[System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://tempuri.org/IService/MyMethod", RequestNamespace="http://tempuri.org/", ResponseNamespace="http://tempuri.org/", Use=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]
[return: System.Xml.Serialization.XmlElementAttribute(IsNullable=true)]
string MyMethod([System.Xml.Serialization.XmlElementAttribute(IsNullable=true)] MyContract dataContractValue);
}
/// <remarks/>
[System.CodeDom.Compiler.GeneratedCodeAttribute("wsdl", "2.0.50727.312")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://schemas.datacontract.org/2004/07/DefinedServiceFromArchitectureDepartment")]
public partial class MyContract {
private string contentField;
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(IsNullable=true)]
public string Content {
get {
return this.contentField;
}
set {
this.contentField = value;
}
}
}
Code Snippetusing System;
using System.ServiceModel;
/// <remarks/>
[ServiceContract(Name="BasicHttpBinding_IService", Namespace="http://tempuri.org/")]
public interface IBasicHttpBinding_IService {
/// <remarks/>
[OperationContract(Action = "blblba", Response = "blabla", Name = "MyMethod")]
string MyMethod(MyContract dataContractValue);
}
/// <remarks/>
[DataContract(Namespace="http://schemas.datacontract.org/2004/07/DefinedServiceFromArchitectureDepartment")]
public class MyContract {
private string contentField;
[DataMember]
public string Content {
get {
return this.contentField;
}
set {
this.contentField = value;
}
}
}
Do you see now the problem? It seams as the wsdl.exe has not been ported yet to .NET 3.0. So wsdl.exe /server or serverInterface should use the System.ServiceModel namespace in WinFX instead of System.Web Namespace.
Thanks for your help
hi there,
ok! now i understand.... I am not sure that this will help but when using svcutil.exe there are similar tags as the wsdl.exe for example /dataContractOnly this instructs the tool to just get data contracts...
http://msdn2.microsoft.com/en-US/library/aa347733.aspx
again sorry if am not able to tell you want you want to hear ...
- Hy Marlon,
I already checked the msdn site you refered before. This only helps for rebuilding the datacontracts but not for the service interface....You see there's actually no tool that helps with that and the tool which should help is not ported! I think wsdl.exe got forgotten... Do you know an adress where I could raise this issue to microsoft?
Thanks
I have no idea.... try to find a forum moderater he will tell you what to do...- Hello Marlon
I think I found the solution:
https://connect.microsoft.com/wcf/feedback/ViewFeedback.aspx?FeedbackID=124245
But actually this "workarround" is quiet ugly. In my point of view this functionality should be implemented in wsdl.exe...
All the best from Switzerland

