Debugging: How to debug "Type is not marked as serializable" exception when the type IS marked as serializable

rism picture rism · Apr 10, 2010 · Viewed 11.6k times · Source

I'm trying to:

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

in a web page. But it keeps throwing a serialization exception:

Type 'QC.Security.SL.SiteUser' in assembly 'QC.Security, Version=1.0.0.1, Culture=neutral, PublicKeyToken=null' is not marked as serializable.

The type, a custom IIdentity, is however 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've no idea how to debug this as I cant step into the serializer code to find out why its falling over. The call stack is only one frame deep before it hits [External Code]. And the error message is next to useless given that the type is clearly marked as serializable. Trial and error adjustments also produced a Type is not resolved for member exception.

It was working fine. But now "all of a sudden" it doesn't which typically means some dumb bug in Visual Studio but rebooting doesn't help "this" time. So now I dont know if it's a stupid VS bug or a completely unrelated error for which Im getting a serialization exception or something I'm doing wrong.

The truth is I just dont trust VS anymore given the number of wild goose chases Ive been on over the last several months which were "fixed" by rebooting VS 2008 or some other rediculous workaround.

Answer

rism picture rism · Apr 10, 2010

O.k so I've fixed the problem. It was/is yet another VS / Cassini issue. As per this url and this url the workaround is to make SiteUser inherit from MarshalByRefObject.

This is neccessary because:

The issue is that cassini will break into separate AppDomains at will, which doesn't happen in IIS (even though they say it CAN). Because of this, when Atlas is trying to convert to the JSON to something on the server, it does something and switches and the .User custom principal doesn't deserialize because the assembly is not in the GAC and not registered with the other AppDomain.

"Developers developers developers cough"