3

mono に基づいてビルド システムの簡単なソリューションを作成する際に問題があります。

現在の状況では、参照するライブラリを git リポジトリ内に保持していますが、これは多くの明白な理由から良くありません。

私が達成したいのは、NuGet が提供するもののようなものです。Web から自動的に dll をダウンロードし、それらをいくつかのディレクトリに置き、忘れてしまいます。

ビルド時にこれを行いたいので、ライブラリのダウンロードなどの追加のアクションは必要ありません。最良のオプションは msbuild (モノの xbuild) タスクですが、システムに依存しないようにしたいので、人気のあるもの、 NuGet.exe を実行することは論外です (並列モノ インストールなどを検討してください)。

Pepita プロジェクトを試してみましたが、違います。いいえ、実際には、設計ミスが多すぎて、使用や修復が容易ではありません。適切な構成を行うには、プロジェクト全体を大幅に書き直す必要があります。

私が気に入っているのは、NuGet.Core ライブラリを採用し、タスクとして利用できるライブラリです。そのようなライブラリが存在しない場合は、nuget パッケージをダウンロードして .csproj で指定されたディレクトリに解凍する任意のソリューションを使用できます。

さらに良いことに、そのようなライブラリが packages.config (または同様の) ファイルで明示的に指定せずに依存関係を解決できるとよいでしょう。たとえば、Castle.Windsor を含めたい場合、構成に Castle.Core を含めたくありません。ファイル。

OpenWrap プロジェクト (NuGet ギャラリーを使用) については知っていますが、有望に見えますが、ライブラリの一定のセットをリポジトリに一度入れ、csproj ファイルといくつかの構成を変更して実行するソリューションが見つかりません。

4

1 に答える 1

2

コアの OpenWrap には、必要なことを行うためのすべてが組み込まれていると言えます。openwrap-shell でできることはすべて、msbuild から呼び出すこともできます。したがって、「update-wrap」を実行するためにopenwrapを呼び出す前にビルドフックを追加するだけでよいように思えます。数か月前、私は実際に似たようなことをすることを検討しました。AFAIR私は実際にopenwrapタスクを呼び出すためにmsbuildスクリプトを書きましたが、実際には通常のビルドプロセスにそれらをフックしませんでした。

「ライブラリの一定のセットをレポに一度置く」とはどういう意味か正確にはわかりませんか? OpenWrap の場合は、プロジェクトの「openwrap 記述子」を維持するだけです。そのファイルには、プロジェクトのすべての直接的な依存関係が含まれています (バージョン番号の制限の有無にかかわらず)。(間接的な依存関係は自動的に取り込まれます) 開始するバイナリ dll がたくさんある場合、どのように開始するのか疑問に思っていますか? 私が何をしたかをあなたに言うことができます。基本的に、NuGet パッケージは使用せず、すべて OpenWrap パッケージを作成しました。また、すべてのバイナリ依存関係 (一部はオープンソース) 用の OpenWrap パッケージも作成しました。これは非常に単純です。OpenWrap 記述子に正しい依存関係を入力し、パッケージに特定の dll のみを含める必要があることを指定します。

例を見たい場合は、これを確認できます: http://code.google.com/p/ppwcode/source/browse/dotnet/External/Apache.Log4Net/trunk/Apache.Log4Net.wrapdesc

バイナリの依存関係をパッケージ化するために必要な作業はこれだけです。これは私が作成したパッケージで、現在私が勤務する会社で使用しています。Log4Net はおそらく NuGet パッケージとして入手可能であり、おそらくそれを使用できるでしょう。これらのバイナリ パッケージを自分で作成する利点は、パッケージ、パッケージのバージョン番号、大きなプロジェクトをいくつかの小さなパッケージに分割する方法などを完全に制御できることです。

OpenWrap リポジトリとして、ローカル ファイル システム上のフォルダー、またはネットワーク共有上のフォルダーを使用できます。私たちが使用しているのは、実際にはドライブにローカルにマウントする webdav リポジトリです (Windows 7 を使用)。これは問題なく機能し、リポジトリへの読み取りおよび書き込みアクセス権を持つユーザーを指定することもできます。

あなたはモノについて言及しています....まあ、それは問題かもしれません.OpenWrapの現在リリースされているバージョン（2.0.2）は、モノのAFAIKでは実行されません。しかし、良いニュースは、Sebastien Lambla が、間もなくリリースされる新しいバージョン 2.0.3 の mono+xbuild で OpenWrap を実行できるように懸命に取り組んでいることです。まだアルファ/ベータ ビルドは利用できませんが、git からビルドできます。(その場合、openwrap-shell と openwrap の両方をビルドする必要があります)。OpenWrap を作成した Sebastien Lambla は、通常、StackOverflow に関する質問に目を光らせており、mono ステータスについてより完全な回答を提供できる可能性があります。

ところで、私が働いている場所では、すでに 1 年以上 OpenWrap を使用しています。当時、NuGet と OpenWrap の両方を比較しましたが、その時点では OpenWrap が NuGet をはるかに上回っていました。基本的に、NuGet は依存関係を管理するためのツールではなく、Visual Studio でリモート サーバーからバイナリの依存関係を取得するためのツールでした (つまり、dll をリモート サーバーからローカル フォルダーにコピーし、ローカル dll への参照を追加します)。プロジェクト ファイル)。その間、NuGet は OpenWrap に追いつき、OpenWrap に既に存在していた機能を追加しました。私の意見では、NuGet が OpenWrap よりも優れている点は 2 つだけで、それは Visual Studio への統合 (リモートで利用可能なパッケージの概要とパッケージのクリック-クリック-クリック追加) と、Microsoft の人々 (AFAIK) によって維持されているという事実です。 . どちらも単なる政治的なものです。きれいなインターフェイスとマイクロソフトのサポートにより、人々を説得しやすくなります。しかし、個人的には、OpenWrap は技術的に優れていると考えており、それに値する注目を集めていないのは本当に残念だと思います。

于 2012-05-26T07:54:08.300 に答える