Masstransit: TypeNameHandling = Auto fails to deserialize message

Created on 17 Oct 2017  路  5Comments  路  Source: MassTransit/MassTransit

Is this a bug report?

Yes

Can you also reproduce the problem with the lastest version?

Reproducible with latest stable MassTransit 3.5.7

Environment

  1. Operating system: Windows 10
  2. Visual Studio version: 2017
  3. Dotnet version: 4.7

Steps to Reproduce

(Write your steps here:)

  1. Clone https://github.com/nkot/typenamehandlingauto-fails
  2. Run it by using Visual Studio
  3. Observe error in console

Expected Behavior

MassTransit is able to deserialize message out of the box

Actual Behavior

Message is not deserialized. Console is spammed with error:
MOVE loopback://localhost/test 8f5a0000-3ede-dc4a-31fd-08d5155e736c loopback://localhost/test_error Fault: Type specified in JSON 'MassTransit.Serialization.JsonMessageEnvelope, MassTransit, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b8e0e9f2f1e657fa' is not compatible with 'GreenPipes.DynamicInternal.MassTransit.Serialization.MessageEnvelope, MassTransit.SerializationGreenPipes.DynamicInternale259301d179d416dbde48e08153bbd64, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Path '$type', line 2, position 71.

Reproducible Demo

https://github.com/nkot/typenamehandlingauto-fails/blob/master/DeserializationFails/Program.cs

Most helpful comment

Dropping an example workaround code (custom JsonConverter) that should fix the issue.
https://github.com/nkot/typenamehandlingauto-fails/blob/master/DeserializationWorkaround/Program.cs

All 5 comments

This is a known issue and will not be fixed. TypeNameHandling should not be modified.

Dropping an example workaround code (custom JsonConverter) that should fix the issue.
https://github.com/nkot/typenamehandlingauto-fails/blob/master/DeserializationWorkaround/Program.cs

@nkot Thanks for the sample code! That approach worked for me.

@phatboyg Am I to understand from https://github.com/MassTransit/MassTransit/issues/195#issuecomment-22528538 that if I were using interfaces exclusively, this scenario would work out of the box? Here's a sketch of the message types I'm working with:

interface IResource { ... }
class SomeResource : IResource { ... }
class AnotherResource : IResource { ... }
class CreateResourceCommand<TResource> where TResource : IResource {
    TResource Resource { get; set; }
}
class DeleteResourceCommand<TResource> where TResource : IResource {
    TResource Resource { get; set; }
}

If your message contracts are all interfaces, there are no types involved because MT creates the backing implementation for the message contracts (interfaces).

Was this page helpful?
0 / 5 - 0 ratings