何が起きるか
更新の適用は、展開した一式を正規の位置へ入れ替えて App を起動し直すところで終わる。起動し直した App が立ち上がったかどうかは見ていない。
立ち上がらない一式が入ると、利用者は App を開けなくなる。退避した .old は残っているが（後始末はウィンドウを立てられた後に行うため）、戻す経路が無い。手で app.old を app へ戻す必要がある。
どういう一式で起きるか
配布 ZIP が壊れている場合である。digest が保証するのは「公開されている配布物そのものを取れたこと」までで、中身が起動できることではない。
#48 では、正規の位置へ触る前に下記を確かめるようにした。
app / cli のディレクトリapp / cli の実行ファイル (.exe) と本体アセンブリ (.dll)- 展開した
app の埋め込み版が記録のタグと一致すること
ただし配布は自己完結・複数ファイルであり、起動には他にも hostfxr.dll などのランタイムが要る。必須ファイルを名前で数え上げていく方針だと、この一覧は数百件あり、増えるたびに追随しなければならない。そもそも「起動できるか」を名前の一覧で近似していること自体に無理がある。
案
起動し直した App を、更新ヘルパが起こした後に数秒見る（#48 で更新ヘルパ自身に対して行っているのと同じ形）。その間に落ちていたら、退避した .old を正規の位置へ戻し、staged を捨てて旧版を起動し直す。
必要なもの。
UpdateInstaller に「適用済みの入れ替えを戻す」経路。いまの RollbackSwapped は適用の途中の失敗にしか使えない- ヘルパ側で、起動し直した App の生存を見る区間
- 戻せなかった場合の扱い。
UpdateRollbackException と同じく、壊れた一式を起動し直そうとしない
なぜ別立てにするか
適用の後半の流れを変えるうえ、Linux では実機で確かめられない。#48 の検証（テスト版プレリリースでの実機確認）を経て、置き換えそのものが期待どおり動くことを見てから入れたい。
前提
何が起きるか
更新の適用は、展開した一式を正規の位置へ入れ替えて App を起動し直すところで終わる。起動し直した App が立ち上がったかどうかは見ていない。
立ち上がらない一式が入ると、利用者は App を開けなくなる。退避した
.oldは残っているが（後始末はウィンドウを立てられた後に行うため）、戻す経路が無い。手でapp.oldをappへ戻す必要がある。どういう一式で起きるか
配布 ZIP が壊れている場合である。digest が保証するのは「公開されている配布物そのものを取れたこと」までで、中身が起動できることではない。
#48 では、正規の位置へ触る前に下記を確かめるようにした。
app/cliのディレクトリapp/cliの実行ファイル (.exe) と本体アセンブリ (.dll)appの埋め込み版が記録のタグと一致することただし配布は自己完結・複数ファイルであり、起動には他にも
hostfxr.dllなどのランタイムが要る。必須ファイルを名前で数え上げていく方針だと、この一覧は数百件あり、増えるたびに追随しなければならない。そもそも「起動できるか」を名前の一覧で近似していること自体に無理がある。案
起動し直した App を、更新ヘルパが起こした後に数秒見る（#48 で更新ヘルパ自身に対して行っているのと同じ形）。その間に落ちていたら、退避した
.oldを正規の位置へ戻し、staged を捨てて旧版を起動し直す。必要なもの。
UpdateInstallerに「適用済みの入れ替えを戻す」経路。いまのRollbackSwappedは適用の途中の失敗にしか使えないUpdateRollbackExceptionと同じく、壊れた一式を起動し直そうとしないなぜ別立てにするか
適用の後半の流れを変えるうえ、Linux では実機で確かめられない。#48 の検証（テスト版プレリリースでの実機確認）を経て、置き換えそのものが期待どおり動くことを見てから入れたい。
前提
.oldは残るので、手で戻せば復旧できる