My WCF client and server exchange objects whose types are defined on a class library shared by both, the server and the client. These objects implement custom serialization via ISerializable. However, my custom serialization is not being used. DataContractSerializer is being used, instead. How do I force my custom serialization to be used?
The reason why I need to use my own serialization is because I do trasfer some big object graphs and my serialization algorithm does a good job in compressing/speeding up things.
This is possible by adding the correct attributes to your wcf contact.
See: http://www.danrigsby.com/blog/index.php/2008/03/07/xmlserializer-vs-datacontractserializer-serialization-in-wcf/ for details.
If this does not help, show some code of how you have told the wcf contract that it should use the custom serializer.
Related
I built a number of WCF services as part of an application. Until recently, most of the classes that were used as parameters of the many operations in a service did not had the DataContract or DataMember attributes applied to them.
Now, I've made a few changes in a row and all of a sudden WCF is complaining that he can't serialize my classes.
Does anyone knows if any changes in configuration or even in the ServiceContract, OperationContract etc. can cause WCF to become picky about the classes it can serialize?
I'd rather not need the attributes in those classes (they should be pure C# classes as possible).
Also of note, if I return to a previous version in my source control, WCF goes back to "normal", so I believe that it's not a machine/environment thing.
The ability to create WCF Data Contracts without the use of the [DataContract] and [DataMember] attributes is a feature added to WCF in .NET 3.5 SP1. Since everything works for you when reverting your code to a previous version, I'm assuming you are already using at least that version.
Nevertheless, in order for classes to be serializable by WCF, the class must meet several requirements listed here. The main requirements of the data contract class are:
It must be public.
It must have a parameterless constructor.
It must not have any data members that do not meet all these requirements. If you do have such a member, mark it with [IgnoreDataMember] and it will be excluded from WCF serialization.
You can get more information about what fails to serialize by performing the serialization manually using the DataContractSerializer class. See this article for more details and code examples. Another method is to mark all members with [IgnoreDataMember] and gradually remove the attributes from members until serialization fails, which will tell you which member is causing the problem.
WCF is lenient towards classes that have [serializable] attribute. You don't require [DataContract]. You must have added something that is not serializable.
I know a way to do that. it's not professional but it works for me
I'm also need pure c# classes so I do it in this way.
I convert each parameter of my class to an object then gather them into array of objects and send it to the other side. in the other side I do the reverse operation to get my parameters back. but this operation will reduce the performance i think
Can anyone please elabortae me the reasons why should I use Data Contract Serializer
while we have XML/Binary serializer already there in .Net ?
This is a site i found when i was looking into the same issue.
You should check this out
Quoting from the same link mentioned above:
Advantages of DataContractSerializer over XMLSerializer
Opt-in rather than opt-out properties to serialize.
Because it is opt in you can serialize not only properties, but also fields. You can even serialize non-public members such as private or protected members. And you dont need a set on a property either (however without a setter you can serialize, but not deserialize)
Is about 10% faster than XmlSerializer to serialize the data because since you don’t have full control over how it is serialize, there is a lot that can be done to optimize the serialization/deserialization process.
Can understand the SerializableAttribute and know that it needs to be serialized
More options and control over KnownTypes
Hope it helps!
One more HUGE advantage; DataContract serialization allows for interop between any two classes that implement the same DataContract. This is what allows WCF to generate the data classes for you automatically when you reference a WCF service. You can also "hack" this process by referencing a published DataContract in a new user-developed class (or two or three); You can then transfer data between instances of these classes, and any other new ones you create, via serialization. This is also possible but much more difficult with XML serialization, and impossible with binary serialization.
XmlSerialization creates a serializer proxy for each class. The proxy resides in a different assembly so it can serialize only public fields.
DataContract serialization can serialize private fields too. Does it mean it uses reflection? Isn't it slower than using a proxy (except for the first time)?
This protobuf-net page shows the performance of DataContractSerializer to be significantly better than XmlSerializer. Of course, you should always test with your own data, but if you are looking to replace XmlSerializer, you will most likely find DataContractSerializer to be a performance improvement.
I'm not sure how DataContractSerializer is implemented internally, but generally serializers are highly optimized. This is especially true for DataContractSerializer since it is a big part of the performance picture for WCF. It is not uncommon for a serializer to generate MSIL code on the fly. When this is done, DynamicMethod allows you to (surprisingly!) bypass visibility checks (see MSDN), so it is possible to access private fields without reflection.
From MSDN:
Given sufficient security permissions,
a serialization engine implemented
using dynamic methods can access
private and protected data to enable
serialization of objects not authored
by the engine creator.
Problem:
WCF contract objects cannot implement 2 types of lists (ie: List and List).
Long-winded explanation:
I'm building a WCF service on top of an existing core system, and I'm trying to work out the best way to implement some of my business objects.
The core system utilizes interfaces for all business objects - Person management functionality, for instance, requires that I pass in an object which implements IPerson. Nothing out of the ordinary here.
The goal is to have a contact object (Person) which can be used on the service side of things, and also implements IPerson so that it can be passed into the core without requiring a conversion layer. This all works just fine for items like Person.
The issue comes in for lists: a method in the core, for instance, might require a IPersonList to be passed in, and as anyone who's dealt with inherited generics will know, List does not inherit from IList.
In our currently running ASMX service, we implement this with some up/down casting in the web objects. "WebPerson" will inherit from List, and implement IList explicitly so that the IList properties do not show up on the WSDL.
In WCF, however, if you try to use this same object, you will get the following error:
Type 'Cssi.IBroker.Service.Cssi.Contracts.PersonList' with CollectionDataContractAttribute attribute is an invalid collection type since it has multiple definitions of interface 'IList`1'.
Apparently, now that the new WCF serializer knows how to serialize IList, it's no longer able to ignore the second explicit implementation.
If possible, I'd like to avoid creating a PersonList object just for the contracts and then converting to and from an IPersonList object for each call. Changing the core business logic to use concrete objects designed just for the WCF services isn't an option.
Help!
I ended up deciding the best route was a set of dedicated objects used only for the contracts. With them being dedicated to one task, I was able to keep them cleaner without having to compromise my internal design for the sake of the WSDL. For the WSDL objects themselves, I ended up using arrays instead of IList.
The extra step of conversion is a bit cumbersome, but less than trying to keep my core objects WCF friendly would be.
I know there have been similar questions on this topic but I wasn't completely sure they were solving the same problem. So just to be clear...
I have an existing class library that has namespaces for types, business logic and data access. The classes in the logic and data access namespaces are static and have basic crud methods to fill the type instances with data or take type instances that are already full and do inserts or updates in the database.
Now, in addition to the existing applications that reference this library directly, I want to also create a WCF service so that other applications can consume the objects and methods that way.
Every WCF turorial that I see creates the domain objects in the service project - but I don't want my objects defined in two places.
So I was thinking I could reference serialization in my existing class library and mark the type classes as [DataContract] and the properties as [DataMember]. Then, in the WCF project, create the [ServiceContract] interfaces with [OperationContract] methods to match the static logic classes and methods from the existing library that I want to expose. Then, from the WCF project, reference the existing class library and implement the WCF interfaces by having methods in it that call the existing library logic methods which return the existing library types.
Is this a good pattern?
It sounds good but retrofitting serialization tends to be more trouble than it seems at first. I would suggest that you build some lightweight data contracts into a service layer and then build a small tier that sits between your service layer and the business layer to translate the data contracts into business objects and vice-versa.
Assuming your business object can be serialized (have attribute Serializable) one approach could be creating DataContainer object, which will be your data contract. This object would be used in your CRUD methods.
For example your interface could be
Update(DataContainer obj)
Insert(DataContainer obj)
etc.
Then you would use Binary serialization to pack your object into array of bytes and pass it this way through WCF. On the other side you would deserialize them using again BinarySerialization. You just have to make sure that both sides (client and server) have valid version of assembly with your business objects types.