title: SignalR doesn't deserialize custom object
body: <p>I'm using SignalR 2.2.2 (Latest release) with .NET 4.5.2</p>
  
  <p>I've this error:</p>
  
  <blockquote>
    <p>Could not create an instance of type
    DF.ApplicationBlocks.IPropertyValueData. Type is an interface or
    abstract class and cannot be instantiated. Path 'Properties[0].Id',
    line 1, position 881.</p>
  </blockquote>
  
  <p>The problem is :</p>
  
  <p>I've a SignalR client (written in .NET, using Signal.Client package) that send a custom object, on this object there is an array of object typed as an interface (IPropertyValueData). The values in the array is an implementation of this interface.</p>
  
  <p>In the signalR client, I've configured to use TypeNameHandling.Auto :</p>
  
  <pre><code>        this._connection.JsonSerializer.TypeNameHandling = TypeNameHandling.Auto;
          this._connection.JsonSerializer.PreserveReferencesHandling = PreserveReferencesHandling.Objects;
          this._connection.JsonSerializer.ReferenceLoopHandling = ReferenceLoopHandling.Serialize;
  </code></pre>
  
  <p>and it does it correctly, as here is an extract of what's sent by the client:</p>
  
  <pre><code>"Properties":[  
      {  
         "$id":"20",
         "$type":"DF.MailFlow.Services.Contract.Data.MailDataProperty, DF.MailFlow.Services.Contract",
         "Id":"5588ce9e-30fb-45b1-afbe-1e6ad0c3e8d4",
  </code></pre>
  
  <p>So the $type property is defined and the value is correct.
  But anyway, the server still trigger the error when the message is received.</p>
  
  <p>I've also configured the server to use TypeNameHandling.Auto, here is how the hub is configured (I use Castle Windsor as IoC):</p>
  
  <pre><code>        var resolver = new WindsorDependencyResolver(WebAPILoader.Container);
  
          var hubConfig = new HubConfiguration()
          {
              EnableJSONP = true,
              EnableDetailedErrors = true,
              EnableJavaScriptProxies = true,
              Resolver = resolver
          };
  
  
          GlobalHost.DependencyResolver = resolver;
  
          // Configure signalR and run it
          app.UseCors(CorsOptions.AllowAll);
          app.Map("/live", map =&gt;
          {
              map.UseCors(CorsOptions.AllowAll);
              map.RunSignalR(hubConfig);
          });
  
          var serializerSettings = new JsonSerializerSettings
          {
              TypeNameHandling = TypeNameHandling.Auto,
              PreserveReferencesHandling = PreserveReferencesHandling.Objects,
              ReferenceLoopHandling = ReferenceLoopHandling.Serialize
          };
          GlobalConfiguration.Configuration.Formatters.JsonFormatter.SerializerSettings = serializerSettings;
          GlobalConfiguration.Configuration.Formatters.JsonFormatter.UseDataContractJsonSerializer = false;
  
          // Register in Castle.Windsor container
          WebAPILoader.Container.Register(Castle.MicroKernel.Registration.Component
                                .For&lt;JsonSerializer&gt;()
                                .UsingFactoryMethod(() =&gt; JsonSerializer.Create(serializerSettings)));
  </code></pre>
  
  <p>I've checked that when the 1st message is received, the the factory method is called and the setting still have the correct TypeNameHandling.Auto.</p>
  
  <p>I also tested to register the serializer this way:</p>
  
  <pre><code>GlobalHost.DependencyResolver.Register(typeof(JsonSerializer), () =&gt; JsonSerializer.Create(serializerSettings));
  </code></pre>
  
  <p>But no way, the server always trigger the same error when the message is received.</p>
  
  <p>Adding to the complexity, the application run both signalr and webapi component (in differnt url). I've checked that the webapi doesn't register any JsonSerializer, and Windsor container used is the same for both component.</p>
  
  <p>Any idea ?</p>
  
  <p><strong>Edit #1:</strong></p>
  
  <p>I just ran on this ticket <a href="https://github.com/SignalR/SignalR/issues/3304" rel="nofollow noreferrer">https://github.com/SignalR/SignalR/issues/3304</a><br>
  Seems just incredible that a bug is listed there without any fix for more than 3 years, even when someone made a PR (<a href="https://github.com/SignalR/SignalR/pull/3343" rel="nofollow noreferrer">https://github.com/SignalR/SignalR/pull/3343</a>)<br>
  So now I'm trying to find a workaround...</p>