C＃およびWix＃を使用してmsiパッケージを作成する

翻訳者から：英語を話すイットブロガーは通常、私がとても興奮している言葉でそのような記事を始めます。 私はWix＃を偶然に発見し、この発見をhabrasocietyと共有することを急いでいます。 ベアWiXを扱ってきた人なら誰でも、このプロセスがいかに不快なものかを知っています。 そして、C＃で数行書くだけでmsiディストリビューションを作成できます！ それは素晴らしいと思います！ そして比較的最近（2014年12月4日）Wix＃の著者であるOleg ShiloがInfoQにインタビューを行いました。 このインタビューの翻訳をご紹介します。 そして、いくつかの言葉のトレーシングペーパーを厳密に判断しないようにお願いします。同じ「展開」は、「展開」よりも私に近いです。





InfoQ：Wixのことを聞いたことのない読者の方へ＃：それは何ですか？



Oleg ：Wix＃（WixSharp）は、Windows Installer（MSI）に基づいた展開オーサリングフレームワークです。 Wix＃を使用すると、C＃で記述された仕様に従って本格的なMSIディストリビューションを構築できます。 典型的なWixソースファイルは、C＃クラスを使用してWiXエンティティを定義する通常のC＃コードで構成されています。



Wixは、MSIを作成する際の多くの問題を解決します。 エレガントで独創的な方法で、典型的なMSI / WiXの制限を回避します。 Wix＃は、Script＃、CoffeeScript、GWTなどの他のトランスコンパイラの後、構文的により便利な言語（この場合はC＃）のソースコードを使用して、あまり便利でない言語（WiX）のソースコードを取得します。 この場合の「構文的に便利」とは、冗長性が少なく読みやすいコードを意味します。 コンパイル段階でより多くのチェックがあり、より高度なツールが利用できるコード。



Wix＃では、まったく異なる言語（C ++など）でMSIサブモジュール（カスタムアクション）を作成する必要もなくなり、コンポーネントと動作の両方を1つの言語（C＃）で記述することができます。 また、より均一でシンプルで一貫性のあるソースコード構造を実現できます。



しかし、さらに重要なことは、Wix＃は、MSI / WiXのすべての複雑さと直感性を隠し、より自然な方法で展開アルゴリズムを表現できる抽象化レイヤーを提供します。 以下のコードは、Myアプリアプリケーションをインストールするための.msiファイルを作成するスクリプトを示す典型的なWix＃の例です。

