ビルド プロセスが設計および実装されたとき (そして、かなりの数年間成功を収めています)、私は会社の一員ではなかったので、「ハッキング」と見なされる可能性のあることが行われていることがわかりました。 MSIの「純粋主義者」へ。ただし、 Visual Studio 2012で実行可能なインストーラーを取得するために、 Visual Studio 2010.vdproj
のファイルで行われていたことを模倣するために最善を尽くしてきました。私が遭遇した多くの問題の中で、これが解決できない最後の問題のようです。
Visual Studio 2010 を使用したビルド プロセスの一環として、コードをビルドし、1 つの VM にフレームワーク MSI を作成しました。次に、そのフレームワーク MSI を別の VM にインストールしました。フレームワークをインストールした後、製品コードをビルドし、それから製品 MSI を作成しました。これにより、フレームワークへの製品依存が作成されました。これが意味することは、クライアント マシンにインストールする場合、ブートストラッパーは最初にフレームワークをインストールし、次に製品をインストールする必要があるということです。msiexec /x {Product.msi/@ProductCode}
アンインストールの際、当社のドキュメントには、ARP またはコマンド ラインで処理するように記載されていますmsiexec /x {Framework.msi/@ProductCode}
。
当時、経営陣は、ProductCode
他の製品チームが当社の製品がマシンにインストールされているかどうかを判断する最も簡単な方法であると判断しました. ProductCode
これにより、フレームワークと製品の両方を静的に保持する必要があるという決定に至りました。
アップグレードを処理するために、引数ProductTool.exe
を取る実行可能ファイルにラップされた msiexec にすぎないを作成する必要がありました。/ProductCode={@ProductCode}
私たちのブートストラップの一部として、彼らは以下を呼び出しました:
- 前提条件のインストール ( Windows Installer 4.5、.NET 3.5 SP1、SQL Server 2008 R2 Express、Sync 2.1)
ProductTool.exe
(Product.msi
-- Product.msi をアンインストールします)ProductTool.exe
(Framework.msi
-- Framework.msi をアンインストールします)- インストール
Framework.msi
- インストール
Product.msi
しかし、Burnブートストラッパーが許可しないことをつい最近まで知りませんでしREINSTALLMODE=amus
た。インストール ログでは、それが に変更されたことが示されていREINSTALLMODE=vomus
ます。どうやら、前述のプロセスをアップグレードで機能させるために、設定する必要がありましたREINSTALLMODE=amus
。
更新:最終的にインストーラーの元の開発者と話をするようになりREINSTALLMODE=amus
、バージョン管理されたすべてのファイル (アセンブリ、DLL ファイルなど) とバージョン管理されていないファイル (.config、SQL スクリプトなど) を元に戻すために意図的に使用されていることがわかりました。 .) リスクの最小化と堅牢性/「自己修復」戦略として。
以上のことをすべて述べた上で、標準の書き込みブートストラップ アプリケーション (BA) をREINSTALLMODE=amus
使用して、アップグレードを機能させるように設定することは可能ですか? MSI ファイルにはプロパティのセットがありますが、Burn がそれをオーバーライドしているようです。