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.
Related
the question is simple..
we usually use web reference to consume the web services literally(visual studio). But, my problem is another way round. I need to call a particular web service from a c# class to make the web service available to be consumed by others.
First of all, if you have a choice, you should be using WCF on both the server and client. If you can't use it on the server for some reason, then at least use it on the client by using "Add Service Reference" instead of "Add Web Reference". "Add Web Reference" is part of the legacy ASMX technology, which should not be used for new development.
Secondly, of course you can create a separate class library, and use "Add Service Reference" in that library. You can then write a class that has public methods which call the service. The users of this class library will call your public methods, and will not directly call the service.
You can extract the C# code class of a Web Reference by unfolding the web reference in VS, (by showing hidden files if I remember well).
You should find a Reference.cs file which is the proxy client code for your web Service.
It contains everything you need to call your WS. You can copy it elsewhere, include it in another project, change its namespace/code etc. On the long run, maintainance of this file will be a pain if the corresponding WS evolves.
Anyway, if you have the choice, you should follow #JohnSaunders advice on WCF
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).
My understanding is that a c# based client "prefers" SOAP because when you add a web service reference it creates a proxy class from the wsdl found at the url you specify.
Which almost makes it transparent to the c# client that we are even using a web service, it almost feels like we are using a local class library. you call methods and you use objects.
My question is can REST achieve the same affect. I assume that it can't since it doesn't have wsdl and thus visual studio can't generate a proxy class for it. But Please correct me if I'm wrong?
A "run of the mill" REST service cannot achieve the same kind of tight integration with C# - mostly because it lacks the metadata that a SOAP service will provide (with a list of methods and their parameters and all that stuff).
The WCF Data Services (built on top of REST) do work much the same way as SOAP services, since the OData protocol contains extensions for pure REST services that provide metadata information needed to create a good, useful client-side proxy.
REST can be used to generate client side class libraries. For Example You can create proxy classes for MS generated REST services. In fact MS is actively pushing this model for Entity Framework based WCF DATA Services, e.g. those used by Silverlight and RIA applications. check out MS ODATA framework for REST which involves creating client objects out of standard REST queries.
http://msdn.microsoft.com/en-us/library/dd673930.aspx
I have classes that are needed in both my web service and my server.
For example, I have a class named Order that I'd like to send from my server to the web service and vice-versa.
Problem is that the class in the server is Order and the one on the web service is localhost.Order, and it is impossible to convert between them, even though they are built from the very same code. Error is cannot convert from 'Order[]' to 'localhost.Order[]'.
What can I do? Thank you very much.
when you add reference to web service you can specify which classes to reuse. by default it generates classes based on WDSL that web service produce.
The namespace used is determined by the name you give the reference when you add it.
For more information see this answer to a similar question:
Unable to cast object of type MyObject to type MyObject
You should maybe have a look at WCF services:
http://msdn.microsoft.com/en-us/library/bb332338.aspx
I've used these on a few projects where both have references to a shared library, and one web site will request one of these objects via a WCF service call from another site. It's very clean, and it opens up other options for transport/security which can be very useful.
The question appears to suggest that you are using ASMX Web Services. If so, you have your work cut out for you.
Jelle Druyts wrote an extension for ASMX that can do, more or less, what you're asking. You have to configure your shared types at the machine level (machine.config). It's not pretty.
There's also a fix for that extension to make it work with nullable types.
Good luck getting this to work with Visual Studio 2008 or on Vista/Windows 7. You'll be OK if you're still running XP with VS 2005.
If you can, you really should consider using WCF for the client proxy instead, since WCF makes it very easy to share types. In fact, the Visual Studio 2008 integration does this by default; you just need to make sure your client project references the assembly containing the service types.
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.