問題タブ [major-upgrade]

MSICREATEというプログラムで作成された.msiファイルがあり、次のようにorcaを使用してドクターされています...

InstallExecuteSequenceテーブル

InstallUISequenceテーブル

PropertyTable

アップグレードテーブルを追加しました

また、新しいPackageCodeと新しいProductCodeを割り当てたため、新しいmsiのPackageCode、ProductCode、およびProductVersionの値は、以前にインストールされた製品とは異なります。

以前にインストールした製品でこのmsiを実行すると、古い製品が削除され、新しいプログラムファイルディレクトリが作成され、.exeを除くすべてのファイルが新しい.msiから再インストールされます。修復すると、.exeが作成されます。古い製品を削除した後に（コントロールパネルの追加/削除プログラムを使用して）新しいmsiをインストールすると、.exeを含むすべてのファイルがインストールされます。

msiexecログファイルはmywebspace.wisc.edu/mdorl/msilog/log3.logです。

.msiはmywebspace.wisc.edu/mdorl/msilog/sbl_Major_Upgrade.msiです

私には奇妙に見える唯一のものは、ログからの次の行です。1番目、2番目、および4番目はインストールされるファイルであり、3番目はインストールされない.exeファイルです。このエントリのNULLアクションに注意してください。

外部 CAB ファイルからいくつかのバージョン管理されていないファイルをインストールする WIX インストーラーがあります。

私の問題は、バージョン管理されていないファイルを正しくアップグレードするには、InstallInitialize の前に RemoveExistingProducts が必要だと言われたことです。ただし、外部のcabファイルでおかしくなり、ファイルがCABファイルにないというエラーが表示され続けます(存在する場合でも)。

RemoveExistingProducts が InstallExecute の後にある場合、初回は CAB ファイルで正しくインストールされますが、アップグレード中にファイルはアップグレードされません。

以下にいくつかのスニペットを示します。

...

...

ここで見つけたコードに基づいてインストーラーを作成しました。アプリの以前のバージョンが存在する場合、新しいバージョンをインストールする前に、インストーラーにそれを削除してもらいたいです。

クリーンインストールであれば、すべてうまくいきます。

アップグレードすると、奇妙なことが起こります。予想どおり、古いバージョンが削除され、レジストリが変更され、ショートカットがデスクトップに配置されます。奇妙なことに、インストーラーが完了すると、プライマリ ファイルはアプリケーション フォルダーに存在しません。

アップグレード後に起動すると、インストーラーの小さなメッセージ ボックスがポップアップ表示され、「Windows が -app name-.. を構成している間お待ちください」と表示されます。この簡単なメッセージの後、ファイルはアプリ フォルダーに存在する必要があり、アプリが起動します。

ただし、ローンチ前は、そこにはありません。アプリを起動する前に再起動を試みて、何らかのキャッシュに詰まっている場合にファイルが配置されるかどうかを確認しました.

誰でもこの動作を見たことがありますか? この質問に少し似ていますが、アップグレードのたびに発生します。

msiを作成するためにwixプロジェクトを使用しています。メジャーアップグレードをしようとしていました。

製品コードと製品バージョンを変更し、新しいMsiを作成しました

新しいmsiがマシンにインストールされます[レジストリキーが作成され、installdirに最新のファイルが含まれています]。

これで、レジストリキーのアンインストールに2つの製品コードが表示されます。古いmsiが正しくアンインストールされていないと思います。

製品コードを更新すると、自動的に処理されるはずですよね。古いものをアンインストールしなかった理由は何でしたか？

メジャーアップグレードを試みています。調査中に、2つのアプローチを見つけました。

1つはアップグレードIDを使用しており、もう1つのアプローチはMajorupgradeタグでした。

Majorupgradeは簡単にできるようです。ただし、installinitializeアクションの前のスケジュールには何も含まれていません。

どちらを使用すべきかわかりません。

どちらが最も好まれ[そして推奨]されますか？

新しいメジャー アップグレード機能を備えた Wix 3.5 を使用WixUI_Advancedしています。また、ユーザーがユーザーごと (デフォルト) またはマシンごとのインストール スコープを選択できるようにするためにも使用しています。

