Develop Reference

NetDataContractSerializer Deserialization With New Property

Lacking any real foresight, I've serialized a large set of data decorated only with Serializable using NetDataContractSerializer, and now I'd like to add a new field. What are my options?
The original class looks something like this (with a few levels of inheritance and quite a few fields):
[Serializable]
public class InheritedClass : BaseClass
{
public string StringId { get; set; }
}
And now I'd like to add another property, say something like:
[Serializable]
public class InheritedClass : BaseClass
{
public string StringId { get; set; }
public int IntId { get; set; }
}
Now when I update the class and go to deserialize, I receive an exception since the new field is not present, something like:
Exception thrown: 'System.Runtime.Serialization.SerializationException' in System.Runtime.Serialization.dll
Additional information: Error in line 1 position 601. 'Element' '_x003C_StringId_x003E_k__BackingField' from namespace 'http://schemas.datacontract.org/2004/07/QT' is not expected. Expecting element '_x003C_IntId_x003E_k__BackingField'.
Ok, so this makes sense since NetDataContractSerializer requires the same class. I can get around that using a DataMember attribute like:
[DataMember(IsRequired = false)]
The problem then is that switching to DataMember (as I should have done upfront, or used a different serializer) changes the implicit alphabetical ordering, and then most of my fields will silently not deserialize as is well known.
I've attempted to add an ordering that's inline with the ordering on disk manually (via Order properties on the attribute), but that doesn't appear to be respected either. (I don't see an order value I could match in the raw xml either.)
Are there any other options beyond writing something to load the xml and insert the missing node? (Or equivalently setup a parallel type and deserialize from one an re-serialize to another?) If not, I'll probably just load up with the current type and deserialize to JsonNet or protobuf, but am I missing anything more straightforward with DataMember/etc?

Marking a type with [Serializable] means that the type can be serialized by serializing its public and private fields -- not its properties. NetDataContractSerializer respects this attribute when present, serializing the fields as indicated. For an auto-implemented property the secret backing field is what is actually serialized.
When adding a new field, what one generally does to handle legacy data is to mark it with [OptionalField] to indicate that it won't always be present in serialization streams. In c# 7.3 and later, it's possible to do this to the secret backing field of an auto-implemented property by using a field-targeted attribute:
[Serializable]
public class InheritedClass : BaseClass
{
public string StringId { get; set; }
[field: OptionalField]
public int IntId { get; set; }
}
Prior to c# 7.3 there is no way to apply an attribute to the backing field of an auto-implemented property. Thus you need to make the backing field be explicit and add the attribute to it:
[Serializable]
public class InheritedClass : BaseClass
{
public string StringId { get; set; }
[OptionalField]
int intId;
public int IntId { get { return intId; } set { intId = value; } }
}
Notes:
As noted in the question, if a type is marked with data contract attributes then NetDataContractSerializer will use those in preference to the default [Serializable] contract and allow you to explicitly indicate properties to serialize (and provide names clearer than the secret backing field names).
Unfortunately it is not always practical to add data contract attributes to legacy types.
NetDataContractSerializer has not been ported to .NET Core / .NET 5 and likely never will be.

How to make readonly property in WCF? [duplicate]

