5

WiXベースのインストーラーを複数のサーバーで台無しにして、アンインストール中にファイルやコンポーネント（またはその他の機能）が削除されないようにしました。MSIログは、アンインストールされないすべてのコンポーネントでPreviousPinned=1であることを示しています。

SharedDll countを使用したり、異なるインストーラー間で共有コンポーネントを使用したりするような、気の利いたことは何もありません。

私はそれを私のWiXコードの特定のリビジョンまで追跡したと思います。私はいくつかの愚かなことをしました。私は（意図せずに）空白のGUIDを使用してアンマネージコンポーネントを作成しました

<Component Id="file.ext" Guid="">
    <File .../>
<Component>

また、別のコンポーネントのファイルの場所とIDも変更しました（ただし、Guidではありません）。以前のリビジョンに存在するすべてのコンポーネントはPreviousPinned=1を示し、アンインストールされず、このリビジョンの後に追加された新しいコンポーネントは正しくインストール/アンインストールされます。

インストーラーを通常の状態に戻し、以前に固定されたこれらのコンポーネントを削除するにはどうすればよいですか？

4

4 に答える 4

5

Windowsインストーラーは、実際には空白のGUIDの概念をサポートしています。これは、「インストールするが、コンポーネントを登録しない」ことを意味します：http: //msdn.microsoft.com/en-us/library/aa368007 (VS.85).aspx （ComponentIdエントリは、null GUIDで何が起こるかを説明します）。

WIXでテストしたところ、空白のGUIDエントリを尊重しているようです（つまり、GUIDは自動生成されません）。絶対パス/キーパスとGUIDの間の1：1ルールを覚えておいてください：

  • GUIDを変更する場合は、コンポーネントのキーパスに新しい絶対パスを使用する必要があります。
  • 絶対パスを変更する場合（たとえば、ファイルの名前を変更したり、ファイルを移動したりすることによって）、GUIDを変更する必要があります。

要約すると、GUID参照は、ファイルではなく、コンポーネントのインストールキーパスをカウントします-移動する可能性がありますが、ファイルは新しいGUIDを介して新しいIDを持ちます（異なるフォルダーにある同じ名前の2つのファイルを考えてください-それらは異なりますファイル、異なるID）。

混乱したGUID参照カウントのクリーンアップは、少し面倒な場合があります。ファイル名を変更できれば、問題を効果的に取り除くことができます。また、新しいGUIDを生成するため、古いGUIDの参照カウントへのリンクを解除します。インストールフォルダの名前を変更することもできます（これは、理想的には、すべてのコンポーネントGUIDも変更する必要があることを意味します）。RemoveFileテーブルの概念を使用して、インストールおよび/またはアンインストール時に、コンポーネントとして登録されていないファイル（生成されたファイルなど）を削除できます。

更新（2018年8月）：アプリケーションがLoadLibrary / LoadLibraryExまたは「ハードコード」ファイル名（ロードされるファイル名）に依存している場合は、dllまたはexeファイルの名前を慎重に変更する必要があることを追加します。ソースコード。

于 2009-10-14T17:22:08.923 に答える
0

コンポーネントのIDを変更し、有効なGUIDを使用すると、問題が解決するはずです。

于 2009-10-14T19:24:41.557 に答える
0

簡単な答えは次のとおりです。

はい、GUIDなしでMSIコンポーネントを使用することは、一種のバッチコピー方式です。コピーして忘れてください。もちろん、1つだけ追加する必要があります。オーバーインストールまたはアンインストール（条件「再インストールまたはパッチまたは削除」）またはメジャーアップグレードの前に、すべてのファイルを削除します。それがなければ、それは本当に意味がありません。CMD.exe / c RD / S / Q ....を使用しても、カスタムアクションでこれを行うことができます（もちろん、カスタムコードはこれよりもエレガントです）

それを正しく行えば、MSIが通常持っている、すべてのトラップなしで非常に簡単なセットアップを行うことができます。もちろん、ファイルごとにディレクトリ全体を再帰的に削除すると、より簡単になります。

まだ試していませんが、次のことを行います。GUIDなしの「動的」コンポーネントと通常のコンポーネントを用意し、パッチを提供します。理論的にはこれは機能するはずであり、パッチ間でファイルセットが大幅に変更されることで発生する多くのパッチ適用の問題に対する適切な回避策になります。

于 2013-08-20T09:39:57.537 に答える
0

1.実際、GUIDのないコンポーネントは、実際の「動的ファイルリンク」方式であり、多くの場合、複数のツールや人から誤って評価されています。

その他の「方法」：2。GUIDを自動的に生成することは、単なる自動化ステップです（ただし、もちろん、すべての優れたセットアップビルドインフラストラクチャの一部です:-)私の目には、これは動的ではありません。動的に作成すると、間違って実行するためです。

2a。毎回完全にランダムなGUIDの生成=>間違ったアルゴリズム

2b。コンポーネントが初めて作成されたときにのみGUIDを生成し、新しいリソースに新しいリソースをパックするためのインテリジェントな「差分」認識を実装した=>唯一機能するfile-tree-syncメソッド。しかし、あなたはここで多くの間違いをすることができます...それは専門家のためです。

于 2013-08-20T09:44:10.117 に答える