メジャー アップグレードは、同じユーザーごとのスコープで新しいバージョンをインストールする場合、ユーザーごとのインストール スコープで正常に機能します。ただし、古いバージョンが Per Machine スコープとしてインストールされた場合、Per Machine スコープで新しいバージョンをインストールしても、実際には古いバージョンが新しいバージョンにアップグレードされません。代わりに、[プログラムと機能] に 2 つのインストール済みインスタンスが見つかりました。

StackOverflow: Wix Major Upgrade and Install Context Issuesからこの質問と回答を見つけました。シプリアンからの唯一の答えは、FindRelatedProductsアクションを再度実行することでした。

再度実行する方法がわかりませんFindRelatedProducts。誰かがこれを試して、それが機能することを確認しましたか?

どうもありがとう。

いくつかのファイル（.NETプログラムバージョン6.0.0.0）をインストールする非常に単純なWiXプロジェクト（バージョン3.7）があります。WiXのMajorUpgrade機能を使用して新しいバージョン6.0.1.0をリリースする準備ができました。

Product要素でUpgradeCodeを同じに保ち、バージョンを6.0.0.0から6.0.1.0に変更します

6.0.0.0がインストールされているマシンで、新しいインストーラーを実行します。

古いバージョン6.0.0.0の削除は正常に実行されます（インストールされているすべてのファイルが削除されます）が、インストーラーが新しいバージョンをインストールし続けると、サードパーティのDLLとサードパーティのEXEの2つのファイルが失われます（まだインストールされていません）。変更されました）は再インストールされていません。

<ComponentGroup>内の他のすべてのファイル（一部は変更済み、一部は未変更（他のサードパーティDLLを含む））は、メジャーアップグレード中に正しくインストールされています。

メジャーアップグレード後に「修復」をクリックすると、2つの欠落しているファイルが再表示されます。また、バージョン6.0.1.0を初めてインストールする場合（アップグレードはありませんが、最初にクリーンなマシンにインストールします）、これら2つのファイルは直接正常にインストールされます。（いくつかのWindowsマシン（XP、7、および8）でテスト済み）

誰かが何が間違っているのか、そしてそれを修正する方法を提案しますか？

私はAjaxControlToolkitを使用していますが、バージョン番号付けスキームを変更することにしました。変更はここに文書化されています：http ：//stephenwalther.com/archive/2013/01/24/new-january-2013-release-of-the-ajax-control-toolkit.aspx

基本的に、新しいバージョンのファイルバージョンは低くなります（4.1.7.123は4.1.60501.0よりも新しいですが、7は60501よりも小さいです）。明らかに、これにより、MSIで問題が発生します。これは、バージョン番号が高いコンポーネントがすでに表示されているためです。マシン上で、したがってこれを出力します：

この新しいがバージョン番号の低いコンポーネントを強制的にインストールするにはどうすればよいですか？

PS個人的な暴言：「7.0123は60,919未満であることに気づきましたが、数が足りなくなった」と言ってこの数を正当化したAjaxControlToolkitの連中。4.2.7.123はうまくいったでしょう、みんな。3番目の数字が足りなくなったので、2番目の数字を増やす必要があります。

For our msi , we did not mention allusers property in existing releases. so by default it went as per user.

Our customers installed the application using an admin user id and that admin left the company. So his user id is no more in valid condition.

Now they are unable to migrate to newer version using another admin account (as it was installed as per user).

Though we can change our msi to support allusers ,it would not work in migration (major upgrade).

It seems like only when we give total new release where no existing release is supported we can fix the issue.

Is there any other workaround there to mention even if the previous msi was per user ,it should be major upgraded now?

We are using WIX 3.5 for our installation process.

私は持っているWiXセットアップを持っています

アップグレード中にエラーが発生した場合、セットアップはロールバックし、以前にインストールされたバージョンを復元します。ただし、カスタム アクションによって作成されたスケジュールされたタスクは失われ、復元されません。

タスクの作成/削除/ロールバックに使用しているカスタム アクションは次のとおりです。

としてキューに入れられます

アクションには、テスト目的で削除したCreateScheduledTask条件がありました。NOT Installed

アップグレードのセットアップがロールバックされたときにタスクを再作成するには、何をする必要があるか教えてもらえますか? PS: タスクが最初に作成されたドメイン、ユーザー名、またはパスワードにアクセスできません。