Windows Phone用の更新プログラムを展開する際の社内変更の管理

Question

近い将来、WP7アプリケーションにいくつかの機能を追加します。 hereのように、私はデータベースをいくつか変更します。このようなコードをどこでどのように扱いますか？私は、「更新」で実行されるよりもどこにでもコードを追加する方法はないと思います。それはアプリのコードに固定されています。

私はIsolatedStorageで設定されたフラグを持つことを考えています。 v1.2UpgradeFlagのような名前をつけ、それをfalseに設定します。 App.xaml.csでは、そのフラグをチェックし、フラグがfalseの場合は、アップグレードが実行されていないことを意味し、コードセットを実行してフラグを更新します。

このようなコードを置いておくというアイデアは、複数のバージョンには適用できないかもしれません。

編集：アプリケーションの累積的な更新をどのように管理するのか不思議です。したがって、v1.2では、データベーススキーマを更新するコードがいくつかあります。 v1.3のときに誰かがアプリを購入すればどうなるでしょうか？私は彼らがv1.1に乗りたがらないようにして、1.2のアップグレードコードを実行してv1.3にしてもらいたい。

Answer 1

初めてデータベースをアップグレードする必要があるため、バージョン情報を保持する追加のテーブルをスキーマに追加したいと思うでしょう。データを取得しようとしたときにNotFoundエラーが発生した場合は、アップグレードを実行する必要があることがわかります。そうすれば、余分なファイルを管理することなく、後続のバージョンでプロセスを管理することができます。

累積的な更新を行うには、同じメカニズムを使用できます。あなたは

var currentDbVersion = GetDbVersion(); 
while(currentDbVersion < currentCodeVersion) 
{ 
    switch(currentDbVersion) 
    { 
     case 1.2: 
      RunUpgradeFrom12to13(); 
      break; 
     case 1.3: 
      RunUpgradeFrom12to13(); 
      break; 
     default: 
      break; 
    } 
    currentDbVersion = GetDbVersion(); 
} 

...などV1.2へのV1からデータベースを更新する方法、1.2から1.3に行くための別の方法は、アップグレード・プロセスは、この擬似コードのようなものに見えるかもしれ維持方法を維持することができます

これは、いくつかのコードパスを維持することなく、以前のバージョンから現在のバージョンへのアップグレードを可能にするはずです（1.0から1.2へのアップグレードは決して変更されず、累積ステップごとに既知の開始位置を持つ必要があります）。

そこにははるかに賢明なアイデアがありますが、これが私が考えた最初のものです。