0

うまく管理されていない古い Wix プロジェクトをクリーンアップする方法についてアドバイスが必要です。問題の 1 つは、現在、プロジェクトに同じファイルの複数のエントリがあり、同じ場所に移動していることです。たとえば、プロジェクト内のいくつかの .wxs ファイルは foo.exe の新しいコンポーネントを定義し、それぞれが異なる GUID を使用し、このファイルを同じ DirectoryRef に送信します。これはまだ問題を引き起こしていませんが、製品でパッチ (MSP) を使用したいのですが、この種のことが動作を台無しにします。

アップグレードを中断せずにこれを解決する最善の方法について疑問に思っています (以前のインストーラーはすべてこのようになっているため)。重複するコンポーネントをすべて削除すると、アップグレード中に未定義の動作が発生します。何が起こっているかというと、1 つ以上の重複するエントリを削除すると、インストーラーがそのファイルの削除操作を生成するということです。ファイルの残りのエントリが新しいバージョンであっても、インストール時の操作順序は保証されません。したがって、これらのファイルの一部は最初に更新され、次に 1 つまたは複数の削除操作によって更新されたファイルが削除されます。したがって、アップグレードの最後にはいくつかのファイルが失われます。その後すぐに修復を実行すると、ファイルが復元されます。

これを解決する 1 つの方法は、次のリリースで 1 回限りの「ハック」を実行することだと思います。この場合、これらのファイルをセカンダリ ロケーションにコピーし、カスタム アクション ポスト インストールを実行して、ファイルをセカンダリ ロケーションからプライマリにコピーし、一時ディレクトリを削除します。

これを解決できるよりクリーンな方法はありますか?

4

1 に答える 1

0

あなたがしなければならない可能性が高いのは、検証を使用してすべての重複を特定し、それらを修正することです。次に、アップグレードをできるだけ早いスケジュールでメジャー アップグレードに変更します。また、コンポーネント参照カウントの中断を回避するために、インストール場所をわずかに異なるディレクトリに変更する必要がある場合もあります。

クリーンアップしたら、マイナー アップグレードに戻って、パッチ適用について考え始めることができるはずです。代替案は「偽の」パッチです。ホットフィックス メソッドとして公開されていない MSI を使用しましたが、うまくいきませんでした。これは多くの規則に違反しますが、規則のパッチ適用を気にせず、ビジネスを満足させたいだけの組織には役立ちます。

于 2013-10-01T11:35:29.557 に答える