EnclosedMessageTypes header contains proxy types

[ramonsmits]

I noticed the following value for the header EnclosedMessageTypes:

Store.Messages.Events.OrderAccepted__impl, NServiceBusMessageProxies, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null;Store.Messages.Events.OrderAccepted, Store.Messages, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null

This seems incorrect. I only expected the interface type(s) but not the dynamic proxy, so in this case the following value:

Store.Messages.Events.OrderAccepted, Store.Messages, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null

[timbussmann]

it seems those types are excluded by this code: https://github.com/Particular/NServiceBus/blob/6.0.0/src/NServiceBus.Core/Pipeline/Incoming/DeserializeLogicalMessagesConnector.cs#L126

the naming confuses me, since this doesn't seem to be only related to v3?

This seems incorrect. I only expected the interface type(s) but not the dynamic proxy

while I'm not sure whether we need that value either, how do you conclude this is incorrect?

[ramonsmits]

@timbussmann The proxy isn't an actual contract type. The header should only contain contract types.

Based on the link you have shared this seems to be a regression as it implies that this was the behavior in V3 and is fixed in V4 or higher and the code seems to be ignoring proxy types (as it indeed should do).

[dbelcham]

We should verify what the v5 behavior is and whether we broke this in v6 or not. Purely from a v6 standpoint its probably that we can simply remove the extra proxy type definition since we are filtering it out when receiving incoming messages. The only risk could be backwards compatibility if this was removed.

[timbussmann]

sending an interface message from v5 yield the following header:

<HeaderInfo>
    <Key>NServiceBus.EnclosedMessageTypes</Key>
    <Value>HeaderMessage, ConsoleHost4-6, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null</Value>
</HeaderInfo>

[andreasohlund]

Since this is confirmed to be introduced in v6 we're flagging this as a bug. This doesn't seems to cause any issues so we can target this for a future release (no urgency to fix)

[boblangley]

We have triaged this issue and will be considering it for inclusion in one of the upcoming maintenance releases for this package.