クリックワンスによる配置が急にできなくなってしまった件

Question

よろしくおねがいします。

現在　C/Sシステムで、クライアント側にインストールして使用するアプリケーションがあります。

VS2010、VB.netでコーディング・ビルドしたアプリで、クライアントにはクリックワンスで配置していました。

いままで　何回か機能追加しVerをあげてきたたびにサーバの共有化したフォルダ内の特定のフォルダにモジュール一式を配置すれば

クライアント側から　アプリを起動した際、最新のモジュールにインストールするか？否か？を聞いてきたため、

OKで応えて更新して来れました。

今回　いままで同様　アプリのVerUPに伴い、クリックワンスによる配置をしようとしましたが

クライアント側からアプリを起動しても最新のモジュールにインストールするか？否か？を聞いてこず、

現在のVerのアプリが起動してしまうため、更新ができなくなり困っています。

サーバ　オンプレミス　Win2012　HV　配下のWin2008　R2

クライアントPC：Windows7pro ×　30台　といった構成になります。

どこか見直す箇所などございましたらご教授いただけると幸いです。

Answer 1

いくつか思い付くものとしては、

・サーバーの共有フォルダに必要なファイル等が全て正しく配置されていない。
・発行の際にバージョンを上げていない。
・発行タブにある更新ボタンを押した際に表示されるオプションで、「アプリケーションの更新を確認する」等にチェックが入っていない。

ぐらいでしょうか・・・

ClickOneceでこのようなトラブルが発生したことは、私は軽軽が無いですね・・・

---

★良い回答には回答済みマークを付けよう！ MVP - .NET 　http://d.hatena.ne.jp/trapemiya/

Answer 2

trapemiya さま

さっそくの返信ありがとうございます。

すみません。事象　追加させてください。　そのクライアント30台のうち、数台は更新可能なPCもあります。

NGのマシンは一度、現在Verをコンパネのプログラムの削除からアンインストールして、

再インストール実施後は　クリックワンスによる更新が可能となります。

一度　すべてのPCにアンインストール・再インストールすれば　なんとか対応できるかもしれないのですが

今後もリリースのたびにそれをしなければならないのと、原因が不明のため同じ事象を解決された方があればと投稿させていただきました。

Answer 3

更新を強制したい場合は、ClickOnce 発行時の「このアプリケーションに最低限必要なバージョンを指定する」において、発行バージョンと同じバージョンを指定しておくことをお奨めします。

これにより、新バージョンが強制的に配信されるようになります。（更新確認後、ユーザーに更新確認の選択肢を出すことなく、直ちにアップデートされます）

一方、この最低バージョン(minimumRequiredVersion)の指定が、クライアントにインストール済みのバージョン以下だった場合もしくはそもそも最低バージョンの指定が無かった場合は、ClickOnce 更新時にユーザー側に更新確認のダイアログが表示されることになります。

この更新確認においてユーザーが「スキップ」を選択すると、更新されないだけではなく、以降の更新確認すら表示されなくなります。今回は恐らくこれに該当しているのでしょう。

Answer 4

一度キャンセルされると、次回起動時も更新確認が行われなくなりますので、一度アンインストールするか、最低バージョンを上げた更新バージョンを配置してみてください。

補足ですが、一度スキップ（キャンセル）すると、以後７日間更新確認のダイアログが出なくなります。
私はこれを避けるために、アプリケーションに手動で最新のバージョンの存在を確認する機能を設けています。確認し、あればバージョンアップするかどうかをユーザーが選択できます。

