👩🏿 🕙 🌚 .NETプロジェクトの継続的統合：NAntおよび/またはMSBuild？ 📹 🛴 🗯️

Habrのすべての読者の皆さん、こんにちは！

少し前まで、私はサーバーアセンブリ用のいくつかのNAntプロジェクトと既にマスターされているMSBuildの継続的な統合を使用し始めました。いつものように、仕事の過程で、異なる符号（プラスとマイナスの両方）を持つボーナスが検出されます。 CIサーバーのコンテキストでさまざまなエンジン（MSBuild、NAnt）によるアセンブリの詳細に興味がある場合は、catに招待してください。

組立工程

最初に、アセンブリプロセス、つまりソースファイルが最終製品になるために通過するフェーズのリストについて簡単に検討します。

前のアセンブリの結果からアセンブリフォルダを削除する
ビルドプロセスの初期化（たとえば、コードファイルに正しいバージョンをインストールする）
コードファイルのコンパイル
試運転
バイナリファイルに基づく特別なファイルの作成（msiインストーラー、NuGetパッケージなど）
ビルド結果の公開（FTPへのアップロード、nuget push）

このアセンブリモデルは、重要でない詳細で議論を混乱させないように十分に単純化されています。そのため、コンパイルフェーズにはリポジトリからパッケージをダウンロードすることが含まれ、テストフェーズは単体テストと統合テストの実行に分割されます。私の意見では、組み立てツールを目的のプロセスに適合させる能力は、選択におけるかなり重要な要素です。

MSBuildでのビルドプロセスのサポート

MSBuildはIDE（Visual Studio、SharpDevelop）の通常のビルダーであるため、最初はMSBuildで作業しました。

プロジェクトをビルドするために、いくつかの追加のスクリプトが使用されました。なぜカップルではなく、正確にカップルですか？すべてが非常に簡単です。MSBuildは、スクリプトの実行中にターゲットファイルを読み込むことができません。最初にスクリプトで指定されたすべてのファイルをインポートしてから、アセンブリプロセスが開始されます。そのため、最初のスクリプトはNuGetリポジトリから追加のターゲットファイルをダウンロードすることのみを担当し、2番目のスクリプトはそこに落ちたすべての資産を使用してビルドスクリプトを実行しました。

個々のプロジェクトをビルドするために、生成されたIDE csprojファイルが使用され、変数を簡単に充実させました。 MSBuildでのプロジェクトの継承により、状況は厳しいことが判明しました。正しく実行するには、親スクリプトが子内のパラメーターセット全体を完全に渡す必要があり、親の本体のプロパティの単純な定義では不十分でした。もちろん、これは致命的ではありませんが、余分な作業を行います。

最初の3つのフェーズに特別な問題がない場合、残りのフェーズの実装にはある程度のスキルが必要です。なぜなら IDEはcsprojファイルを使用してプロジェクトを管理しますが、あまり変更することはできません。解決策は、メインスクリプトに残りのすべてのフェーズのアセンブリスクリプトを記述することでした。このソリューションの利点は、すべてが1か所で記述されることです。ただし、プロダクションプロジェクトと単体テストプロジェクトの数が10に増えると、そのようなビルドスクリプトを維持することが難しくなります。

IDEは、プラットフォーム/構成の組み合わせごとに個別の出力フォルダーを生成するため、ビルドプロセス中に、参照プロジェクトのdllがどのフォルダーにあるかを常に判断するのは簡単な作業ではありません。

プロジェクトでNuGetパッケージリポジトリを使用することに決めた場合、すぐに重複します。パッケージからdllへのリンクは、csprojファイルとpackages.configファイルの2つの場所にあります。 Nugetクライアントには、これら2つのファイルの同期を維持する際の既知の問題があります。特に、パッケージを更新しても、常に望ましい結果が得られるとは限りません。

NAntビルドプロセスのサポート

NAntの現在のバージョンは0.92（2012年夏リリース）であるため、私の研究ではこれに依存しました。

ここでは、おそらく特定された欠点から始めます。

基本的なIDE（Visual Studio、SharpDevelop）はNAntを好まず、そのプロジェクトの標準フォーマットはサポートしていません。ただし、完全を期すために、SharpDevelop NAntの古いバージョンの1つがサポートされていることに注意してください。現在、SharpDevelopの現在の開発部門でNAntサポートが最小限に抑えられているのは謎のままです。

NAntには独自のボーナスがなく、MSBuild（WPFなど）を使用せずに特定の種類のプロジェクトを収集できます。 MSBuildを使用した結果を最小限に抑える方法については、後ほど説明します。

楽しいボーナスには何がありますか？

マスクを使用してファイルを操作すると、一度書かれたスクリプトをサポートするための作業量を最小限に抑えることができます。

