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
Related
I want to download xsd specifications from a web service and automatic converting (serialize) these schemas to classes (visual studio - vb.net). If the organization that is responsible for the xsd schemas alter them in a way that only my class corresponding to the xsd have to be altered (not the rest of my code) I would like to automatic update my xsd corresponding class. Is this possible? If so, can somebody tell me how to do it?
Thanks!
I use vs2010. What I want to do is: call a web service where I can send in an input parameter to the service which specifies the xsd I want to retrieve (the service is GetShemaDefenition and returns an object with the schema specification in a string property of the object). I den have to read the xsd string from the string property and convert this to a class representation of this xsd specification. Is it possible to do this automatically? I have done this manually by using xsd.exe. If the owner organization of the xsd has altered the xsd specification, I have to test if there is a new specification, and if there is I have to build a new class representation of this xsd? Is it possible to do what I want? And how would I know if it has been a big change in the xsd which also affect other parts of my code, not just the class representation of the xsd?
Tanks a lot for your reply! So what you are saying, if I understand you correct, is that there is not a good solution for automating this functionality because if the xsd change I most likely (in some occasions’) have to change my code manually? So I have to choose, either in my application or in my intermediate service? But what is the purpose for providing the xsd in a web service? What can I use the web service for? I just wondering, maybe it is clear but I am new to web services and is eager to learn more.
Update:
Thanks! But can you explain a little bit more. What I have to do is: I use one web service where one of the properties is a string. The string is an XML inside a CDATA block. The organization which provides the web service will not pares the xml inside the CDATA block but instead forward this to another organization that will use the xml data. The organization which uses the xml data specifies the xsd schem that I have to follow to generate my xml correct. This is the xsd schema I can get from another web service. I don’t really understand what I can do with this xsd file from the web service. What can I do with it and why do I want to download it from the web service, when I can’t use it automatically? Because I have to manually do the changes when the xsd changes I can easily download the xsd schema from the organization’s home page and make the new class with xsd.exe. I understand there is something I don’t understand :o), can you pleas clarify?
What visual studio version you are using?, Normally you can click on the project's references and Add Web service. In this case Visual studio creates automatically the objects required to consume the service. you can update it any time by a right click on the reference.
However if it is very likely to change often, One solution is to implement an adapter class. use create an interface that provides the same functionality and call the actual web service. In your application you use only the proxy class and not the Web Service. Later when the web service interface changes all you have to do is to change the internals of this intermediate class.
Update:
you can use this tool to create you object model in code. Then you can compile your new object model and use it in you application. There are many complications in what you want to do and the bottom line is; when the object model changes, your code will fail. There is absolutely no way to imagine how the interface will change so while you can do all that automatically there is nothing to do if the name of a function changes.
However the answer to your situation is indirection. If you can't guaranty the stability of a external service. Why not create a stable intermediate service that calls the actual one? this way in future you don't need to touch you application. All you have to do is to modify the intermediate service while keeping it's interface compatible.
I have a WCF service that I'd like clients to be able to reference using Visual Studio's "Add Service Reference" feature. They've been able to recognize the metadata endpoint, the interfaces, methods and data types appear in the Add Service Reference dialog, and it appears to successfully generate the proxy without a hitch - but when viewing the generated code file or viewing the classes in the object browser, there is no service interface generated from the ServiceContract - only the DataContracts are represented. When I point svcutil at the same endpoint URL from the command line, the generated file does contain the interfaces.
The service itself has been used in production for a while and seems to work fine
It uses a custom binding, but the exact same binding configuration (and other config settings) are used by another service that seems to work fine with Add Service Reference
One thing that is different is that this service uses a custom behavior (an attribute derived from IServiceBehavior). The interface is also in a different assembly from the concrete service type, although so are the data contracts.
Update:
What seems to be causing the problem, which I'd somehow overlooked, is that there are FaultContracts for some of the methods on this interface, and these FaultContracts are referencing an exception type that is [Serializable], not [DataContract] (as I think anything that derives from Exception must be). The exception type itself is represented in the generated code, but its public properties aren't (in either svcutil or ASR-generated code)
What seemed to be causing the problem, which I'd somehow overlooked, is that there are FaultContracts for some of the methods on this interface, and these FaultContracts are referencing an exception type that is [Serializable], not [DataContract] (as I think anything that derives from Exception must be). The exception type itself is represented in the generated code, but its public properties aren't (in either svcutil or ASR-generated code)
I found an issue but it refers to the BETA version of VS 2010. I am interested in knowing if this issue has been fixed in RTM?
Basically it states (saw it via EF 4 Self Tracking Entities does not work as expected )
Make certain to reuse the
Self-Tracking Entity template’s
generated entity code on your client.
If you use proxy code generated by Add
Service Reference in Visual Studio or
some other tool, things look right for
the most part, but you will discover
that the entities don’t actually keep
track of their changes on the client.
I am very used to using Add Service Reference, and its always worked great for me in the past but of course I wasn't using STE (Self tracking entities). Is this problem still apparent with VS 2010 RTM and the STE template?
If I do create the proxy via code instead of add service then all the classes won't be created will they?
This is not an issue and it never was an issue. It is absolutly expected and correct behavior. STEs are classes which contains data and logic (the logic tracks changes).
When adding service reference your client proxy code is generated from service's metadata. Metadata are exposed in form WSDL. WSDL is XML based description of the service which also contains XSD description of transfered data types. XSD can describe only data format but not related logic implemented by the type. By default all unknown data types described in WSDL are generated on the client. So when you generate client proxy with all data types by Add service reference the tracking logic is lost.
To overcome this issue you have to do two things:
Create separate assembly and place all your STEs to this assembly. Then share this assembly among all involved layers (yes you have to use Add reference in your client).
Then you can use Add service reference with "Reuse types in referenced assemblies" checked.
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.
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?