Nach langem suchen habe ich heute endlich eine Erklärung und eine Lösung für die Fehlermeldung "The state information is invalide for this page" gefunden. Das Problem ist extrem weitreichend und wird durch eine winzige Kleinigkeit ausgelöst, dass ich mich entschlossen habe diesen Fall einmal genauer zu beschreiben.

Wir haben eine ASP.NET 2.0 Web Applikation geschrieben, die in der Entwicklung einwandfrei läuft und getestet wurde. Nun ging diese Applikation in das Live System über und, (wie es bei größeren Web Anwendungen vorkommen kann) somit nicht nur auf einem Web Server sonder auf zwei WebServern läuft. Neben der Kleinigkeiten, das die machinkey in der web.config oder machine.config auf beiden WebServer gleich lauten muss will ich jetzt gar nicht sprechen.

Die Applikation ist auf dem Live System erfolgreich und fehlerfrei gelaufen. Leider häuften sich dann die Aussagen der Benutzer, das die Applikation ab und zu eine Fehlersituation auswirft. Nach näherer Betrachtung und Analyse der Fehlermeldung könnten wir zwei Seiten ausmachen, die sporadisch die Fehlermeldung gebracht hatten:

Der Hinweis auf den ViewState lässt ja erst einmal darauf schließen, das durch die beiden WebServer der State nicht richtig aufgelöst werden kann, wenn z.b. ein Request auf Server 1 landet und der darauffolgende Request auf Server 2. Wenn diese beiden Server nicht auf den gleichen Stateserver verweisen, kann diese Fehlermeldung vorkommen. In unserem Fall war das aber nicht so, also mussten wir weiter forschen… In der Fehlermeldung konnten wir dann noch weitere Informationen entnehmen wie z.B. die Meldung:

"Could not load file or assembly "App_Web_4ec219hu, Version 0.0.0.0 Culture=neutral, PublicKeyToken=null …"

Und diese Meldung hat mich dann auf den richtigen Weg gebracht. Wenn man sich das Ausführungsmodell von ASP.NET anschaut, wird folgendes auf dem WebServer bei jedem Request durchgeführt:

• File ASPX laden
• CodeBehind Klasse compilieren und ein dynamisches Assembly erzeugen oder aus dem Cache laden

Die Fehlermeldung lässt darauf deuten, das der Webserver ein dynamisch erzeugtes Assembly nicht finden kann, weil er es für die Pageklasse benötigt. Das kann ja passieren, wenn man mehrere WebServer hat und das Assembly mit einem autogenerierten Namen nur auf dem ersten WebServer erzeugt wurde und der Request auf dem zweiten WebServer landet.

Aber wieso ist das ein Problem, da bei jedem Request das ASP.NET Framework ja die CodeBehind Klasse neu compiliert, wenn er sie nicht finden kann, somit sollte auf dem zweiten Server das nicht vorhandende Assembly auch erzeugt werden? Das passiert auch und bis dahin läuft alles richtig wie gewünscht und gedacht… ABER…

Wenn man nun in seiner PageKlasse einen ViewState mit einem Objekt setzt, dessen Klassen-Beschreibung innerhalb eines Autogenerierten Assemblies liegt, wie z.B folgendes Property mit einem Enum:

public partial class Admin_Security : System.Web.UI.Page
{
    public enum PageView { Liste = 0, Detail };
    public PageView CurrentView
    {
         get
         {
             if (ViewState["Admin_Security_CurrentView"] != null)
                return ((PageView)ViewState["Admin_Security_CurrentView"]);
             return (PageView.Liste); 
         }

         set
         {
             ViewState["Admin_Security_CurrentView"] = value;
         } 
    }
}

Dann passiert folgendes: Das Objekt in der ViewState Variable "" wird für den ViewState ja serialisiert und bei diesem Prozess wird auch der Typ mit vollqualifizierten Namen in den Serialisierungsstream geschrieben, somit die Referenz auf das autogenerierte Assembly.

Wird nun der Request von dem zweiten Server bearbeitet, versucht der Server den ViewState wieder zu deserialisieren und holt die Typ Definition aus dem Stream und versucht so ein Objekt zu instanziieren. Da das autogenerierte Assembly aber nicht auf diesem Server liegt und er auch keine Ahnung hat wo er das Assembly herbekommen soll, kommt es zu der Fehlermeldung:

"Could not load file or assembly "App_Web_4ec219hu, Version 0.0.0.0 Culture=neutral, PublicKeyToken=null …"

Das hat zur Folge, dass der ViewState nicht deserialisiert werden kann und es kommt zu der Fehlermeldung:

"The state information is invalid for this page …"

Quod erat demonstrandum!

Die Lösung:
Das Problem kann man also umgehen, wenn man dafür sorgt, das es keine Objekte in ViewState gehalten werden, deren Klassendefinitionen in autogenerierten Assemblies liegen.