我不认为这是重复的。我做了一些阅读，但没有发现任何相同的东西。似乎字段可以在二进制格式化程序和protobuf中序列化，但不能在XML中序列化。我不知道JSON。
我正在寻找用protobuf-net替换标准的.NET二进制序列化器。原因是提高速度并获得较小的持久文件大小。
在.NET二进制文件中，我只是将类标记为可序列化并将其留在那里。我怀疑不好。
使用protobuf-net我需要指定使用[ProtoMember（）]属性序列化的内容。我的新手测试显示，如果标记为自动属性，私有字段将被序列化。
我根本不想更改类代码定义，因为我仍然需要能够反序列化.NET序列化程序创建的旧持久数据。我混合了：
可能还有其他一些人。换句话说，几乎所有类型的领域和财产。
我想我需要保留任何表示在从文件反序列化后无法构造的对象状态的值。
我认为坚持每个字段和属性都没有坏处，但这会使作业变慢，文件大于它需要的。
我想我可以忽略仅在类中使用但不从外部设置的私有字段。 我想我应该坚持那些在构造函数中设置的字段。 我不确定支持领域 - 坚持他们或他们的公共财产更好吗？ 我必须坚持自动属性 我不能坚持没有setter的属性，所以我需要坚持在计算中使用的任何字段/属性。
我是在正确的轨道上还是错过了这一点。
提前致谢。
答案 0 :(得分：3)
我们不能说需要序列化的是什么。 BinaryFormatter在“所有字段”的基础上工作（除非它们明确标记为不是序列化）。您可能使用相同的方法，但如果您使用自动实现的属性（这很好），请注意您无法向支持字段添加属性 - 不像字段 - 与事件类似，以下 无效c＃ ：
[field:ProtoMember(1)] // not valid
public int X { get; set; }
这意味着您唯一明智的选择是装饰房产：
[ProtoMember(1)]
public int X { get; set; }
因为，如果将自动实现的属性更改为常规属性，则会导致BinaryFormatter的反序列化中断，因为字段名称已更改。但这很好 - 为序列化标记字段或属性（或两者都属于同一类型）没有任何问题。在某些平台上的另一个考虑因素是可访问性：私有字段可能无法访问，其中 - 公共字段工作正常。显然，公共领域非常罕见。
所以：
BinaryFormatter继续工作，请不要将自动实现的属性更改为常规属性（protobuf-net不关心您是否更改此属性）