Storing objects (non-string things) in TempDataDictionary does not round trip correctly

[pranavkm]

Scenario

public class FeedbackController : Controller
{
    private const string _userKey = "user-data";

    [HttpPost]
    public IActionResult SubmitApplication(string name, int age)
    {
        // Do db stuff
        var user = new User { Id = 100, Name = name, Age = age };
        TempData[_userKey] = user;
        return RedirectToAction("WelcomeUser");
    }

    public string WelcomeUser()
    {
        var user = (User)TempData[_userKey];
        return "Welcome " + user.Name;
    }
}

Expected (per behavior in Mvc 5)
Ouputs Hello {userName}

Actual
Unable to cast object of type 'Newtonsoft.Json.Linq.JObject' to type 'User'.

[pranavkm]

It looks like we Json serialize values in TempDataDictionary as opposed to using binary serialization in Mvc 5. Consequently complex types don't deserialize correctly. Perhaps we should consider disallowing storing non-primitive value types + strings in our default implementation if the (totally reasonable) intention is to avoid binary serialization.

[pranavkm]

Minor note: In-memory session state is simply holding on to the object in memory, not serializing them. Consequently, you can store objects that cannot be deserialized in it

public class User
{
   public User(int id) {}
   public string Name { get; set; }
}

This is to counter @danroth27's suggestion to use Json.Net's type name handling behavior to serialize types.

[danroth27]

@pranavkm Consider restricting to only primitives, dictionaries of primitives and arrays of primitives for now.

[pranavkm]

I think this was meant to be assigned to @ajaybhargavb. Let's talk about this before you start working on it.

[Fido789]

In some early beta it was working as expected

var messages = TempData[PageMessagesKey] as IList<PageMessageModel>;

then in beta4 I had to deserialize objects from TempData like this

var messages = (TempData[PageMessagesKey] as Newtonsoft.Json.Linq.JArray)?.ToObject<List<PageMessageModel>>();

but it was working. And in beta5 it is not working at all. I don't think it's going to the right direction. How can I use TempData to store objects in beta5?

[pranavkm]

cc @Eilon. Could you respond to @Fido789 on what the suggested approach is if a user wants to stash complex data types?

[Eilon]

@Fido789 can you log a new bug with the exact case that isn't working? We can have @ajaybhargavb take a look at that - he's the guy who wrote the codes.

[ajaybhargavb]

@Eilon, I believe we made a design decision to not support serialization of complex data types by default. We currently throw an exception saying it can't be serialized.

[Eilon]

Oh, right. We might still want to document some guidance on this then.

[Muchiachio]

So how would you save complex data types, at least until the request is ended?
Is there any other way to do that without using TempData?

[Eilon]

@Muchiachio I believe you can store the data in a dictionary as key/value pairs, and then re-assemble the object on the way out.

[Muchiachio]

No @Eilon, as I understand this was made deliberately

[HttpGet]
public ActionResult Index()
{
    object value = new { Type = "Success", Message = "You got successfully redirected" };
    TempData["messages"] = value;

    return RedirectToAction("New");
}

throws and exception

System.InvalidOperationException
The 'Microsoft.AspNet.Mvc.SessionStateTempDataProvider' cannot serialize
an object of type 'System.Object' to session state.

I would be fine with that, if there is a way to pass these type of objects around without using TempData?

[Eilon]

I mean a real Dictionary<string, string> etc.

[danroth27]

Or you can do whatever serialization you want and store the data as a string or bytes.

[she2]

I want to believe it is the worse kind of design. How do we store complex data then? Any alternative?

[Eilon]

@she2 the recommendation is to serialize it yourself using a serializer that you know has the correct fidelity. The problem with doing this automatically is that there is no serializer that can serialize completely arbitrary data with full fidelity. And only the person writing the app knows what serializer matches the data structure that needs to be serialized. Once you have a string, you can stash that in the state.