8

我们在 .NET 中有一些（很多）类。我们使用protobuf-net对其进行标记，并通过google original library为 C++ 代码端生成 .proto 包装器。

所以我有一条消息（C++ DebugString() 在一些 EventBase 类上（在 .NET 中EventCharacterMoved 继承EventBase，而在 C++ 中我只是写入可选属性））：

UserId: -2792
EventCharacterMoved {
  Coordinates {
    Position {
      X: 196.41913
      Y: 130
      Z: 213
    }
    Rotation {
      X: 207
      Y: 130
      Z: 213
    }
  }
  OldCoordinates {
    Position {
      X: 196.41913
      Y: 130
      Z: 213
    }
    Rotation {
      X: 207
      Y: 130
      Z: 213
    }
  }
}

（来自这样的 .proto 文件）

message Coordinates {
   optional TreeFloat Position = 1;
   optional TreeFloat Rotation = 2;
}
message EventBase {
   optional int32 UserId = 10 [default = 0];
   // the following represent sub-types; at most 1 should have a value
   optional EventCharacterMoved EventCharacterMoved = 15;
}
message EventCharacterMoved {
   optional Coordinates Coordinates = 100;
   optional Coordinates OldCoordinates = 101;
}
message TreeFloat {
   optional float X = 1 [default = 0];
   optional float Y = 2 [default = 0];
   optional float Z = 3 [default = 0];
}

在 C++ 中，我发送这个，我们从 .NET 发送相同的消息内容。

C++ 代码可以解析 C++ 编码的消息以及 .NET 编码的消息。.NET 代码只能解析 .NET 消息。

通过网络，我们得到 87 个字节（与.Net 文件和C++ 文件大小相同），但内容不同：

在此处输入图像描述

如您所见，它相似但不一样。由于这种差异，CPP 代码可以读取 .NET C# 消息，而 .NET 无法读取 CPP 消息。

在反序列化的代码中，我们得到：

TestProto.exe 中发生了“System.InvalidCastException”类型的未处理异常

附加信息：无法将“TestProto.EventBase”类型的对象转换为“TestProto.EventCharacterMoved”类型。

在如下代码中：

using (var inputStream = File.Open(@"./cpp_in.bin", FileMode.Open, FileAccess.Read)) {
    var ecm = Serializer.Deserialize<EventCharacterMoved>(inputStream);
}

让我们看一下（如jpa在他的评论中提到的）protoc --decode_raw选项：

在此处输入图像描述

这可能与我的 CPP 包装器使用最新的 google protobuf 版本有关，而 protobuf-net 可能使用一些较旧的编码格式或类似的东西......

所以我想知道如何让 .NET protobuf 读取 C++ 消息（让 tham 能够解码相同的东西）？

或者至少如何使原始谷歌 protobuf 以与 .NET protobuf 相同的方式编码？

对于那些真正感兴趣并希望通过简化示例进入压缩包的人（包括 C++ 和 C# 代码的 VS 2010 解决方案）

4

2 回答 2

2

编辑; 这应该在 r616 及更高版本中修复。

我终于有机会看看这个（为延迟道歉，但社会季节性假期需求介入了）。我明白现在发生了什么。

基本上，数据理论上是一致的；这实际上归结为字段排序。从技术上讲，字段通常按升序编写，但可以按任何顺序编写。关于 protobuf-net；对于不涉及继承的类型，无论顺序如何，它都可以正常工作。protobuf 规范没有定义继承，因此 protobuf-net 在规范中添加了对继承的支持（由于不断的需求）。作为一个实现特性，它首先写入子类信息（即字段15，子类型，在字段10之前写入）。目前，在反序列化期间，它还期望首先是子类型信息。这很少对任何人产生影响，因为由于 protobuf-net 是唯一使用这种继承的实现，因此继承特性的使用大多只在 protobuf-net 到 protobuf-net 的使用中出现。

在您的情况下，您正在使用 .proto 与 CPP 互操作；这意味着 CPP 代码将能够消费到 protobuf-net 数据，但它可能有一个相反的类型转换异常（基本上，它在获得第一个数据字段时开始构造具体类型）。

尽管很少成为问题，但这是需要解决的问题。我可以试着在今天晚些时候或明天看看这个。

选项：

  • 确保子类型字段始终低于任何数据字段
  • 如果您知道它需要子类型，请使用 Merge API 并传入所需类型的现有新对象 - 这将正确填充现有对象
  • 等待一两天（希望如此！）使用 build r616 或更高版本进行正确修复
  • 使用互操作时避免继承（和其他特定于实现的功能）
    • 请注意，您可以通过封装在没有继承的情况下对相同的数据进行建模- 它会很愉快地工作；特别是具体类型的创建是这里的问题
  • 在从 CPP 站点构建数据时，通过将其分为两部分来编写不合理的长度（意思是：我不认为这是一个实际的解决方案）：
    • 先EventBase用数据写一个，然后序列化；现在在一个单独的模型中只写一个数据，然后序列化；这将模拟按所需顺序编写它们（protobuf 流是可附加的） - 不漂亮EventCharacterMovedEventBaseTreeFloat
于 2012-12-31T07:52:29.070 回答
1

这看起来与http://code.google.com/p/protobuf-net/issues/detail?id=299和http://code.google.com/p/protobuf-net/issues中提到的问题非常相似/detail?id=331据称已由http://code.google.com/p/protobuf-net/source/detail?r=595修复

您使用的 .NET protobuf 版本是否足够新以包含该修复程序？

于 2012-12-26T22:29:48.370 回答