CODEWITHSUNDEEP
asp.net.netjsondeploymentviewstate
joelsand
joelsand

Reputation: 2275

ViewState and serialized object versioning

We are using ASP.NET viewstate to store our own objects (ie, not just primitive types). Each time we do a build, the build number is incremented. The issue we are trying to work around is during a server update:

  1. User loads the page
  2. We deploy a new build of the web application

  3. User causes a postback on the same page, and an exception is thrown:

    • HttpException: The state information is invalid for this page and might be corrupted.
    • ViewStateException: Invalid viewstate.
    • ArgumentException: The serialized data is invalid.
    • FileLoadException: Could not load file or assembly '[our assembly], Version=[our new version], Culture=neutral, PublicKeyToken=...' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference

I understand why it's happening - the ViewState was serialized with the previous version of the class, and is then trying to deserialize with the new version and .NET serialization doesn't support that.

We've considered creating a custom PageStatePersister and using JSON (and then encrypting it) to serialize/deserialize instead, since the data members are almost always compatible between builds.

Any other ideas?

Upvotes: 2

Views: 491

Answers (1)

David Chaverri
David Chaverri

Reputation: 56

First of all is not a good idea to have data serialized on viewstate , one reason is this deserialization missmatch your expriencing, but the other problem is that the data is traveling to the server and going back on every postback.

I would use a simple repository approach that stores that data in cache or session for example so you can ask the repository no matter where and how it is persisted, this is being used to mimic a on-memory repository. so you have something like "MyDataSotarage.GetMyCustomObject()" and "MyDataSotarage.SaveMyCustomObject(CustomObject obj)" so inside the repository have your logic to add the item to cache (using the userid and objct name as the key for instance) or session if you like (dont be affraid of them, some people does). It is more a design approach than an implementation aproach but in this way you will completely decouple how the data is stored and you will avoid serialization issues and you will save KBs of network traffic, etc.

Upvotes: 1

Related Questions