5

（編集：質問が変更されました。）

私は、InstallShield 2010 によってビルドされたインストーラーを備えた製品を持っており、すべてのアカウントで「新規」インストールとして問題なくインストールされているように見えます。

このコンポーネントまたはそのコンポーネントをバグ修正などで更新するため、定期的にインストールの内容を変更します。その際、更新されたファイルのメタデータのバージョン番号を変更しようとしますが、それができないコンポーネントがあります。もちろん、最終的には常に最新の変更日になります。MSI データの製品のバージョン番号も変更します。ただし、パッケージコードは毎回変更していません。

製品が既に存在するシステムで一部のユーザーがインストーラーを実行すると、更新モードの UI (「更新しますか?」など) が表示され、インストーラーが完了したように見えます。ただし、特にバージョン番号が変更されていない場合は特に、後で「修復」インストールが実行されるまで、更新されたファイルが古いファイルを常に上書きするとは限りません。この動作を変更しないでください。

何が起きてる？より良い結果を得る方法はありますか？製品を改訂したり、コンポーネントを更新したりするたびに、パッケージ コードを変更する必要がありますか? (編集: リリースをビルドするたびにパッケージ コードが変更されるため、これは問題の原因ではありません。)

編集：これは更新UIですが、更新後のメンテナンスは、実際に目的のインストールを完了するものです.

4

4 に答える 4

3

ビルドごとに PackageCode を変更する必要があります。実際、デフォルトでは、InstallShield にはまさにこれを行うビルド設定があります。

実際、MSDN ヘルプ トピックのパッケージ コードには次のように書かれています。

同一でない .msi ファイルには、同じパッケージ コードを使用しないでください。パッケージ コードは、インストーラーが特定のインストールに適したパッケージを検索して検証するために使用する主要な識別子であるため、変更することが重要です。パッケージ コードを変更せずにパッケージを変更した場合、インストーラーが新しいパッケージの両方に引き続きアクセスできる場合、インストーラーは新しいパッケージを使用しない場合があります。

これが、アップグレード エクスペリエンスではなくメンテナンス UI エクスペリエンスを取得する理由です。

これを開始したら、次に、アプリケーションにサービスを提供するためにマイナー アップグレード、メジャー アップグレード、またはパッチをサポートするかどうかを検討する必要があります。これを理解し、インストーラーを本番環境に置く前に戦略をテストすることが非常に重要です。

于 2011-01-15T00:22:12.077 に答える
2

上記の@ChristopherPainterの回答で、InstallShieldにパッケージコードを自動生成する設定があることも知りましたが、彼はそれがどこにあるのかは言いませんでした. だから、それを探している他の人のために：

この設定は、メディア / リリース / (リリース名)、製品構成、一般タブにあります。「パッケージ コードの生成」が表示され、[はい] に設定されていることを確認できます。

于 2014-07-02T15:21:02.933 に答える
1

インストーラーは、不変のファイル バージョン情報に基づいて、想定どおりに動作しています。

ファイルを変更するたびにファイル バージョンを更新するのが理想的ですが (バージョン情報を含むファイルの場合)、何らかの理由でそうしない場合でも、コンポーネントを強制的に更新する方法がいくつかあります。

簡単な方法は、REINSTALLMODE プロパティを設定することです。「amus」に設定すると、すべてのファイルが再インストールされます。MSDN を参照してください - http://msdn.microsoft.com/en-us/library/aa371182%28v=vs.85%29.aspx

これは機能しますが、独自の問題が発生する可能性があります。たとえば、パッケージにいくつかの再配布可能コンポーネントを含めている場合、それらの再配布可能コンポーネントを強制的に再インストールすると、再配布可能コンポーネントがバックレベルになる可能性があります。

個々のコンポーネント レベルで制御できるやや難しい方法は、カスタム アクションを使用することです。MsiSetComponentState を呼び出して、各コンポーネントを必要な状態に明示的に設定します。 http://msdn.microsoft.com/en-us/library/aa370383%28v=VS.85%29.aspx

私の記憶では、カスタム アクションは CostFinalize の後に行う必要があるため、インストーラーは更新を消去しません。

于 2011-01-15T22:58:13.547 に答える
0

Windows インストーラーがコンポーネントをインストールするかどうかを決定するとき、最初に "keypath" リソースが既に存在するかどうかを確認します。そうである場合、コンポーネント内のリソースはどれもインストールされていません。(Installshield は各ファイルを独自のコンポーネントに配置し、キーパスはファイルであると想定しています。)

キーパス リソースがバージョン管理されたファイルである場合、Windows インストーラーは、同等またはそれ以上のバージョンのファイルが見つかった場合にのみ、それが存在すると見なします。したがって、同じバージョン番号のファイルが既に存在する場合、そのファイルは再インストールされません。したがって、バージョン番号を変更せずにファイルを変更すると、問題が発生します。

編集: 修復によって問題が修正される理由について:c:\windows\installerキーパス リソースの存在/バージョンに関係なく、キャッシュされた MSI ファイルからすべてのコンポーネントが再インストールされると思います。これは、破損したファイルを確実に復元する唯一の方法であるため、論理的に思えます。(MSDN でこれを裏付ける明確なリファレンスをすぐに見つけることができません。申し訳ありません。)

TortoiseSVN の開発者は、1.6.10 より前のバージョンからそれ以降のバージョンにアップグレードする際の TortoiseSVN の同様の問題についてブログに書いています。彼の場合、問題はファイルのバージョンではなく、いくつかのコンポーネントのキーパスの変更であり、結果は同じでした。その場合、修復によってアプリケーションも修正されました。

于 2011-01-15T01:35:03.807 に答える