I have a WSDL from a webservice for which I don't have the implementation.
In order to create a client app, I'd like to build a dummy implementation of this WSDL.
Is there any way to create either a WCF service from this WSDL or a oldschool web service ?
I only want the skeleton of the service (throw new NotImplementedException() is ok). Then I will implement a custom test behavior.
ths
For WCF, you can actually do this for the most part. Just use svcutil.exe (or the VS Add Service Reference wizard) to add a reference to the service.
This will generate all data and service contracts, and then all you need to do is add a new class to your project that implements the service contract interface that svcutil generated (which is just a few clicks in VS).
Related
I created a service reference with VS to a soap service. Now the server is offline and I would like to build a simple server for testing purposes. I've already tried wsdl.exe with the wsdl file but didn't work because it couldn't reach the server.
Is there any simple way to acheive this? Of course, I'm not expecting any business logic to be magically created, just the structures and empty methods. Then I'll make it respond with dummy data.
In the folder [project]\ServiceReferences\[service reference name] you'll find two files: one .wsdl and other .xsd
The xsd file contains the information that wsdl.exe was trying to get online. So running:
wsdl /language:CS /serverInterface file.wsdl file.xsd
will create the interface for the service. Then, create a new Wsdl Service Library project, add the interface (the new .cs file found in the same folder than wsdl.exe) and add the correct attributes to the interface, methods and data objects (if there's any).
Creating the service class is easy now that you have the interface.
I've got a WCF service that sits as a middle tier between a client and an ASMX service. I've extracted the classes from the ASMX service and wrapped them in a separate dataContract dll using SVCUtil to generate the code. I've then added a reference to the shared DLL from a Winforms client and the WCF service.
The winforms client populates a type in the shared data contract dll and passes it to the WCF service but when the WCF service receives the type, it's null.
Are there additional steps I would need to take to wrap these ASMX types successfully in a shared assembly?
To avoid problems with generated proxies and have total control over invoking service methods use shared (client) lib WCF contracts and create your own proxy class. See, for example, this and more for details.
We are doing enhancements to a WCF service application. This WCF service application references another WCF service. Enhancements are done to both WCF service applications. Therefore I am updating the service reference whenever there are changes. I am observing strange behavior when VS 2010 is generating client proxy classes. Whenever an update happens, VS 2010 is using the XMLSerializer. Earlier it was using the DataContractSerializer.
But when I created an empty WCF Service application and referenced another WCF service, the DataContractSerializer is being used.
I want to update service reference using DataContractSerializer instead of XMLSerializer. Otherwise I have to change a lot of code, since I have to update code for the PropertySpecified field as well.
What is wrong here?
Search your service side code to see if [XmlSerializerFormat] attribute was added to your service. That's really the only way this could happen, unless of course, you're specifically setting the flag during client proxy generation to use XmlSerializer.
If that doesn't work, then you may want to consider just deleting your service reference and re-adding it.
I have a WCF service. Contract for the service is defined using interface. The implementation is not yet created. I need to create WSDL and XSD corresponding to the contract. I will deliver the soforth generated wsdl to my team members. They must be able to create the interface from the wsdl and create the service. What are the approaches/tools for creating the wsdl and xsd from the C# interface which is used as the contract? Also, how to create the interface back from the WSDL? Do I need to provide both the xsd and wsdl to the developers or only the WSDL?
What is the best approach for WSDL interoperability?
Note: I have two services. One uses Data Contract. Second one uses Message Contract.
Note: I am using Visual Studio 2010 and .NEt 4.0
Reading:-
Generating a WSDL from an XSD file
Can you combine the WSDL and XSD data from a WCF service?
What tool can I use to merge wsdl and xsd file?
Providing the WSDL should be enough as the WSDL would have the reference to the xsd's using the import attribute.
When defining your bindings for your WCF service make sure you use BasicHttpBinding (follows BasicProfile 1.1) which is interoperable.
Also you would consider flattening your WSDL for your service to be highly interoperable as at times php and other java clients might need flat wsdl. If you are using .NET 4.5 then you have this as an inbuild option now else you can check this link on how to flatten your wsdl
I have the following class in Class Library: Artist, which is a POCO
Now I have a method in a web-service (which has a reference to the mentioned-above library) with a signature like this:
[WebMethod]
public int Artist_AddArtist(Artist a) {
//
}
When I try to consume this service from an application (that also has a reference to the mentioned-above Class library), the expected parameter of the Artist_AddArtist method is not Artist, but a new type of Artist that is being generated in Reference.cs which is a partial class that is auto-generated.
Thus since in my application I use, supposedly the same Artist class from the library and now the Web Service method expects this new auto generated type, I cannot pass an instance of it to the web-service.
How can I fix this issue?
Maybe switching to WCF services is an option for you. As far as I remember, with a WCF service, you can reuse the same types on ther server and client side.
This article explains how to migrate an ASMX web service to a WCF service.
You cannot, and should not, fix the problem.
Some others will tell you to do things like edit the generated file, but that's not a good practice (as the changes will go away as soon as the Web Reference is updated).
What you're seeing is by design. See Basics: How Web Services Work.
Briefly, when you use "Add Web Reference", Visual Studio downloads the WSDL file from the service, and uses the XML Schemas from the WSDL to create some proxy classes to represent the XML described by the schema. It also creates a proxy class for the service itself, having methods for each operation in the service.
The proxy data classes can serialize to the XML that the service is expecting to receive, and can be deserialized back from the XML that the server sends in reply.
One way to think of it is that you only have this problem because both client and service are .NET. If your client were written in Java, then you wouldn't be thinking of sharing classes.
Note that WCF can do this, if necessary. It introduces a dependency between the client and service (they both have to use compatible versions of the assembly containing the classes), but when you need to do it, the option is there. It's useful when there is behavior in these classes that must be used both by the client and by the service.