以前にInfoQで取り上げたように(参考記事)、WiX 3.0はVisualでシップされることになっている。WiXは、現在利用可能なVisual Studio Setup Projectよりもはるかに柔軟であり、管理コードをサポートし、Windows Installerと対話する。作成者は、C#、VB.NETまたは他の.NETプログラミング言語を使用することができる。これにより、インストール作 成者にとって主な痛点である、デバッギングが可能になる。
WiXでDeployment Tools Foundation(DTF)を使用し、管理Custom Actions(CA’s)をサポートすることで、デベロッパはもはやC++やスクリプト作成(VB ScriptまたはJavaScript)を使用して、CA’sを作成する必要がない。DTFは、 msi.dllに加えて管理.NET wrapperがあり、ユーザは完全なMSI APIにアクセスすることができる。C#のCAメソッドは、以下のような感じになる。
[CustomAction]
public static ActionResult CustomActionName(Session session)
{
...
}
CustomAction属性は、CAとしてメソッドにタグを付ける際に使用される。Sessionオブジェクトは、Windows Installer API に対するアクセスをデベロッパに提供し、MSIデータベース、アクセスプロパティなどを参照できるようにする。これは、スクリプト作成またはC++で実行 される既存のCA’sの場合に非常に良く似ている。
WiXで上記のCAを使用するためには、以下のようにWiXプロジェクトで登録される必要がある。
<CustomAction Id="someID" BinaryKey="someKey" DllEntry="customActionName" Execute="immediate" Return="check" /> <Binary Id="someKey" SourceFile="someCustomAction.CA.dll" />
UISequenceでCAを実行すると、以下のようになる。
<InstallUISequence> <Custom Action="someID" After="CostFinalize" Overridable="yes">NOT Installed</Custom> </InstallUISequence>
WiX 3.0は、現時ｔはCA'sであるが、すべてのWiXユーザに利用可能な一連のデフォルトアクションを提供する。 デフォルトのアクションが利用可能な領域は、以下のとおりである。
- IIS
- Com+
- MSMQ
- SQL
完全なリストは、WiX 3.0ドキュメンテーション(リンク)を参照のこと。
例として、IISで新たなWebサイトの作成に必要なWiXソースコードは、以下のとおりである。
<iis:WebSite Id='DefaultWebSite' Description='Default Web Site'> <iis:WebAddress Id='AllUnassigned' Port='80' /> </iis:WebSite>
Windows Installerチームが管理Custom Actionをサポートしない理由を、多数の人が尋ねている。Rob Mensching氏(リンク)(WixのDevリード)が以下のように説明している。
…一年前、Carolyn氏(MSIのDevマネージャ)および数名のWindowsアーキテクトとおこなった、管理コードCustom Actionに関する討論の成果(リンク)を、ブログに投稿しました。そのブログ記事を要約すると、2つの問題がありました。まず最初は、技術的な問題であり、管理 コードCustom Actionが別々のプロセスで実行される必要があるということです。2点目は、WindowsプラットフォームにはCustom Action数を削減するための、戦略的な目標があります。
そのブログ記事を掲載したとき、DTFにその両方の問題を抱えていました。ブログの掲載から1ケ月位たって、Jason氏はプロセス間通信メカニズムを実装し、管理コードCustom Actionを別のプロセスに移行(それでもWindows Installerと通信できる)することで、その技術的な問題に取り組みました。
InstallShieldは、2009バージョンでは管理Custom Actionのサポートをする(リンク)が、Rob氏による上記の2点が解決されていないソリューションがあり、デバッグは不可能である。Christopher Painter氏は、DTFがより優れていると感じている理由(リンク)を説明している。
- DTFはCLRの確定バージョンでのmsiプロセスのtatooingの問題を解決する。
- 依存性に関して、MakeSfxCaはより柔軟で、直感的である。
- MSIの相互運用性オブジェクトモデルは、C#コードの観点から見ると、より優れている。
- ホスティングプロセスでは、デバッグが容易である。
- オープンソースであるので、問題が簡単に見つけられ、それに対する対策がすぐにとられる。
- ベンダーロックインがない。 InstallShieldとの統合を含む、さまざまな方法でカスタムアクションを構築し、使用することができる。
WiX 3.0のリリースは近い。現在、修正しなければならないバグ(リンク)があり、Visual Studioチームがそれをおこなうことになっている(リンク)ので、Votive(Visual Studioのアドオン)を統合することができる。最新バージョン3.0.5006.0は、毎週のリリース(リンク)からダウンロード可能である。