Is it possible to create a single file to generate a client from a WCF generated WSDL file (and any additional XSD files that are also generated from this service)
I can generate a valid client using svcutil.exe passing both the wsdl file and each xsd file, but I have a customer who is using a PHP tool to generate this and I wanted to see if I could make it easy for them by having only one file instead of many.
Yes, you can - with some clever WCF extensions. Check out these ready-made solutions:
Flatten your WSDL with this Custom ServiceHost for WCF
Improving WCF Interoperability: Flattening your WSDL
Flatten WCF WSDL on demand
Inline XSD in WSDL for WCF
Hope that helps!
Marc
It's possible.
The WSDL types element can contain multiple schema elements (each with its own namespace),
this means that types element from an imported WSDL/XSD can be put in the root document's types element under a schema element that represents the same namespace.
Other WSDL elements (message, portType, binding & service) use the root definitions element namespace, so these imported elements from different namespaces cannot remain under different namespaces when put in the same document.
Note however that only the types namespaces are used for the construction of SOAP messages, so changing
the namespace of these other elements (if necessary) will not affect the generated SOAP messages.
Related
How can I remove specific types from the the generated WSDL document of a WCF service?
I already have a System.Web.Services.Description.ServiceDescription for my service in a custom IWsdlExportExtension. Where can I find the types in the service description?
Thanks
When you're creating your .NET proxy class using the svcutil command line utility, you can define a command-line switch
/excludeType:<type>
Specifies a fully-qualified or assembly-qualified type name
to be excluded from referenced contract types.
When using this switch together with /r from separate DLLs,
the full name of the XSD class is referenced.
Short Form: /et
See the complete and freely available MSDN documentation for svcutil for more details.
I am working on a project where the customer has changed the way they are generating the wsdls that we consume. When I generate the service reference with using the original wsdl it appears that the DataContract attributes are being used in the reference.cs class. When I use the new wsdl it looks like the XmlSerializer attributes are being used.
This causes a problem because the Order of the elements is being enforced by the XmlElement attribute. From what I have read, the VS service generator will do this if there are schema elements used in the wsdl that are either ignored or forbidden.
Is there any way automated or other means that will highlight where these errors might be?
Thanks
I have a Product Datacontract with a couple of Datamembers that are part of a WCF Service. I also serialise and store this Product Datacontract in my app using the DataContractSerializer.
Now, I want to remove some of the Datamembers of the Product Datacontract when the Service metadata (WSDL) gets generated. However, I want all Datamembers from the Product Datacontract to be available when I serialise the object within my app.
What I wanna do, actually, is this: grab hold of the WSDL generation process and remove the required Datamembers from being injected into the generated WSDL.
Thanks
Mofolo
Hacking WSDL to not contain the information will not help you. Your service will still use full serialization of your types when passing them to your client and when deserializing them from your clients. Instead of hacking WSDL and WCF use DTOs for WCF service = new set of types which will contain only properties you really want to exchange with clients. Convert your master object to DTOs and vice-versa (you can either create your own custom convertors or use some framework like AutoMapper). This is the best practice.
I'm trying to use NeoLoad to generate and execute SOAP requests and upon supplying the WSDL, it doesn't seem to like the imports that they are referring to.
I'm thinking I would need to flatten the WSDL generated by the WCF service.
Are there any techniques I could use to flatten it?
I've been reading:
http://blogs.msdn.com/dotnetinterop/archive/2008/09/23/flatten-your-wsdl-with-this-custom-servicehost-for-wcf.aspx
http://blogs.thinktecture.com/cweyer/archive/2007/05/10/414840.aspx
Would this be something I should be trying out?
Yes, some clients have trouble with the (standards-compliant) way that Microsoft has implemented the WSDL and XSD.
Those two articles you mention are great starting points - they show how you can get your WCF service to render out a flattened WSDL (which includes the XSD inside it).
The same goes for WCF Extras on Codeplex, which also does a few more things in addition (most notably exporting the XML comments from your C# or VB.NET code into the WSDL). Highly recommended.
When trying to generate a proxy code for this wsdl file (from an ASMX web service) , WsdlImporter (and svcutil) is reporting an error. I thought WCF is fully backwards compatible with ASMX web services? Please help
Below is an output from svcutil (I get the same errors using WsdlImporter)
Microsoft (R) Service Model Metadata Tool
[Microsoft (R) Windows (R) Communication Foundation, Version 3.0.4506.648]
Copyright (c) Microsoft Corporation. All rights reserved.
Warning: The optional WSDL extension element 'header' from namespace 'http://sch
emas.xmlsoap.org/wsdl/soap/' was not handled.
XPath: //wsdl:definitions[#targetNamespace='http://mycompany.com/Enterprise/WebS
ervice/Finance/']/wsdl:binding[#name='FinanceServiceSoap']/wsdl:operation[#name=
'ProcessNonRefPayment']/wsdl:fault[#name='fault']
Warning: The optional WSDL extension element 'header' from namespace 'http://sch
emas.xmlsoap.org/wsdl/soap/' was not handled.
XPath: //wsdl:definitions[#targetNamespace='http://mycompany.com/Enterprise/WebS
ervice/Finance/']/wsdl:binding[#name='FinanceServiceSoap']/wsdl:operation[#name=
'ProcessRefPayment']/wsdl:fault[#name='fault']
Warning: The optional WSDL extension element 'header' from namespace 'http://sch
emas.xmlsoap.org/wsdl/soap/' was not handled.
XPath: //wsdl:definitions[#targetNamespace='http://mycompany.com/Enterprise/WebS
ervice/Finance/']/wsdl:binding[#name='FinanceServiceSoap']/wsdl:operation[#name=
'SearchPayments']/wsdl:fault[#name='fault']
Warning: The optional WSDL extension element 'header' from namespace 'http://sch
emas.xmlsoap.org/wsdl/soap/' was not handled.
XPath: //wsdl:definitions[#targetNamespace='http://mycompany.com/Enterprise/WebS
ervice/Finance/']/wsdl:binding[#name='FinanceServiceSoap']/wsdl:operation[#name=
'GetPayments']/wsdl:fault[#name='fault']
**Error: Cannot import wsdl:binding**
Detail: The given key was not present in the dictionary.
XPath to Error Source: //wsdl:definitions[#targetNamespace='http://mycompany.com
/Enterprise/WebService/Finance/']/wsdl:binding[#name='FinanceServiceSoap12']
**Error: Cannot import wsdl:port**
Detail: There was an error importing a wsdl:binding that the wsdl:port is depend
ent on.
XPath to wsdl:binding: //wsdl:definitions[#targetNamespace='http://mycompany.com
/Enterprise/WebService/Finance/']/wsdl:binding[#name='FinanceServiceSoap12']
XPath to Error Source: //wsdl:definitions[#targetNamespace='http://mycompany.com
/Enterprise/WebService/Finance/']/wsdl:service[#name='FinanceService']/wsdl:port
[#name='FinanceServiceSoap12']
You didn't ask for this, but it may help you more in the end....
The WSDL you've provided is over-designed and under-architected.
There is a unique namespace for just about every complexType defined in the WSDL. This is unnecessary. You do not need an XML namespace to hold the definition of the Transaction message. Waaaaay too many namespaces. When I looked at it, I saw justification for only one namespace (http:///blahblah/Finance/). You may need more, but certainly you do not need so many. The vast number of namespaces is one reason the wsdl.exe tool crashed - it simply cannot handle it.
There is no modularity. The XML Schema should be separate from the WSDL. For those namespaces that are justified, use a separate .xsd file for each, and perform an xsd:import for those schema. It could be you have a single XSD file.
You've got complexTypes that derive from common base types, but nothing in the base types. No message Id, no message version. This seems like trouble.
The WSDL as provided does not map the porttype to the binding. This is one reason the wsdl.exe will not generate code from it. wsdl.exe looks for a name attribute on the wsdl:input element in the porttype, which must match the name attribute on the wsdl:input on the binding.
You've got too many bindings. Are you really going to need SOAP1.1, SOAP1.2, HTTPGET and HTTPPOST? Really? Pick one and stick with it.
What to do now?
You don't control the ASMX, I suppose, and you don't have access to the code. What I would do is manually re-work that WSDL so that it makes sense - separating all those schema into separate .xsd files. Then start with a simple subset of the WSDL, and get it so that it works. Iteratively add back the more complex pieces until you have what you need.
wsdl.exe crashes when importing this WSDL, so there must be something really wrong with. Even a .NET 2.0 client cannot consume it. Could you post the code of the web service?