問題タブ [brokeredmessage]

そのため、新しい Azure Functions プロジェクト v3 を作成し、4.6.2 で実行されていた v1 から関数のサブセットを移植していますが、残りは古いものとして廃止しています。残念ながら、Microsoft.ServiceBus.Messaging から Microsoft.Azure.ServiceBus への変更による BrokeredMessage から Message への変更では、次の逆シリアル化メソッドが失敗するようになりました。

タイプ ストリームのオブジェクトのデシリアライズ中にエラーが発生しました。入力ソースの形式が正しくありません。

問題はエラーの中にありますが、正しい新しいアプローチが何であるかはわかりません。少し不明確です。

シリアライズ

逆シリアル化

物体

One of the best places where I can point to that describes the situation quite well is this thread:

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

_{(I rarely see much getting resolved on that forum. That thread was closed a few years ago, and once that happens, you can usually give up on getting a resolution on there.)}

So imagine you have a string - let's say its value is "test123", and you want to send it over the Azure Service Bus to a legacy system, and that legacy system is using .NET Framework along with BrokeredMessages to receive everything. However you need to use .NET Standard (or potentially Core, if necessary), which relegates you to Message.

This doesn't work out of the box, as once the Full Framework system gets the message and starts trying to deserialize it out of a BrokeredMessage it throws exceptions along the following lines:

There was an error deserializing the object of type System.Byte[]. The input source is not correctly formatted.`

The problem is this: When using Messages in .NET Standard, the serialized form of your body will typically look something like this:

However to make this work with a BrokeredMessage out of the box, it needs to look something more like:

So, to some extent, this can potentially be worked around in the .NET Standard sender by taking the original string, "test123", and just manually padding it to look like the .NET Framework version. However there are multiple items which seem to get in the way of this:

1. There are tiny nuances in the legacy / Full Framework format that are hard to predict. The main place where there seems to be a problem is where you see Ö on the third line above - that byte varies in ways that just seem a little quirky and hard to perfectly predict.

2. That's just for strings. This needs to be able to work with a wide range of generics (and not just ones with the Serializable attribute).

3. So far, I haven't found anything that translates stuff into the legacy format automatically. Even suggestions on the thread above are not perfect and throw exceptions on the receiving end like this:

{"Expecting element 'string' from namespace 'http://schemas.microsoft.com/2003/10/Serialization/'.. Encountered 'Element' with name 'base64Binary', namespace 'http://schemas.microsoft.com/2003/10/Serialization/'. "}

4. Using heuristic reverse-engineering like this is both time-consuming and error-prone.

So what do you do about this when the legacy system is using .NET Framework and BrokeredMessages? In not just my case, but in many other peoples' cases as well, it is not possible to adjust the legacy software to cater to the newer .NET Standard/Core software; it must be done the other way around, if feasible.

Is there a way to resolve this issue? Are Full Framework and Core/Standard systems just directly incompatible in the general case because of this?

In case it matters, I'm doing this with topics, but normally I'd think it'd be the same situation between them and queues.

Update

The title of the question is phrased as a yes-or-no question, but I am looking for an answer that goes into detail.

If no, they are compatible, please clearly explain a very viable method to make these two work together. If yes, they are incompatible, please provide a clear, solid explanation.

In other words, please clearly explain how to put these two together in a professional, viable way that doesn't depend on 20 extra whacky dependencies or something, or please explain why and/or how this is not reasonably possible.