WCF Serializeable entity and __BackingField

We have a 3rd party dll wich contains (among other things) our entities.

The entites are all marked with the [Serializeable] attribute.

We now need to creat a new WCF services which will expose some of this entities.

The problem is, since the entites are not declared with the DataContract and DataMember attributes, the property names are appended with __BackingField!

I know using the DataContarct\Member attributes will solve this issue, but given that I cannot modify 开发者_Python百科the 3rd party dll with the entities, is there a different workaround?

Types decorated with the [Serializable] attribute have their fields serialized, not properties (that's the [Serializable] "contract"). If the 3rd party types use automatic properties (as shown below), the compiler will create a field with the k_BackingField suffix, and this is what will be serialized.

If you cannot change the types in the 3rd party library, one alternative would be to use that same library on the client. When creating the proxy for the service (using either svcutil or Add Service Reference), you can reference the 3rd party library, and the generated client won't create new types for the contracts, instead reusing the types from the library. This way you won't have to deal with types with public _BackingField property names.

Automatic properties:

[Serializable]
public class MyType
{
    public string MyProp { get; set; }
}

The compiler will turn it into something similar to

[Serializable]
public class MyType
{
    private string <MyProp>k_BackingField;
    public string MyProp
    {
        [CompilerGenerated]
        get { return this.<MyProp>k_BackingField; }
        [CompilerGenerated]
        set { this.<MyProp>k_BackingField = value; }
    }
}

You can use the XmlSerializerFormatAttribute to use XmlSerializer instead of DataContractSerializer in the service implementation.

It will perform slower but it should sovle your problem.

I am assuming you want to expose these third party types from a service.

One solution which you may consider is to maintain a separate library which mirrors the types in the third party library.

This has the following benefits:

1. Ownership - You own the types you are exposing therefore you control the serialization/deserialization across your service boundary.
2. You are insulated from sudden changes to the other party's types and can change your interfaces in a controlled fashion.

From a SOA perspective if you are exposing another party's types on your service the other party should supply the types in a contractural format like XSD. I think your design calls for some fairly unreasonable hoop-jumping on your part.

It may be more work up front but it is kind of a one-off exercise.

Hope this helps some.