Как поддерживать синхронизацию проекта C # и C ++ для сериализации сообщений JSON?

Question

Мы строим отдельную систему низкоуровневых клиентов C ++ в дикой природе и ядра dotnet 2.1 C # WebAPI.

В настоящее время мы решили сериализовать классы сообщений в строки JSON и отправлять их по проводам.и десериализовать их обратно.

Но этот подход начинает становиться громоздким, так как эти классы живут независимо.Таким образом, изменения в классе сообщений C # нарушают сериализацию с соответствующим классом сообщений C ++ и наоборот.

Есть ли какая-либо совместимость C # / C ++, в которой мы могли бы извлечь выгоду в этом сценарии?

Или мыоставлен один на один с управлением проектами классов сообщений вручную, чтобы не допускались изменения только одной стороны уравнения?

Answer 1

Как прокомментировал Ричард Ходжес:

Создайте git-репо, задачей которого является поддержка проекта буферов протокола, который создает библиотеки c ++ и c #, инкапсулирующие одну и ту же версию источников .proto.Свяжите ваши c ++ и c # проекты с двумя общими библиотеками.

Answer 2

В настоящее время невозможно решить проблему с переименованным классом сообщений C #.Однако вот одно решение, в котором вы можете оставить поле 'aliases' в вашем JSON, чтобы указать оригинальное имя вашего объекта JSON, например:

{ ALIASES: { message: { ALIASES: ["ORINGINAL_NAME_OF_FIELD_MESSAGE1", "ORIGINAL_NAME2", "ORIGINAL_NAME3"], }, property: { ALIASES: ["OLD_PropertyName", "OldName"], some_string: ["old_Sub_PropertyName"], some_array: ["Old_array"] some_number: null } }, message: "some messages here", property: { some_string: "VALUE", some_array: [1, 2, 3, 4, 5], some_number: 0 } }

В этом примере JSON приводится полекаждого псевдонима каждого свойства, используемого в JSON, вы всегда можете правильно десериализовать его, так как вы можете знать все прежние имена любых узлов.

Единственное, что нужно помнить - не изменять узел "ALIASES".

• Этот метод требует переписывания ваших функций JSON stringify и parse.