using System; using WixSharp; class Script { static public void Main() { var project = new Project("My App", new Dir(@"%ProgramFiles%\My Company\My App", new File(@"\\BuildServer\LatestRelease\Bin\MyApp.exe"), new File(@"\\BuildServer\LatestRelease\Bin\MyApp.exe.config"), new File(@"\\BuildServer\LatestRelease\Docs\readme.txt"))); project.GUID = new Guid("6f330b47-2577-43ad-9095-1861ba25889b"); Compiler.BuildMsi(project); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、Wixはより複雑なスクリプト（カスタムアクション、またはWPFまたはWinForms上の独自のUI）を実行できますが、上記のコードはその本質を示す優れた例です。



Wix＃はCS-Scriptユーティリティスイートの一部です。これは、C＃スクリプトを実行するためのオープンソーススクリプトエンジンです。 InfoQの読者は、Notepad ++のCS-Scriptプラグインについての前回のインタビューで既にお話ししたように、すでにこれに慣れているかもしれません。



InfoQ：ドメイン固有言語（DSL）形式ではなく、Wix＃のAPI形式を選択した理由は何ですか？



Oleg ：Wix＃の目標は、XML構文を他のものに置き換えることではありません。 これは、MSI + WiXバンドルの多くの実際的な制限の1つだけを解決します。 Wix＃を使用して、展開開発を通常のプログラミングに減らしたいと思いました。 ソフトウェアを作成する最も一般的な開発者が、迅速かつ快適に展開ソリューションを作成できるようにしたかったのです。 DSLは、開発者が次の構文を学ぶ必要があり、Intellisenseなどのヘルパーユーティリティが不足していることを意味します。 また、DSLはカスタムアクションを作成するために別の言語を必要とする可能性が高いでしょう。 C＃とお気に入りの開発環境（IDE）がデプロイメントを開発するための「ワンストップショップ」になることを望んでいました。 そして、あなたのチームは別のWiXスペシャリストを必要としません。通常のプログラミングスキルは、ほとんどすべての展開シナリオを実装するのに十分になります。



ただし、DSLアプローチを放棄する理由はそれほど明白ではありません。 典型的なDSLタスクは、ある構文を別の構文に変換するか、あるソフトウェアモデルを別のソフトウェアモデルに変換することです。 WiXのコンテキストでの翻訳タスクには、実用的な意味がほとんどありません。 実装は簡単ですが、これはWiX構文をより単純な構文に変換するだけですが、MSIのすべての制限を保持します。 逆に、よりクリーンで直感的な新しいプログラミングモデルへの変換は、まさにWiXが必要とするものです。 このような変換は通常、高レベルの汎用プログラミング言語（Wix＃のコンテキストではC＃）を使用して実現されます。 その後、新しいプログラミングモデルは通常、新しいDSL構文に関連付けられます。 ただし、Wix＃の場合、最後のステップ（構文バインディング）は役に立ちません。 Windows開発者の大多数は、非常に快適であるか、少なくとも.Net言語に精通しています。 したがって、新しいDSL構文は余分なオーバーヘッドをもたらすだけです。 そこで私はC＃に焦点を合わせることにしました。



上記にかかわらず、Wix＃ソフトウェアモデルの上にあるDSLは理にかなっており、実装が簡単です。 しかし、これは全く異なる話です...



InfoQ：複雑なフォーマットに加えて、WiX採用の最大の障害は何だと思いますか？



オレグ ：非常に良い質問です。 はい、WiXは本当に非常に複雑ですが、本当の障害は複雑ではなく、MSIとの密接なコミュニケーションです。 WiXは、MSIプログラミングモデルへのアクセスを劇的に簡素化します。 ただし、アクセスの複雑さではなく、このモデル自体が問題の原因です。 そのため、WiXユーザーは、MSIの不便さにまだ対処しており、XMLのみを使用しています。



ここで、WiXを守るためにいくつかの言葉を中断して言いたいと思います。 不完全なMSIソフトウェアモデルはWiXのせいではありません。 実際、WiXがMSIに対して行ったことを考えると、MSIの制限が修正されることを期待することはほとんど不可能です。 WiXを真に評価するには、マイクロソフトの展開テクノロジの開発を振り返る必要があります。



MSIが導入されたとき、MSIは「すべての質問に対する答え」になろうとしました。 また、多くのマイクロソフトテクノロジーと同様に、最初から非常に複雑でした。 それ以来、彼は変わっていません。 マイクロソフトはMSIに多くの複雑な機能を実装しましたが、今日では実用的な価値はほとんどありません（たとえば、コンポーネント、MSM、 広告のインストールなど）。



そして、Microsoftが問題を認識し、最後の試みであるClickOnceでこれらすべての機能を削除したという事実には驚くべきことは何もありません。 ClickOnceは非常にシンプルな展開フレームワークです。 実際、MicrosoftはMSIの概念を完全に放棄し、代替としてClickOnceをゼロから実装しました。 軽量で、スマートで、ミニマルです（良い意味で）。 確かに、それはより閉じられており、拡張もカスタマイズもできません。



内部の欠陥のため、MSIは非常に開発しやすいです。 .msiファイルはデータベースファイルです。 展開ロジックは、テーブルのデータを通じて定義されます。 Microsoftは、Orca MSIテーブルエディタを使用して、フィールドごとにこのデータを手動で入力することにより、MSIを作成することを提案しました。 これにより、InstallShieldは（MSIサポートの価格を上げることで）莫大な収入を得ましたが、開発者には何も残しませんでした。 そして、WiXが起こりました。 そして彼は「MSIのカオス」を止めました。 WiXは、秩序をもたらし、MSIの作成をソフトウェア開発のタスクにすること（データでドライブするのではなく）-「ソースからバイナリファイルを構築する」ことで称賛に値します。 したがって、WiXを使用すると、これらのMSIテーブルに手動ではなくXMLファイルを取り込むことができました。 ただし、これによりMSI開発の本質は変わりませんでした。 WiXを使用する場合、開発者は「MSIテーブル」の観点から考えなければなりませんでした（まだそうすべきです）。



ほんの数週間前、WiX＃ユーザーの1人が、レジストリを変更するだけでよい単純なMSIシナリオのソリューションを共有しました。 問題は、MSI / WiXではインストールフォルダーを設定する必要があるということです。たとえ単一のファイルを入れずに、レジストリにキーを入力するだけでもです。 解決策は、ダミーフォルダーを設定してから、フォルダー操作を削除して、インストール中にフォルダーを物理的に作成しないようにすることです。 これはすべて、展開要件のためではなく、MSIの不可解な制限のために必要です。フォルダテーブルには少なくとも1つのエントリが必要です。



一方、WiX＃では、スタブフォルダーのエントリを自動的に作成でき、MSI / WiXの複雑さを完全に隠します。

 var project = new Project("MyProduct", new RegValue(RegistryHive.LocalMachine, "Software\\My Company\\My Product", "Message", "Hello"), new RegValue(RegistryHive.LocalMachine, "Software\\My Company\\My Product", "Count", 777)); project.GUID = new Guid("6f330b47-2577-43ad-9095-1861ba25889b"); Compiler.BuildMsi(project);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記のコードに相当するWiXは、約40行の非常に高密度のXMLコードに加えて、WiXコンパイラーとリンカーを起動するバッチファイルになります。



ダミーフォルダーは、孤立したケースではありません。 Wix＃で解決されるMSI / WiXには、他にも多くの構文上の「障害」があります。



多くのWiXの達人は、MSIアーキテクチャへのそのような近接性がWiXの力であると考えています。これは、MSI機能への絶対アクセスを提供するからです。 私は同意しません。 開発者のニーズを無視しているため、これはテクノロジー全体の採用を妨げるものと確信しています。 したがって、WiXは開発者指向ではなく、完全にMSI指向です。 しかし、これをWiXのせいにするべきではありません。 WiXがこれについて考える必要があるかどうかさえ、私にはわかりません。 私の意見では、要件/仕様（たとえば、Wix＃ファイル）を取得し、MSI-DB仕様（WiXファイル）に変換する別のレイヤーがここに必要です。



WiXは、MSI環境でILが.NETで行うのと同じ役割を果たします。 ILはCLR機能への絶対アクセスを提供しますが、開発には誰も使用しません。 このために、すべての高レベルの.NET言語があります。 したがって、質問を「ILを受け入れる最大の障害は何か」と言い換えると、答えは簡単になります。 受け入れる必要はありません。 開発には、ILよりもはるかに優れたオプションがあります（ILはすべての.NETテクノロジーの重要な部分であるという事実にもかかわらず）。 Wix＃は、これらの「最良のオプション」の少なくとも1つをMSIドメインに導入しようとする試みです。 したがって、Wix＃またはそのようなソリューションは、WiXの次の開発ステップにすぎません。



InfoQ：基本的なインストールパッケージの作成を容易にすることに加えて、WiX＃の最も興味深い機能は何ですか？



Oleg ：言及する価値のある非常に重要なことがいくつかあります。



1.まず第一に、これは管理された（カスタム）カスタムアクションの不滅のシンプルさであり、高レベルプログラミング言語（C＃）の力に由来します。

 using System; using WixSharp; class Script { static void Main() { var project = new Project("CustomActionTest", new ManagedAction("MyAction", Return.check, When.After, Step.InstallInitialize, Condition.NOT_Installed)); Compiler.BuildMsi(project); } } public class CustomActions { [CustomAction] public static ActionResult MyAction(Session session) { MessageBox.Show("Hello World!", "Embedded Managed CA"); session.Log("Begin MyAction Hello World"); return ActionResult.Success; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2. UI。 Wixは、通常のWinFormsダイアログをUIシーケンスに挿入できるだけではありません。 また、独自のGUIを完全に作成し、それをMSIエンジンランタイムにスリップする機会を提供します。 MSI APIによって提供されるこの素晴らしい機能は、Microsoftが多くの製品（特にインストーラーOffice、Visual Studio）で使用しているにもかかわらず、ほぼすべてのMSI作成フレームワークによって完全に見落とされています。



私は自分のUIを非常に物議を醸す展開手法と考えており、（設計上の理由から）開発者にこの方法を勧めません。 しかし、ユーザーの要求を無視することはできませんでしたが、それでも実装しました。 以下は、独自のUIの（Wix＃ディストリビューションからの）WPFの例のスクリーンショットです。





3.最後に言及したい機能は、Wix＃の拡張性です。 デプロイメント記述は、C＃クラスの単なる宣言です。 ヘルパークラスを使用して簡単に改善し、通常のインストール条件を簡素化または変更できます。 たとえば、すべてのファイルを一覧表示する代わりに、フォルダー構造を実行して動的に実行するクラス（AllFilesなど）を作成できます。 したがって、新しいdllを配布パッケージに含める必要がある場合、インストールスクリプトを変更する必要はありません。

 var project = new Project("My App", new Dir(@"%ProgramFiles%\My Company\My App", new AllFiles(@"\\BuildServer\LatestRelease\*.*")));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Wix＃の機能が十分でない場合、Wix＃コンパイライベントハンドラを使用して、生成されたXML（WiX）コンテンツを直接操作できます（XMLがMSIコンパイラに渡される直前）。 XMLツリーから要素または属性を追加または削除できます。 例では、組み込みのWiX＃機能を使用してASP.NETサイトをインストールする方法と、コンパイルの直前に必要なXMLを挿入して同じことを行う方法を示します。



ちなみに、Wixディストリビューションの例の数は非常に多く、すべてのWixコードの〜95％です。



Wixのライフサイクルのこの段階で、その主な機能はほぼ完成していると思います。 したがって、新しい機会は、垂直よりも水平方向の開発を提供します。 主に、開発ツールとの統合と、開発者向けのフレームワークの使いやすさに焦点を当てます。 私の計画は、NuGetでWix＃を公開し（ 完了 、 約Transl。 ）、MSIユーザーインターフェイスの完全な同等物を提供しますが、WinFormダイアログの外部セットとして、Notepad ++用のプラグインを開発し、場合によってはプロジェクトテンプレートを使用してMSBuildタスクを開発しますVisual StudioはWix＃を通常のC＃プロジェクトとして扱います）。 そして、もちろん、ユーザーのリクエストを処理します。



Wix＃はMITライセンスの下でCodePlexで利用可能です。