In the protobuf-net v3 release notes, one of the breaking changes is: non-generic list-like APIs like IList or ICollection are no longer supported; there is a new API for processing custom collection types.
I've been looking through the repo, but haven't been able to figure out the details. Would someone be able to provide an example on how to migrate this data contract to v3?
Here is an example:
[DataContract]
public class Data
{
[DataMember(Order = 1)]
public IList<DataEntry> DataEntries
}
[DataContract]
public class DataEntry
{
[DataMember(Order = 1)]
public string Name;
}
No change is necessary. You are using IList<T>, which is the generic API. The thing that isn't supported is using the old non-generic IList (with no <T>)
Related
I'm considering migrating current WCF-based based application to protobuf-net.Grpc. It seems to be doable, however I was not able to make protobuf-net serialize properties of (DTO classes) base class without including all derived classes with [ProtoInclude] attribute.
Simplified class hierarchy:
[DataContract]
public abstract class DtoBase
{
[DataMember(Order = 1)]
public int Id { get;set; }
[DataMember(Order = 2)]
public int Version { get;set; }
[DataMember(Order = 3)]
public EditState EditState { get;set; }
}
[DataContract]
public class PersonDto : DtoBase
{
[DataMember(Order=4)]
public string FirstName { get;set; }
[DataMember(Order=5)]
public string LastName { get;set; }
}
I have investigated related questions and it all boils down to the fact that specific type should be known during deserialization - or there should be a way to determine it. Our service methods already know the specific subclass to use, e.g. we have methods like
[ServiceContract]
public interface IPersonService
{
[OperationContract]
ScalarResult<PersonDto> GetById(personId);
}
DataContractSerializer can do that - deserialize base class properties, when specific subclass is already known. It needs hints (known types) when you deserialize subclass having base class signature, like returning PersonDto instead of DtoBase. But when specific subclass is known, known types are not needed and everything just works.
So the question is how to do the same with protobuf-net? And if it's not possible, why?
Protobuf-net, like any library, makes certain assumptions and compromises. If it wants to support additional scenarios, they need to be specified, designed, implemented, tested and supported - all of which takes time. So far, the scenario you describe: hasn't had that time invested.
It may be possible to configure the base-type properties using the RuntimeTypeModel API, but I must emphasize: whenever a question arises that is essentially:
My existing model isn't working well with my chosen serializer
my default response (based on literally decades of experience in this field) is:
If your existing model isn't a great fit for a different serializer: stop fighting the serializer. Instead, create a new model that works perfectly with your new choice of serializer, and shim between models at the point of (de)serialization
I would like to use ServiceStack on the server side, and I would like to use protobuf-net as the serialization system used by ServiceStack. However, some of the clients will not be using the ServiceStack client libraries. They will be using protobuf-net directly.
In reading the widely linked ServiceStack protocol buffers howto (http://stevenhollidge.blogspot.in/2012/04/servicestack-rest-with-protobuf.html), it indicates using [DataContract] and [DataMember(Order=i)] attributes on the classes and properties respectively. However, when I read the protobuf-net documentation it indicates attributes are [ProtoContract] and [ProtoMember(i)] instead.
If I want my DTOs to work with both native protbuf-net and ServiceStack's protobuf-net wrapper do I need to add both attributes to every class and property, or will one or the other be sufficient?
ProtoBuf requires a mapping from Properties to numerical indexes, both of the options you've specified are equivalent ways to do this:
[DataContract]
public class Dto
{
[DataMember(Order=i)]
public string PropertyName { get; set; }
}
[ProtoContract]
public class Dto
{
[ProtoMember(i)]
public string PropertyName { get; set; }
}
We have a huge application with a lot of classes. We are currently porting this .net application to IPad with Monotouch. We have some problems with the DataContractSerializer and we would like to use Marc Gravell's protobuf-net serializer.
The communication between the client and the server is managed by a WCF Service.
A WCF service is made of one Interface exposed to the client and the server, and one implementation of this interface on the server.
The interface looks like that:
[ServiceContract]
public interface IMyService
{
[OperationContract]
SomeObject MyFunction(SomeObject myObject);
}
The server side implementation looks like that:
[ServiceBehavior(...)]
public class MyService
{
public SomeObject MyFunction(SomeObject myObject)
{
}
}
Our classes looks like that:
[DataContract]
public class MyClass
{
[DataMember]
public int SomeProp {get; set;}
[OnSerialized]
public void OnSerialized(StreamingContext context)
{
}
}
So here are my questions:
What would be the changes to do to my classes, wcf interface and wcf implementation.
How would I replace the default WCF DataContractSerializer to the Protobuf Serializer.
Please note that on monotouch, I only have access to Protobuf and Protobuf.Meta namespaces.
[EDIT]
I found a way to swap the serializer runtime:
Custom WCF DataContractSerializer
The above solution uses the DataContractSerializerOperationBehavior. Does Protobuf-net provides such behavior?
In all honesty, I am unfamiliar with the WCF options available to you in monmotouch; they are very different between regular .NET and Silvelight, for example - and I see no reason to assume that monotouch has the ability to swap serializer at runtime (which "full" .NET does, at least under the MS version). This makes it hard to do the transition silently, as we can't wrestle control from DataContractSerializer.
As such, IMO the simplest option is to seize control of the data manually, and send raw byte[] - ideally with MTOM encoding enabled if monotouch can do that. Then once you have your byte[] the world is your mollusc, as they say.
Re changes to your types... well, MyFunction() is an oddity, in that it doesn't transfer any data, so I'm not sure what you want me to suggest on that one. With MyClass, all it needs is a unique number (unique within the type, not globally) per member, i.e.
[DataContract]
public class MyClass
{
[DataMember(Order=1)] // <==== this provides the 1 as the key
public int SomeProp {get; set;}
// see below re callback
}
You also have a serialization callback; these are fully supported, but it expects to find a familiar pattern - StreamContext is not one that I know of (although it should work with StreamingContext and a few others).
Finally, note that by default protobuf-net executes the constructor, which is different to DataContractSerializer. If you desire, you can suppress this via:
[DataContract(SkipConstructor=true)]
public class MyClass {...}
If I've missed the intent here, let me know.
Note there are also ways of doing all the configuration without changing/adding any attributes if you prefer.
I have some simple POCO object:
public class ProductCategoryDTO
{
public string Name { get; set; }
public DateTime ModifiedDate { get; set; }
}
As sometimes field order is important (for example, if sending to Infopath forms), I need to keep element order when serializing.
And now I am confused, what attributes I should use for the class and for each field. I know that:
DataContractSerializer uses [DataContract] and [DataMember(Order = n)]
XMLSerializer uses [Serializable] and [XmlElementAttribute(Order = n)].
Then what attributes to use if I want to support both XMLSerializer and DataContractSerializer, so it can used in both WCF or ASP. web services?
Strictly speaking, you don't need to use any attributes for either ;-p It used to be that DataContractSerializer would demand [DataContract] / [DataMember] (and they absolutely should be used), but you can use it without (but it then acts in a very dubious way similar to BinaryFormatter). Likewise, XmlSerializer doesn't need anything unless you want to control things. There are, however, some differences you should note:
XmlSerializer demands (and uses) a public parameterless constructor; DataContractSerializer doesn't use a constructor (at all). So watch out for that, and don't (for WCF) rely on code in the ctor - if you have necessary init code, use a serialization callback for WCF.
XmlSerializer demands either public fields (yeuch) or public properties with both get and set (even for lists); DataContractSerializer will happily work against private members, properties with (for example) a public get and private set, and collections without a `set (as long as your type initialises it).
XmlSerializer demands public types; IIRC DataContractSerializer is less fussy
So yes; you can support both serializers, and you can add any number of attributes in parallel, but note the above if you want total compatibility.
Another option is to just use XmlSerializer; you can configure WCF to use XmlSerializer by using [XmlSerialzerFormat]. Both options support inheritance, via [XmlInclude] and [KnownType].
Finally, note that if you implement IXmlSerializable, this takes precedence over either, but it hard to get right. Don't do that unless you have to.
I don't see any reason why you couldn't put both attributes on the class and member properties, if you really must. Doesn't look nice, but if it works for you, that's just fine!
[DataContract(Namespace="....")]
[XmlType]
public class ProductCategoryDTO
{
[DataMember(Order=1)]
[XmlElementAttribute(Order=1)]
public string Name { get; set; }
[DataMember(Order=2)]
[XmlElementAttribute(Order=2)]
public DateTime ModifiedDate { get; set; }
}
Order of XML elements should be dictated by the WSDL and you don't need to worry about it. Starting from .NET 3.5 SP1 you no longer need to use DataContractAttribute and DataMemberAttribute. The serializer will automatically include all public properties. As far as XmlSerializer is concerned, the SerializableAttribute has no effect. This attribute is used for binary serialization by the BinaryFormatter. So to resume, you could leave the class as a POCO, expose it either in WCF or ASP.NET webservice and leave the clients consume it according to the WSDL.
I have 'extended' the System.DateTime struct by adding some essential fields to it. Ideally I'd like to be able to deliver this object via a webservice to a winforms client.
I've marked the stuct type as [Serializable] and it also implments ISerializable, however if I inspect the XML being delivered by the webservice it simply contains an empty tag for the object.
Putting breakpoints all over the place has lead me to believe that when the object gets de-hydrated the ISerializable method void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context) never appears to get called.
There are various reasons why I'd prefer to keep this as a struct, but will convert it to a class if necessary.
Does anyone know why GetObjectData is being ignored by the .net framework while it is preparing the data for the webservice response? The struct which I am working with contains a DateTime member and a few booleans.
please note, this is .net 2.0!
Cheers
First, web-services use XmlSerializer - so you'd need IXmlSerializable for custom serialization. The standard XmlSerializer serialization only acts on public properties that have both a getter and setter.
Second, structs generally don't work very well as web-service DTO objects; in particular, XmlSerializer demands things be mutable... which structs shouldn't be.
I'd use a class, personally. If you can give more info, I might be able to say more...
For example:
[Serializable]
public class FunkyTime
{
[XmlAttribute]
public DateTime When { get; set; }
[XmlAttribute]
public bool IsStart { get; set; }
[XmlAttribute]
public bool IsEnd { get; set; }
}
(note you can tweak the xml layout / names in various ways)