プロジェクト間のプロパティの継承により、異なるレベルのプロジェクト間ですべての値が明示的に転送されることを心配する必要がなくなります。たとえば、個々のプロジェクトのbin、objフォルダーを増やす代わりに、すべてのコンパイル結果のコレクションをソリューションレベルで1つのフォルダーに整理するのは簡単です。

NAntの必須性により、個々のプロジェクトターゲットを適切に修正することが容易になります。典型的なタスクの実装：ライブラリに加えて、BeforeBuildおよびAfterBuildイベントを使用して自家製の構成をいくつかコピーします（内部ではMSBuildタスクを使用しませんが、通常はcmdまたはPowershellスクリプトを使用します）。

フルタイムのJava Antビルダーの出力システムは、ビルドサーバーで長い間解析されてきたため、NAntに特別な問題はありません。 Jenkinsビルドサーバー（Hudson）用のNAnt用の個別のプラグインがあります。

NAntは、MSBuildとは異なり、スクリプト内で明示的に指定されたときに追加のタスクセットを動的にロードしたり、NAnt.exeの横に正しい場所にある場合は自動的にダウンロードしたりできます。したがって、xcopyメソッドを使用してコレクター自体を配布できます。これにより、複数のマシンで単一のコレクター構成を並行して使用することが非常に容易になります。通常のタスクセットに追加された便利なライブラリのうち、次のことに注意してください。

NAnt Contribは、 MSBuildおよびSubversionとの相互運用性を含む、NAntの多数のアドオンセットです。
Wixビルド MSIインストーラー
パッケージマネージャーでの作業に対するNugetのボーナス

上記のすべての結果によると、私にとって最適な組み合わせは次のとおりでした。IDEで作業しているときにMSBuildをビルドし、CIサーバーが機能しているときにNAntを起動しました。

WPFプロジェクトを構築する

投稿の最後で、タールバレルに蜂蜜を1スプーン入れたもの、つまりNAntを使用したWPFプロジェクトの組み立てについてお話ししたかったのです。ダブルコンパイル（xaml-> cs-> dll）を完全に克服する魔法はないとすぐに言います。ただし、NAntの注意深い監視の下で、MSBuildがtrapに行くように訓練することはまだ可能です。

NAntアセンブリのコンテキストでMSBuildを起動すると、2つの重要な問題があります。

MSBuildは、依存関係プロジェクトをビルドする必要があると誤って考えています
MSBuildは、依存関係プロジェクトをビルドした後にあるはずの依存関係を持つDLLを探しています

最初の問題は、アセンブリキー/ p：BuildProjectReferences = falseを設定することで解決されます。

2番目は額では解決されないため、反対側から少し近づきます。 NAntを介してアセンブリを実行するためにcsprojファイルの静的バージョンを含めることは、利益がありません。両方のバージョンをサポートする必要があります。そのため、そのようなバージョンをその場で生成する必要があります。小さなXSL変換を取得して記述し、スタイルNAntタスクを実行して、調整されたプロジェクトをMSBuildにフィードします。スタイルタスクが開始されると、既にコンパイルされたDLLファイルへのパスを含む1つのパラメーターが渡されます。

XSL変換

<?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msbuild="http://schemas.microsoft.com/developer/msbuild/2003"> <xsl:output indent="yes" method="xml"/> <xsl:param name="dllPath"/> <xsl:template match="/"> <xsl:apply-templates /> </xsl:template> <xsl:template match="//msbuild:ItemGroup/msbuild:ProjectReference"> <xsl:element name="Reference" namespace="http://schemas.microsoft.com/developer/msbuild/2003"> <xsl:attribute name="Include"> <xsl:value-of select="msbuild:Name/text()"/> </xsl:attribute> <xsl:element name="HintPath" namespace="http://schemas.microsoft.com/developer/msbuild/2003"> <xsl:value-of select="$dllPath"/> <xsl:value-of select="msbuild:Name/text()"/>.dll</xsl:element> </xsl:element> </xsl:template> <xsl:template match="*|@*"> <xsl:copy> <xsl:apply-templates select="node()|@*"/> </xsl:copy> </xsl:template> </xsl:stylesheet>

したがって、MSBuildはプロジェクトを単独でビルドし、他のプロジェクトについて何も疑わないようにすることができます。人々が言うように、「あなたはあまり知らない、よく眠る」、これはMSBuildを管理するために非常に重要です。

結論の場所（代わりに）

どの方法と何を使用するかは、常に自分自身またはチーム内で決定し、すべての長所と短所を慎重に検討する必要があります。

MSBuildから始めるのが最善です。通常、開発者のマシンに既にインストールされており、メイン設定で不要なジェスチャーを必要としません。

NAntでの作業も複雑ではありませんが、開発者からの脳の特定の「ターン」が必要です。

.NETプロジェクトの継続的統合：NAntおよび/またはMSBuild？

組立工程

MSBuildでのビルドプロセスのサポート

NAntビルドプロセスのサポート

WPFプロジェクトを構築する

結論の場所（代わりに）

More articles: