protobuf-net indeed needs *some* way to associate protobuf numbers with members; one of the ways it supports is `[XmlElement(Order=n)]`, but to confirm: yes the "n" needs to be >= 1, and yes, since `[XmlAttribute]` doesn't specify any such number, protobuf-net can't use that in any meaningful way.
One option, of course, is to add `[ProtoContract]` and `[ProtoMember(n)]` attributes; these will take precedence over `[XmlType]` and `[XmlElement]`; but you say you don't want to edit the existing class; fine.
If the reason for this is that `Movie` is a generated type, for example from xsd.exe, then another option might be a `partial class`. With such, you can add a **second** class file that is merged with the existing .cs by the compiler. This is ideal for adding information to a generated type, for example (in a second .cs, and in the same namespace):
[ProtoContract]
[ProtoPartialMember(1, "MovieName"),ProtoPartialMember(2, "MovieDir")]
[ProtoPartialMember(3, "TheatersCount")]
partial class Movie { }
If, however, even this is not allowed, then you can tell protobuf-net about `Movie` at runtime rather than via attributes; for example (during your apps startup):
RuntimeTypeModel.Default.Add(typeof(Movie), false).Add("MovieName", "MovieDir", "TheatersCount");
(that is just a very basic usage; there are much more subtle configuration options available)
Any of those help?
Marc
(protobuf-net)