1

お客様の場所にインストールされるアプリケーションがあります。このアプリケーションは、Windowsサービスとして実行されている自己ホスト型のWCFサーバーと、この問題に関係のないクライアントアプリケーションで構成されています。

WiXで生成された.msiファイルをバックグラウンドでダウンロードし、お客様がインストールを選択したときにインストールされるようにすることで、更新をお客様に公開します。インストール手順は次のとおりです。

  1. サーバーはブートストラッパーアプリケーションを一時パスにコピーして実行し、インストールするMSIファイルへのパスを渡します
  2. ブートストラッパーは、MSIファイルのアップグレードコードを使用して以前のバージョンをアンインストールしてから、新しいバージョンをインストールします。のようなMSIに関連するさまざまなP/Invoke呼び出しを使用してインストーラーを呼び出しますMsiInstallProduct。
  3. ブートストラッパーはサービスを再開します

問題は、ほとんどの顧客サイトに電話をかけると、この自動化されたプロセスが失敗することですが、他のすべての場合と同様に、私たちの場所でのテストと本番の両方で機能します。アンインストール中に失敗することもありますが、通常はインストール中に失敗します。エラーコード1601（InstallServiceFailure）と1603（InstallFailure）は、何が悪かったのかを判断するのにまったく役に立たないのと同じくらい一般的です。

ユーザーがWindows内からブートストラッパーを実行してインストーラーを手動で呼び出すことができるバックアップ手順があります（もちろん、管理者として実行が必要です）。このプロセスは確実に機能し、失敗した自動プロセスとまったく同じインストールロジックを使用します。

すべてのサービスは、少なくともサーバーボックスの管理者権限を持つアカウントとして実行されています。

エラーの原因についてより多くの情報を見つけようとするか、さらに良いことに、そもそもエラーを防ぐために、どこから始めればよいでしょうか。

編集失敗したインストールの詳細ログファイルの一例を次に示します。

=== Verbose logging started: 3/29/2013  8:23:30  Build type: SHIP UNICODE 5.00.7600.00  Calling process: <<PATH TO MSI>> ===
MSI (c) (00:7C) [08:23:30:194]: Resetting cached policy values
MSI (c) (00:7C) [08:23:30:262]: Machine policy value 'Debug' is 0
MSI (c) (00:7C) [08:23:30:418]: ******* RunEngine:
           ******* Product: <<PATH TO MSI>>
           ******* Action: 
           ******* CommandLine: **********
MSI (c) (00:7C) [08:23:30:491]: Client-side and UI is none or basic: Running entire install on the server.
MSI (c) (00:7C) [08:23:30:520]: Grabbed execution mutex.
MSI (c) (00:7C) [08:23:30:562]: Failed to connect to server. Error: 0x800703FA

MSI (c) (00:7C) [08:23:30:605]: Failed to connect to server.
MSI (c) (00:7C) [08:23:30:637]: MainEngineThread is returning 1601
=== Verbose logging stopped: 3/29/2013  8:23:30 ===
4

2 に答える 2

1

これは答えるにはあまりにも広い質問ですが、私が他の顧客のために設計したものは次のとおりです。

1) 昇格されたサービスは、MSI をローカル ディレクトリにダウンロードし、コマンド msiexec /jm foo.msi を使用して MSI を「アドバタイズ」(祝福) します。

2) 昇格されていないクライアント側コンポーネントは、コマンド msiexec /I foo.msi を使用して MSI をインストールします。

MSI は適切に設計され、UAC に準拠している必要があります。Install UI から Install Execute への移行は、UAC プロンプトなしで行われます。適切にスケジュールされた (偽装なしで延期された) カスタム アクションのみが管理者特権で実行されます。

すべての種類が解決されると、顧客は自動更新パターンに非常に満足しました。

于 2013-03-08T18:59:39.210 に答える
0

たぶん、別のコーナーを調べる必要があります。

過去に奇妙なインストールの問題に遭遇したとき、それらは通常、本来あるべきではないものを外部からブロックする動作分析ツールが原因でした。そのようなツール (ウィルス スキャナー スイートの一部、または ThreatFire などのスタンドアロン アプリケーション) が問題のコンピューターにインストールされている場合は、更新手順に必要なパーツがどこにも「ブロックされている」としてリストされていないことを確認してください。更新プログラムが動作分析コンポーネントによる自動処理につながるアクションを実行する場合は、それらを確実にホワイトリストに登録してください。

于 2013-04-08T08:26:11.473 に答える