2009-11-11 4 views
1

Je stocke un tableau d'une classe sérialisable personnalisée en session sur mon site. Quand une page du site change, elle devient soudainement invalide et m'indique qu'elle ne peut pas convertir le type en son propre type. Je suppose que les numéros de version de la classe changent ou quelque chose ?!La modification de page ASP.NET provoque un tableau d'objets dans Session pour être impossible de convertir son propre type?

J'apprécierais d'éviter les réponses «Ne pas utiliser la session», à moins que ce ne soit une solution vraiment simple. Je n'essaie pas de refaçonner tout ce processus.

Unable to cast object of type 'ShipmentPackages[]' to type 'ShipmentPackages[]'. 

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Exception Details: System.InvalidCastException: Unable to cast object of type 'ShipmentPackages[]' to type 'ShipmentPackages[]'. 

Source Error: 


Line 21:   Else 
Line 22:    If Not Session("ShipmentList") Is Nothing Then 
Line 23:     ShipmentList = DirectCast(Session("ShipmentList"), ShipmentPackages()).ToList 
Line 24:    End If 
Line 25:   End If 
+0

Avez-vous par hasard plus d'un espace de noms ici? Peut-être un client de service Web et un assembly référencé avec les mêmes noms de type? –

+0

non, ce code fonctionne bien entre les modifications apportées à cette page. une fois qu'une modification est faite, c'est quand ce qui est en session ne correspond plus ... quand asp.net recompile la page, la classe est-elle rendue comme une nouvelle version ou quelque chose? Je pense que même ainsi, ce serait convertible/castable. – TheSoftwareJedi

Répondre

1

J'ai vu ce message un certain nombre de fois moi-même, c'est très énervant! Comme vous l'avez souligné, c'est probablement parce que la version d'assemblage a changé. Dans Asp.Net, lorsque la page change, le code est recompilé. Selon où vous placez la classe déterminera si la classe est recompilée avec la page ou non. Je suggère de déplacer toutes les classes de type "modèle" vers un projet séparé. Cela permettra d'éviter ce problème ainsi que l'envie de mélanger vue/contrôleur et le code du modèle :).

Vous pouvez également essayer de sérialiser l'objet en session au format XML. Si vous le faites, vous devriez pouvoir le désérialiser même si l'assemblage change, mais pas si les propriétés de l'objet changent. Je sais que vous avez dit que vous ne vouliez pas entendre cela, mais vous pourriez également envisager de ne pas placer d'objets dans la session. Cela rend difficile l'évolutivité de votre application si le moment arrive que c'est nécessaire. Le plus tôt vous fixerez cela, plus il sera facile de réparer.

1

Il y a quelques jours, j'ai été ennuyé par ce problème aussi. La première solution d'Alas Brian ne fonctionnera que tant que vous n'aurez pas besoin de recompiler le "projet-modèle". Si vous faites cela (à cause d'un bug, etc.) et mettez à jour l'application en cours (avec les utilisateurs qui tiennent leur session pendant le processus de mise à jour, ce qui est fait), vous obtenez l'exception suivante :-(!

Dans mon cas particulier, la meilleure solution était vraiment facile! J'ai changé "DirectCast" en "TryCast" .Si la version d'assembly a changé et que la conversion échoue, trycast ne retournera rien, dans ce cas, ou si je n'ai pas écrit le dictionnaire/collection la session encore, je récupère mes données (encore) sur la base de données et les stocke après, la prochaine fois que le casting fonctionnera ;-)! Et un autre bon point, cela fonctionne aussi si l'interface de l'objet va changer!