9

私の WiX インストーラー (Wix 3.10、MSI 4.5) はMajorUpgrade更新に使用します。インストールするファイルはheat.exeビルド前に収集されます。現在の (古い) msi ファイルには、ファイル バージョン、製品バージョン、最終書き込み時刻 を持つファイルnlog.dll(NuGet パッケージに付属) が含まれています。v4.1.04.1.0.04.1.02015-09-01

nlog チームはいくつかの重大な命名の問題に遭遇したため、更新された NuGet パッケージ を公開しました。これには、製品バージョンが に増加した一方で、ファイル バージョンが に減少しv4.1.1た更新プログラムが含まれています。最終書き込み時間はです。nlog.dll 4.0.0.04.1.12015-09-14

ロビーがここで行ったように、関連する問題が発生しています: wix メジャー アップグレードでは、すべてのファイルがインストールされません: 新しい msi パッケージをインストールしてメジャー アップグレードを実行すると、現在nlog.dll(ファイル バージョンによっては新しいものですが、古いものです)ファイルの日付と製品バージョンによると) は削除されていますが、新しいnlog.dllものはインストールされていません。

ただし、Schedule="afterInstallExecute"orSchedule="afterInstallFinalize"を提案どおりに使用しても、うまくいきません。ロビーの場合のように、新しいファイルを削除して古いファイルをインストールしない代わりに、現在のファイルを上書きせず、その場所にそのまま残します。

簡単に言えば、ファイル/製品/アセンブリのバージョン管理に関係なく、インストーラーに付属のすべてのファイルを単純にインストールしてもらいたいのです。新しいファイルを古いファイルに置き換えることが望ましい場合があります。ファイルのバージョン/日付を無視するようにインストーラー エンジンに指示することはできませんか? そうでない場合、どのような選択肢がありますか?

4

2 に答える 2

11

REINSTALLMODE プロパティを OMUS ではなく AMUS に設定できます。これは、すべてのコンポーネントにグローバルに影響します。

もう 1 つのトリックは、「バージョンの嘘」を使用することです。これは、より高いバージョンのファイル要素を作成する場所です。heat を使用すると、コンパイルする前に XML を変換する必要があるため、これが難しくなります。

もちろん、本当の解決策は nlog チームに頭をぶつけることです。しかし、私が何年にもわたって彼らから見てきたことに基づいて、それは決して起こりません. おそらく、リソース エディタを使用して DLL をハックし、バージョンを「修正」するだけです。それは、厳密な名前を付ける必要がないことを前提としています。これは汚い感じで、CMの悪夢の可能性があります。

または単に nlog をダンプします。:)

于 2015-09-16T11:21:54.177 に答える
0

If this is a major upgrade and you want everything to be uninstalled before the new product is installed, then you schedule RemoveExistingProducts after InstallInitialize or InstallValidate. That does the uninstall first.

I can't tell if you're getting the "disallowing install..." issue or not, but if you are, and there are other clients of the Dll (it's shared with other installed products) then I'd see if that Dll has support for private copies so you can have you own private copy for your product. If it is shared with other products I wouldn't use version lying - I'd open the Dll with Visual Studio "open as file" and change the version! Make that your latest shared version, so every package that installs it can just use it.

If it's not shared with other products and you're just running into that MSI quirk, then make your own upgrade element and schedule RemoveExistingProducts before CostInitialize, which is what is deciding not to install. That works, but it's before MigrateFeatureStates so you will lose feature migration in your major upgrade.

于 2015-09-16T17:54:41.663 に答える