Debugging: how to debug the exception "Type is not marked as serializable", if type IS is marked as serializable

I'm trying to:

((Request.Params["crmid"] != null)) 

on the web page. But he continues to throw an exception for serialization:

Enter 'QC.Security.SL.SiteUser' in the assembly 'QC.Security, Version = 1.0.0.1, Culture = Neutral, PublicKeyToken = null' is not marked as serialized.

A type that is user-defined IIdentity, however, is marked as serializable as follows:

  [Serializable()] public class SiteUser : IIdentity { private long _userId; public long UserId { get { return _userId; } set { _userId = value; } } private string _name; public string Name { get { return _name; } } private bool _isAuthenticated; public bool IsAuthenticated { get { return _isAuthenticated; } } private string _authenticationType; public string AuthenticationType { get { return _authenticationType; } } 

I have no idea how to debug this, since I cannot go into serializer code to find out why it crashes. The call stack is only one frame before it hits [External Code]. And the error message is next to useless, given that the type is clearly marked as serializable. Correction of trial and error also created a type that is not allowed to exclude a member.

It worked fine. But now โ€œsuddenlyโ€ this is not the case, which usually means some dumb error in Visual Studio, but rebooting does not help โ€œthisโ€ time. So now I donโ€™t know if this is a stupid VS error or a completely unrelated error for which Im gets a serialization exception or something that I am doing wrong.

The truth is that I simply do not trust VS anymore, given the number of monstrous persecutions of others that have been "fixed" over the past few months, by restarting VS 2008 or some other reworked workaround.

+4
source share
1 answer

Ok, so I fixed the problem. This was another VS / Cassini issue. By this url and this url Workaround for SiteUser to inherit from MarshalByRefObject.

This is necessary because:

The problem is that cassini will break into separate AppDomains at will, which does not happen in IIS (even though they say it CAN.) . this is, when Atlas tries to convert to JSON to something on the server, it does something and switches the user principle. User is not deserialized, because the assembly is not in the GAC and another AppDomain is not registered.

"Developers dev developers cough"

+7
source

Source: https://habr.com/ru/post/1306532/


All Articles