We have a xsd file in which the contracts are already defined. We use xsd.exe to generate classes for our WCF service, and use the XmlSerializerFormat for our webservice again.
It seems to me, that this is a weird thing to do, to have WCF generate a new XSD for the classes which the xsd.exe generated for us, while we have already have our XSD definition right there for the taking..
While xsd.exe does a nice job of generating classes for us, it also simplifies complextypes as you can see in my previous question; meaning, the xsd actually changes a bit when it generates classes and are used in the webservice again; the ArrayOfStringXXX problem..
Can we tell the WCF service to use our own xsd file for its contract, instead of generating a new contract based on what the xsd.exe delivers?
What I tried:
I already looked at this sample: IWsdlExportExtension interface sample which seems promosing, but I was not able to replace the xsd in the export method, because it was never
called.
TL;DR: Can we point our WCF service to our own xsd file, instead of letting it generate it's own?
Thanks
You can use tools like WSCF.blue to generate the data contract classes from your XSD file. I have experience from this and it works OK for most cases. See this blog for a good explanation.
There are also other tools that enable this, see this question for some suggestions.
There also seems to be a new option in Visual Studio 2012 for this, see the documentation. I haven't checked this out myself.
This development method is referred to as contract first, so you will find yet more info on Google :-)
Related
I have been following this tutorial to add protobuf-net to my WCF project. I have a shared DTO library. Both server and Client use those DTO classes. I have attributed all my Service methods with [OperationContract] attributes, but i have not assigned any [DataContract] attributes on my DTO classes.
I added the protobuf-net Nuget package and added the configuration to the web.config.
I am using IIS Express to test my service, and thought that i should be ok with what i had done so far. However, after testing a few calls, i noticed that i forgot to add protobuf-net to my client and yet everything worked as expected (ie. no errors from serialization or deserialization).
I suspect that protobuf is not used in my program at all, and that i am missing something. I'd like to avoid using [DataContract] attributes but i could live with adding them, if that is what is need to get protobuf-net working.
What else am i missing?
A year ago I faced the same problem, where protoBuf seems to be an excellent option, with WCF it has some shortcomings.
I created an open source project to overcome these shortcomings, it uses protobu-net library and adds functionality to it, such that you don't need to share assemblies anymore with client. It however again requires you to put DataContract attributes though currently.
You can give it a try: https://github.com/maingi4/ProtoBuf.Wcf
DISCLAIMER: I am creator and owner of the above project.
I need to create a .NET web service that accepts xml, uses this to query a database, and then returns xml. I have been given xsd files for the request and response. Could someone point me in the right direction for where I start from or an example?
I haven't used WCF before so would prefer to use a simple asmx file to do this. I know how to get the data from the database, so it's the xml and web service bits where I'm lost.
I've tried googling this for a while but don't know where to start. Thanks.
The problem you have is that asmx and WCF are both code-first web service technologies. What this means is that you generally start with classes and the web service stack takes care of exposing your types as XML across the wire.
You are starting with a schema, which is not code. So if you want to use asmx/wcf you need to model your schema in code. You can do this by inferring a class structure from your schema using xsd.exe (or svcutil.exe for WCF).
Alternatively you can model your classes by hand based on the schema definition.
Once you have your classes then you can add declarative attributes to the code (See http://msdn.microsoft.com/en-us/library/83y7df3e.aspx for asmx, DataContract and DataMember for WCF). These attributes control:
how an incoming stream of XML is deserialized to a type when a service request is received, and
how instances of your response types get serialized to XML when passed out of your service
The problem with this approach is that getting your XML to validate against your XSD schemas will be a little bit hit and miss, as you cannot rely 100% on class inference from XSD, and additionally you may miss some fine detail if you are modelling it by hand.
Whichever way you do it you need to make sure that your request and response class instances cleanly serialize into XML which will validate against the XSD schemas you have been given.
Also look at a framework called WSCF-Blue which allows you to do contract-first web service design: http://wscfblue.codeplex.com/
Good luck, if you need any more detail about this please let me know via a comment.
From what I can understand, you need to build a webservice, which will accept XML as input, do some processing and spit out XML.
I assume you have a basic understanding of XML but dont know anything about XSD. In very simple terms, XSD is a document which is used to validate a XML file. Think of it a rule book for how XML file should be structed, you can read more about XSD from W3schools. Dont worry about the XSD to much right now. Get a few sample XML documents, which you need to accept as input and output. Build a console application to parse the sample XML file and get the results from the database. Then use the results to build the output XML by looking at the output sample XML. Once you have that completed, then you can use the .NET classes to validate your input and output XML from the XSD you have.
You can look at this answer to see how validation is done.
Once that is done, you can create your web service to return the XML as string.
Hope this help.
I have generated a class using wsdl.exe from the wsdl file.
I inspected the generated code and there is like 3-4 methods available but I guess only by soap protocol(I'm just guessing & probably wrong) which is defined with the attribute above like:
[System.Web.Services.Protocols.SoapDocumentMethodAttribute(etc..)]
Simply, I want to create a dummy class from the wsdl and use its methods.
Thanks in advance.
I would recommend using svcutil.exe instead of wsdl.exe
Using svcutil makes it really easy to make a "dummy" class (which I am reading as a stub or mock) as it generates an interface as well as a proxy.
So, for example,
svcutil.exe http://www.restfulwebservices.net/wcf/CurrencyService.svc?wsdl
will generate an interface called ICurrencyService and a CurrencyServiceClient.
The visual studio command prompt has an exe that should allow you to do this.
wcftestclient.exe [service end point address]
hopefuly thats what you mean.
I'm using DataContractSerializer to serialize/deserialize my classes to/from XML. Everything works fine, but at some point I'd like to establish a standard schema for the format of these XML files independent of the actual code. That way if something breaks in the serialization process I can always go back and check what the standard schema should be. Or if I do need to modify the schema the modification is an explicit decision rather then just a later affect of modifying my code.
In addition, other people may be writing other software that may not be .NET based that would need to read from these XML files. I'd like to be able to provide them with some kind of documentation of the schema.
Is there some relationship between a DataContract and an XSD schema. Is there a way to export the DataContract attributes in classes as an XSD schema?
Yes, you can use XsdDataContractExporter.
An example is provided in the MSDN article Exporting Schemas from Classes.
Svcutil.exe can "export metadata for compiled data contracts".
There is relationship between DataContract and XSD:
The DataContractSerializer maps CLR types to XSD when metadata is exported from a Windows Communication Foundation (WCF) service using a metadata endpoint or the ServiceModel Metadata Utility Tool (Svcutil.exe). For more information, see Data Contract Serializer.
The DataContractSerializer also maps XSD to CLR types when Svcutil.exe is used to access Web Services Description Language (WSDL) or XSD documents and generate data contracts for services or clients.
You can get the XSD(s) at run-time as well, even in your browser, by setting up a MEX endpoint.
The WSDL by default will contain references to XSD(s) that can be accessed through the endpoint as well.
You might be able to generate schema files from DataContracts using the svcutil.exe tool that comes with Visual Studio.
svcutil myAssembly.dll
- Generate metadata documents for Service Contracts and associated types in an assembly
svcutil myServiceHost.exe /serviceName:myServiceName
- Generate metadata documents for a service, and all associated Service Contracts and data types in an assembly
svcutil myServiceHost.exe /dconly
- Generate metadata documents for data types in an assembly
I believe I messed with this at one point in the past, and may or may not have gotten it to work. Another easy way to generate schemas is to stand up a WCF service that uses your data contracts, and access the WSDL. The WSDL will import all the xsds for the DataContracts.
Building an app that is relying on a 3rd party provider who has a very verbose set of SOAP services (we're talking 50+ WSDL files). Each individual WSDL however has numerous shared type declarations. When generating client code with wsdl.exe, there used to be a /sharedtypes flag that would merge duplicate entries if a type was found several times.
When I attempt to generate my client code, I bomb on these overlapping types that the 3rd party includes in all their WSDL files.
svcutil /t:code /importxmltypes [mypath]/*.wsdl
Results in error messages alluding to the type collisions. For example, a couple samples of the error messages below:
Error: There was an error verifying some XML Schemas generated during export:
The simpleType 'http://common.soap.3rdparty.com:CurrencyNotation' has already been
declared.
Error: There was an error verifying some XML Schemas generated during export:
The complexType 'http://common.soap.3rdparty.com:NumberFormat' has already been
declared.
I do not have control over the output of the WSDLs. I do not want to have to edit the WSDLs by hand for fear of an error that breaks in a fashion at runtime that would be highly difficult to track back to our editing of the WSDL files. Not to mention that there are 50 some WSDL files that range from 200-1200 lines of XML. (Remind me again why we thought SOAP was the great salvation to us all back in the late 90s?)
Try specifying all the WSDLs in one command:
svcutil http://example.com/service1?wsdl http://example.com/service2?wsdl ...
This should automatically take care of duplicate types. Another option is to take a look at the /reference command switch:
/reference:<file path> - Add the specified assembly to the set of
assemblies used for resolving type
references. If you are exporting or
validating a service that uses 3rd-party
extensions (Behaviors, Bindings and
BindingElements) registered in config use
this option to locate extension assemblies
that are not in the GAC. (Short Form: /r)
This means that if you already have some types defined in some assembly you may include this assembly and svcutil will exclude types from it to avoid duplicates:
svcutil /reference:someassembly.dll http://example.com/service?wsdl
I was having similar problems. By defining different CLR namespaces for the different xml namespaces (using the /namespace argument of svcutil) i was able to get it working.
/namespace:http://www.opengis.net/gml,OpenGIS.GML
I have been using wsdl.exe to get round this because I work with some SOAP webservices which define the same data transfer objects at different endpoints. So I use wsdl.exe because it has the sharetypes switch. I'm not a WPF developer so I don't really care that the output does not implement IWhatever for WPF, but the classes generated are all partial so you can do some work to implement interfaces you care about in a separate file.