我们有一个NServiceBus 6环境，其中包含许多服务，这些服务通过自定义SqlDataBus：IDataBus使用DataBusProperty在彼此之间发送文件。
使用内置的JSON序列化程序在NSB6上运行良好，但是在我们移至NSB7和NewtonsoftSerializer之后，现在已失效。
从我们的类中删除DataBusProperty并仅使用byte []即可正常工作。我们还尝试将DataBus更改为FileShareDataBus，但遇到相同的异常：
NServiceBus.MessageDeserializationException: An error occurred while attempting to extract logical messages from incoming physical message c7b5cd47-c1b7-4610-9f6c-aa7800cc9b64 --->
Newtonsoft.Json.JsonReaderException: Error reading bytes. Unexpected token: StartObject. Path 'Data.Key', line 1, position 68.
即使服务正在向自身发送消息，此操作也会失败。我们还可以看到写入文件存储的文件，无论是在Sql还是File Share上，因此它们都可以很好地序列化。
错误队列中的有效负载示例是
{"ExecutionId":"1db85105-a71c-4b29-87da-9b7ae6518c1c","Data":{"Key":"2019-06-26_13\\6a2b63c7-12b0-46dd-8b92-f1fc743d27c1","HasValue":true}}
当它在NSB6 + JsonSerializer中工作正常时，如何在NSB7 + NewtonsoftSerializer中反序列化呢？
谢谢
答案 0 :(得分：1)
我花了大约8个小时试图弄清楚到底发生了什么，并且意识到，无论出于什么原因，NSB7都希望使用无参数的构造函数和可设置的属性。我要回过头来看看是否会发生这种变化，但是我希望我们必须调整所有消息类以适应该范式。
答案 1 :(得分：0)
尽管数据总线属性应该起作用，但是数据总线属性还有一种替代方法，它可以通过发送选项使用流附件：
取决于使用Streams的用例，可能是一种更有效的方法。