I have a server side class which I make available on the client side through a [DataContract]. This class has a readonly field which I'd like to make available through a property. However, I'm unable to do so because it doesn't seem that I'm allowed to add a [DataMember] property without having both get and set.
So - is there a way to have a [DataMember] property without setter?
[DataContract]
class SomeClass
{
private readonly int _id;
public SomeClass() { .. }
[DataMember]
public int Id { get { return _id; } }
[DataMember]
public string SomeString { get; set; }
}
Or will the solution be use the [DataMember] as the field - (like e.g. shown here)? Tried doing this too, but it doesn't seem to care the field is readonly..?
Edit: Is the only way to make a readonly property by hacking it like this? (no - I don't want to do this...)
[DataMember]
public int Id
{
get { return _id; }
private set { /* NOOP */ }
}

Your "server-side" class won't be "made available" to the client, really.
What happens is this: based on the data contract, the client will create a new separate class from the XML schema of the service. It cannot use the server-side class per se!
It will re-create a new class from the XML schema definition, but that schema doesn't contain any of the .NET specific things like visibility or access modifiers - it's just a XML schema, after all. The client-side class will be created in such a way that it has the same "footprint" on the wire - e.g. it serializes into the same XML format, basically.
You cannot "transport" .NET specific know-how about the class through a standard SOAP-based service - after all, all you're passing around are serialized messages - no classes!
Check the "Four tenets of SOA" (defined by Don Box of Microsoft):
Boundaries are explicit
Services are autonomous
Services share schema and contract, not class
Compability is based upon policy
See point #3 - services share schema and contract, not class - you only ever share the interface and XML schema for the data contract - that's all - no .NET classes.

put DataMember attribute on a field not the property.
Remember thought, that WCF does not know encapsulation. Encapsulation is a OOP term, not a SOA term.
That said, remember that the field will be readonly for people using your class - anyone using the service will have full access to the field on their side.

I had some properties in a class in my service layer I wanted to pass over to Silverlight. I didn't want to create a whole new class.
Not really 'recommended', but this seemed the lesser of two evils to pass over the Total property to silverlight (solely for visual databinding).
public class PricingSummary
{
public int TotalItemCount { get; set; } // doesnt ideally belong here but used by top bar when out of store area
public decimal SubTotal { get; set; }
public decimal? Taxes { get; set; }
public decimal Discount { get; set; }
public decimal? ShippingTotal { get; set; }
public decimal Total
{
get
{
return + SubTotal
+ (ShippingTotal ?? 0)
+ (Taxes ?? 0)
- Discount;
}
set
{
throw new ApplicationException("Cannot be set");
}
}
}

There is a way to achieve this. But be warned that it directly violates the following principle cited in this answer:
"3. Services share schema and contract, not class."
If this violation does not concern you, this is what you do:
Move the service and data contracts into a separate (portable) class library. (Let's call this assembly SomeService.Contracts.) This is how you'd define an immutable [DataContract] class:
namespace SomeService.Contracts
{
[DataContract]
public sealed class Foo
{
public Foo(int x)
{
this.x = x;
}
public int X
{
get
{
return x;
}
}
[DataMember] // NB: applied to the backing field, not to the property!
private readonly int x;
}
}
Note that [DataMember] is applied to the backing field, and not to the corresponding read-only property.
Reference the contract assembly from both your service application project (I'll call mine SomeService.Web) and from your client projects (mine is called SomeService.Client). This might result in the following project dependencies inside your solution:
Next, when you add the service reference to your client project, make sure to have the option "reuse types" enabled, and ensure that your contract assembly (SomeService.Contracts) will be included in this:
Voilà! Visual Studio, instead of generating a new Foo type from the service's WSDL schema, will reuse the immutable Foo type from your contract assembly.
One last warning: You've already strayed from the service principles cited in that other answer. But try not to stray any further. You might be tempted to start adding (business) logic to your data contract classes; don't. They should stay as close to dumb data transfer objects (DTOs) as you can manage.

Define the Service contract (Interface) Before implementing the contract using the class.

Hiding base class property using new keyword in WCF

I have a Scneario like this in my Server DLL class library.
[DataContract]
public class Base
{
[DataMember]
public string Info { get; set; }
}
[DataContract]
public class Child : Base
{
[DataMember]
public new int Info { get; set; }
public int Save()
{
}
}
My WCF Proxy at client side creates a Reference class. It Renames "Info" to "Info1". And shows proper properties in Base class.My code compiles great. So far so good. When I try to run ChildProxy.Save() from my client it gives me error Saying
"There was an error while trying to serialize parameter http://tempuri.org/:info. The InnerException message was 'Type 'ClientServiceLayer.InfoService.Info' with data contract name 'ArrayOfInfo:http://schemas.datacontract.org/2004/07/Info_DLL' is not expected. Add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.'. Please see InnerException for more details.
"
How to hide the property of base class in WCF?
UPDATE:
Here is the call on the client-side
InvoiceServiceClient infoProxy = new InfoServiceClient();
invId = invfoProxy.Save();

As stated here:
You can't. Although the Child class is "hiding" the Info property of its base class, the attribute is being read by the serializer.
You could try adding [DataMember(Name = "Info")] to the child class and see what happens.

You could use KnownType Attribute in your DataContract
MSDN Data Contract Known Types

protobuf-net and interface support

This question directly in large part to the protobuf-net maintainer(s) but anyone else please comment.
I was trying to serialize a class that contains a property which has an interface type, ie:
[DataContract]
public class SampleDataClass
{
[DataMember(Order=1)]
public int Field1 { get; set; }
[DataMember(Order = 2)]
public IPayload Payload { get; set; }
}
[ProtoContract]
[ProtoInclude(1, typeof(Payload))]
public interface IPayload
{
int Field4 { get; set; }
}
[DataContract]
public class Payload : IPayload
{
[DataMember(Order = 1)]
public int Field4 { get; set; }
}
I have managed to get this to work by changing the source of v1 of protobuf-net.
I did not see any problem with this approach as long as ProtoInclude is defined for the interface.
Clearly to get this to compile I had to allow ProtoContract and ProtoInclude to be decorated on interfaces, plus a few other changes here and there. (note, I would have used DataContract/KnownType however these attributes are also not able to be decorated on interfaces)
Can you please comment on possible shortcomings?

The main glitch I can see is that in terms of payload this moves the data into a sub-message. I have some similar designs around v2 that hopefully get around this, keeping most values in the primary message. For sanity reasons, I mainly had just v2 in mind for this change (since the two implementations would be separate, and v2 has a much better type model).
However, it should be possible to support both modes of use. If you want to send it as a patch for v1 (with the same license etc) I'd happily take a look :)
This is available as a standard feature of v2

WCF issues with KnownType for Dictionary

I have a service that implements the following DataMember:
[DataMember]
public Dictionary<string, List<IOptionQueryResult>> QueryResultItems { get; set; }
I have the class "OptionQuerySingleResult" which inherits from IOptionQueryResult. Now, I understand that I need to make the OptionQueryResult type "known" to the Service and thus tried to add the KnownType in various ways:
[KnownType(typeof(Dictionary<string, OptionQuerySingleResult[]>))]
[KnownType(typeof(Dictionary<string, List<OptionQuerySingleResult>>))]
[KnownType(typeof(OptionQuerySingleResult)]
However, none of those approaches worked and on the client side I'm either getting that deserialization failed or the server simply aborted the request, causing a connection aborted error.
Does anyone have an idea on what's the proper way to get this to work?
I'd like to add that if I change the QueryResultItems definition to use the concrete type, instead of the interface, everything works just fine.
Thanks,
Tom
Edit:
The exception that I am getting is:
Error in line 1 position 524. Element 'http://schemas.microsoft.com/2003/10/Serialization/Arrays:anyType' contains data from a type that maps to the name ':OptionQuerySingleResult'. The deserializer has no knowledge of any type that maps to this name. Consider using a DataContractResolver or add the type corresponding to 'OptionQuerySingleResult' to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding it to the list of known types passed to DataContractSerializer.
However, when I look at the client proxy that svcutil generates, "OptionQuerySingleResult" is definitely defined in it:
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "4.0.0.0")]
[System.Runtime.Serialization.DataContractAttribute(Name="OptionQuerySingleResult", Namespace="")]
[System.SerializableAttribute()]
public partial class OptionQuerySingleResult : object, System.Runtime.Serialization.IExtensibleDataObject, System.ComponentModel.INotifyPropertyChanged

I think you would use:
[KnownType(typeof(OptionQuerySingleResult)]
But you also need a [DataContract(Name = "OptionQuerySingleResult")] on your OptionQuerySingleResult class.
I think this also relies on your client proxy classes being generated by the SVCUTIL.EXE util.

You simply need to add the following property to your datacontract class.
[DataMember]
public object UsedForKnownTypeSerializationObject;
So now the generated proxy contains the Knowtypes you set on the datacontract.
I had the same problem and this is the only solution I came up with.
If you don't at the a property of type Object to you DataContract class,
the generated proxy doesn't contain the declared knowtypes
For example:
[DataContract]
[KnownType(typeof(List<String>))]
public class Foo
{
[DataMember]
public String FooName { get; set; }
[DataMember]
public IDictionary<String, Object> Inputs { get; set; }
[DataMember]
private Object UsedForKnownTypeSerializationObject{ get; set; }
}
It's not as pretty because you end up with a dummy property which doesn't have any
functional implementation. But then again I don't have another solution.