2

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?

4

1 に答える 1

1

まず第一に、データを viewstate でシリアル化することはお勧めできません。1 つの理由は、この逆シリアル化が経験と一致しないことですが、もう 1 つの問題は、データがサーバーに移動し、すべてのポストバックに戻ることです。

たとえば、そのデータをキャッシュまたはセッションに保存する単純なリポジトリ アプローチを使用します。これにより、どこにどのように永続化されているかに関係なく、リポジトリに問い合わせることができます。これは、オンメモリ リポジトリを模倣するために使用されます。「MyDataSotarage.GetMyCustomObject()」や「MyDataSotarage.SaveMyCustomObject(CustomObject obj)」のようなものがあるので、リポジトリ内にアイテムをキャッシュに追加するロジックがあります (たとえば、ユーザー ID とオブジェクト名をキーとして使用) またはセッション必要に応じて (恐れる必要はありません。気にする人もいます)。これは実装アプローチというよりも設計アプローチですが、この方法では、データの保存方法を完全に分離し、シリアル化の問題を回避し、ネットワーク トラフィックの KB を節約できます。

于 2013-02-13T20:30:08.453 に答える