3

我可以指出的最好的地方之一就是这个线程：

https://github.com/Azure/azure-service-bus-dotnet/issues/239

（我很少在那个论坛上看到很多解决方案。那个帖子几年前就被关闭了，一旦发生这种情况，你通常可以放弃在那里获得解决方案。）

因此，假设您有一个字符串 - 假设它的值为"test123"，并且您希望通过 Azure 服务总线将其发送到旧系统，并且该旧系统使用 .NET Framework 和BrokeredMessages 来接收所有内容。但是，您需要使用 .NET Standard（或可能的 Core，如有必要），它将您降级为Message.

这不是开箱即用的，因为一旦完整框架系统收到消息并开始尝试反序列化它，BrokeredMessage它就会抛出以下异常：

反序列化 System.Byte[] 类型的对象时出错。输入源的格式不正确。`

问题是：在 .NET Standard 中使用Messages 时，身体的序列化形式通常如下所示：

t   e   s   t   1   2   3
116 101 115 116 49  50  51

然而，为了使这项工作BrokeredMessage开箱即用，它需要看起来更像：

@   [ACKNOWLEDGE]   s   t   r   i   n   g   [BACKSPACE]   3
64  6               115 116 114 105 110 103 8             51

h   t   t   p   :   /   /   s   c   h   e   m   a   s   .   m   ...
104 116 116 112 58  47  47  115 99  104 101 109 97  115 46  109 ...

Ö   [BELL]   t   e   s   t   1   2   3
153 7        116 101 115 116 49  50  51

因此，在某种程度上，这可以在 .NET Standard 发送器中通过获取原始字符串 ,"test123"并手动填充它以使其看起来像 .NET Framework 版本来解决。但是，有多个项目似乎阻碍了这一点：

  1. 旧版/完整框架格式中存在难以预测的细微差别。似乎存在问题的主要地方是您Ö在上面的第三行中看到的位置 - 该字节的变化方式看起来有点古怪且难以完美预测。

  2. 这仅适用于字符串。这需要能够使用广泛的泛型（而不仅仅是具有Serializable属性的泛型）。

  3. 到目前为止，我还没有找到任何可以自动将内容转换为旧格式的东西。甚至上面线程上的建议也不完美，并在接收端抛出异常，如下所示：

{“来自命名空间'http://schemas.microsoft.com/2003/10/Serialization/'的预期元素'字符串'..遇到名称为'base64Binary'的'元素'，命名空间'http://schemas.microsoft.com /2003/10/序列化/'。"}

  1. 像这样使用启发式逆向工程既费时又容易出错。

BrokeredMessage那么当遗留系统使用 .NET Framework 和s时，你会怎么做呢？不仅在我的情况下，在许多其他人的情况下，也不可能调整旧软件以适应更新的 .NET Standard/Core 软件；如果可行的话，必须反过来做。

有没有办法解决这个问题？因此，完整框架和核心/标准系统在一般情况下是否直接不兼容？

万一这很重要，我会用主题来做这件事，但通常我认为它们和队列之间的情况是一样的。

更新

问题的标题被表述为是或否的问题，但我正在寻找一个详细的答案。

如果不是，它们是兼容的，请清楚地解释一个非常可行的方法来使这两者一起工作。如果是，它们不兼容，请提供清晰、可靠的解释。

换句话说，请清楚地解释如何以专业、可行的方式将这两者结合在一起，而不依赖于 20 个额外的怪异依赖或其他东西，或者请解释为什么和/或如何合理地做到这一点。

4

0 回答 0