Debugging: Comment déboguer « Type est pas marqué comme sérialisable » exception lorsque le type est marqué comme sérialisable

Question

Je suis en train de:

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

dans une page Web. Mais il ne cesse de lancer une exception sérialisation:

Type 'QC.Security.SL.SiteUser' dans assembly 'QC.Security, Version = 1.0.0.1, Culture = neutral, PublicKeyToken = null' est pas marqué comme sérialisable.

Le type, un IIdentity personnalisé, est cependant marqué comme sérialisable comme suit:

[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; } } 

Je ne sais pas comment déboguer ce que je ne peux pas entrer dans le code sérialiseur pour savoir pourquoi son tomber. La pile d'appels n'est profonde que d'une image avant qu'elle ne touche [Code externe]. Et le message d'erreur est à côté de inutile étant donné que le type est clairement marqué comme sérialisable. Les ajustements d'essai et d'erreur ont également produit un type n'est pas résolu pour l'exception de membre.

Cela fonctionnait bien. Mais maintenant "tout d'un coup" ce n'est pas ce qui signifie généralement un bug bête dans Visual Studio, mais le redémarrage n'aide pas "cette" fois. Donc maintenant je ne sais pas si c'est un bogue VS stupide ou une erreur complètement indépendante pour laquelle je reçois une exception de sérialisation ou quelque chose que je fais mal. La vérité c'est que je ne fais plus confiance à VS étant donné le nombre de chasses aux oies sauvages que j'ai eues au cours des derniers mois qui ont été "corrigées" en redémarrant VS 2008 ou une autre solution de contournement redoutable.

Answer 1

O.k donc j'ai résolu le problème. C'était/est encore un autre problème VS/Cassini. Selon this url et this url la solution de contournement est de rendre SiteUser hériter de MarshalByRefObject.

Cela est nécessaire parce que:

Le problème est que Cassini se casseront dans AppDomains séparés à volonté, qui ne se produit pas dans IIS (même si elles dire CAN). En raison de cela, quand Atlas tente de convertir au JSON à quelque chose sur le serveur , il fait quelque chose et passe et le principal personnalisé .user ne deserialize parce que l'assemblée est pas dans le GAC et pas enregistré avec l'autre AppDomain.

« DÉVELOPPEURS développeurs toux »