また、最低限必要なバージョンを指定することも諸刃の剣のようなところがあって、これを指定するとユーザーがロールバック出来なくなってしまいます。（もしロールバックが出来たら、最低限必要なバージョンで動作させることを保証できない）
そのため、最低限必要なバージョンを指定することはデフォルトでオフになっているのではないかと推測していますが、私の経験上、リリースしたバージョンに重大なバグがあり、その対策に時間がかかるためにユーザーにロールバックをお願いしたということはありません。ただ、ロールバックで逃げられるという保証も大きいと思いますので、常に最低限必要なバージョンを指定するのではなく、その時々のバージョンアップの内容を考慮して判断するのも一つのやり方だと思っています。例えば、データに不整合が発生することを修正するバージョンアップは、最低限必要なバージョンを指定し、かつアプリケーションの開始前に更新チェックを行うにするなどです。（更新の確認をアプリケーションの開始後に行うにしていると、一度は旧バージョンで実行されてしまう）

---

★良い回答には回答済みマークを付けよう！ MVP - .NET 　http://d.hatena.ne.jp/trapemiya/

Answer 5

魔界の仮面弁士さま

回答有難うございます。

調べるとユーザがスキップしてしまうと次回更新まで7日後がデフォルトの仕様ということが分かり、そういったユーザのオペレーションも疑ったのですが、今回のリリースではユーザ依頼ではなく、モジュール更新後に我々がクライアントPCからテスト的にクリックワンスによる配布を実施した際、不具合を確認。

ちなみに更新確認をせずに強制更新もできることがわかったため、そのVerのモジュールも　所定の共有フォルダに配置。

現象変わらずでした。

クライアントによって事象が異なるということはクライアントのフレームワークのVerに依ることはあるのでしょうか？

Answer 6

この 7日間という期日は変更できなかったはず。

今回の事象に関して、私自身は Ver 依存という認識は無いのですが、事象の発生したクライアントにおいて、フレームワーク Ver に共通点があったということでしょうか？

バッチ処理や仮想化された実験環境など、オペレーションミスの可能性を完全に否定できる段階に無いのですが、テスト環境というのであれば、念のために 7 日間経過後に動作を確認してみるのも手かもしれません。

また、バージョンアップを強制するのであれば、setup.exe を叩いてみるのも良いかと思います。.appref-ms からの自動更新がスキップされた状態であっても、setup.exe からの導入であれば、強制アップデートされるかと。

Answer 7

7 日間という値の変更はできませんが、レジストリには記録が残っているようですね。

実験結果によるものなので、Undocumented な情報ですが、
HKEY_CLASSES_ROOT\Software\Microsoft\Windows\CurrentVersion\Deployment\SideBySide\2.0\PackageMetadata\{2ec93463-b0c3-45e1-8364-327e96aea856}_{3f471841-eef2-47d6-89c0-d028f03a4ad5}
の中の配置アプリケーションのエントリに、
{2ad613da-6fdb-4671-af9e-18ab2e4df4d8}!UpdateSkippedDeployment
{2ad613da-6fdb-4671-af9e-18ab2e4df4d8}!UpdateSkipTime
という値が、UTF-16 な NULL 終端文字列として REG_BINARY で保存されていました。
　


前者は通常 NULL (00 00) ですが、スキップされていた場合には、
assemblyIdentity 相当の文字列が記録されます。

後者は、解除される日時を示しているようで、
DateTime.UtcNow.AddDays(7.0).ToString("yyyy/MM/dd HH:mm:ss" & vbNullChar)
に相当する文字列が記録されていました。
（ちなみに UpdateSkipTime を過去日付にしたところ、更新確認が実施されました）

ゆえに、レジストリの上記エントリの記録から、UpdateSkipTime に記載された日付の 159 時間前(6.625日前)を逆算することで、「スキップが実施された日時」を確認することができそうです。

Answer 8

trapemiyaさま

再度の回答ありがちうございます。

配布が便利ということで　クリックワンスを導入しましたが

ロールバックの可否決定も　運用を考慮して選定する必要があるのですね。

勉強になります。　ただ、今回の事象が解決に至ってないので、もう少し調べるか、配布方法自体検討してみます。

ありがとうございました。

Answer 9

魔界の仮面弁士さま

回答有難うございます。

その後の調べで　どうやら、現行Ver　アプリを起動時に　クリックワンスをコールしてないような印象です。

手動でサーバの共有フォルダ内のクリックワンスを叩くと更新を聞いてきます。応答すると勿論インストールします。

現在時点で分かったこと

・ネットで指摘されていたオンラインキャッシュクリアのプログラムを作成し、事象の出ているクライアントで実行。→事象変わらず。

・事象マシンでアンインストール・再インストール、もしくは　手動で　サーバ共有フォルダのクリックワンスを叩くと更新を聞いてきてインストール可能になる。

・事象マシンと、なしマシンとの.netF/WのVerに差異はなし。

・セキュリティソフトは同一。設定もデフォルトのまま。

です。

急に更新不可となったマシンの原因は良く分かりませんが、今回はサーバ共有フォルダ内のクリックワンスを手動で叩いて更新をすすめたいとおもいます。

　サーバ共有フォルダ内のクリックワンスのショートカットをクライアントのスタートアップにでも入れて起動させれば、よいですかね・・・・。

というかそれが、正しい運用なのでしょうか？

Answer 10

今回の作業前、たとえば「サーバーに新バージョンを配置する前」に、既にスキップ状態になっていたという可能性は無いでしょうか。

『急に更新不可になった端末』それぞれに対して、先ほどの 2 箇所のレジストリ エントリの内容を調査することはできますか？ そこをみれば、「最初に障害が発生し始めた時刻」までは特定できますので、その時刻当時に行われていた作業内容をトレースすることで、原因を特定できるかもしれません。

その後の調べで　どうやら、現行Ver　アプリを起動時に　クリックワンスをコールしてないような印象です。

『クリックワンスをコールしてない』というのは、具体的にはどういう状態を指しているのでしょうか。たとえば、サーバー側のアクセスログはどうなっていますか? Fiddler 等での通信トレースはどうですか?

更新がスキップされる期間だとしても、appName.appliaction へのアクセスは発生するものと認識しているのですが、それすら発生していないのだとすると、また別の要因かもしれません。

更新スキップが発生しているのだとすれば、サーバー上の配置マニフェスト(appName.appliaction)が、!UpdateSkippedDeployment に記録されたバージョンと一致していた場合、!UpdateSkipTime の時刻になるまで、更新作業が実施されません。この場合、ログに残るのは appName.application へアクセスのみとなり、.deploy 等へのアクセスは発生しないことになります。

ただ、更新そのものが禁じられているわけでは無いので、特定バージョンの配置マニフェストの URL を直接呼び出して更新させることは可能です。ただ、それは緊急回避でしょう。

今後の対策としては、ApplicationDeployment クラスによるカスタム更新を実施するとか、そもそもスキップされないよう、minimumRequiredVersion を調整することだと思います。（自分は後者で回避しています）

Answer 11

魔界の仮面弁士さま　

ありがとうございます。

QAの時系列が前後してしまったようです。

レジストリ情報は未だ確認できていません。

明日　業務終了後に作業時間を確保できたため、現地で上記点も含め改めて調べたいと思います。

結果も含めて報告させていただければと思います。

Answer 12

教えてnet さん、こんにちは
フォーラム オペレーターの立花楓です。

本件について、問題は解決しましたでしょうか。
進展がございましたらこちらのスレッドへご返信いただけますと幸いです。

また、参考になる情報がありましたら、投稿者からの [回答としてマーク] をお願いします。
 
宜しくお願いします。

---

MSDN/TechNet Community Support 立花楓

Answer 13

フォーラム オペレーターの立花楓さま

返信おくれました。申し訳ありません。

その後　対応としては、

サーバー側のアクセスログやクライアントのレジストリ、 Fiddler 等での通信トレースは調査しきれませんでした。

クリックワンスによる更新は諦めて、いったん現在インストールしたアプリを「プログラム一覧から削除」実施後、再インストールで回避しました。

いろいろとご教示ありがとうございました。

次回以降、念のためスキップ不可の設定でデプロイします。

今後ともよろしくお願いします。