パッケージマネージャーは、ほぼすべての形で存在します
。Ruby用の
Gemsと
Rip 、Java用の
Maven 、およびさまざまなLinuxおよびUnixディストリビューション用の海です。 そして、必要なライブラリの特定のバージョンを探して、古い形式の.NET開発者だけがサイトを巡回します。
そのような開発者の一人であり、必要なコンポーネントの絶え間ない検索にうんざりしているので、私はそれが終了する時であると決めました。 この決定の結果は、.NETプラットフォームの同じコンポーネントマネージャーでした
コンポーネント
満たす：
octalforty Componento （最初のアルファ版は、32ビットOSの場合は
ここで 、64ビット版の場合は
こちらで入手でき
ます ）。 私の知る限り、これは.NETのパッケージマネージャーを作成する最初の試みです。
作業のメカニズムは、原則として、他の環境の対応するメカニズムとそれほど変わりません。クライアントがアクセスし、どこからどこからダウンロードするかについての情報を取得する中央リポジトリがあります。 大きな欠点は、パッケージ形式（実際-zipアーカイブ）が標準化されていないことです。したがって、同じRubyに比べて、この点でカオスが支配します。 しかし、これはすべて有益です（もちろん、成功したコースの対象となります）。
「行こう！」
Componentoが解凍されたフォルダーは、
PATH追加するのが最適です。次に簡単になります。
あなたがプロジェクト開発のまさに初期段階にあり、必要なライブラリを収集し始めていると想像してください。 プロジェクトのフォルダー構造が次のようになっていると仮定します。
src製品自体のソースコード、
libサードパーティライブラリ、ただし
doc 、明らかにドキュメント。
真の.NET開発者は、単体テストとORMツールなしでは一歩を踏み出すことさえできません。 したがって、最初のステップでは、NUnit、NHibernate、およびFluent NHibernateが必要です。 続行：
C：\> cd d：\ projects \ acme \ lib
E：\ Projects \ Acme \ lib>コンポーネントリスト
Componentoは、このようなコマンドに対して、「パッケージがインストールされていません」という事実で合理的に応答します。 サーバー上にあるコンポーネントを見てみましょう。
E：\ Projects \ Acme \ lib>コンポーネントリスト/リモート
octalforty Componento 1.0 Alpha 1
Copyright（c）2009 octalforty studios
4.3 Kbのダウンロード
autofac（1.4.4.561）
bltoolkit（3.0）
...
fluent-nhibernate（1.0）
...
nhibernate（1.2.1）
nhibernate（2.1.0）
...
nunit（2.5.0.9122）
nunit（2.5.1.9189）
nunit（2.5.2.9222）
...
urlrewriting.net（2.0）
zedgraph（5.1.5）
必要なものだけです。
componento install nunit最新のNUnitは
libフォルダーにあります。
nhibernateと
fluent-nhibernate同じ方法
fluent-nhibernateインストールします。 結果は次のとおりです。
_componentoフォルダーはダウンロードされたファイルのキャッシュであり、
componento.dbはインストールされたコンポーネントとその依存関係のデータベースです。
その他の機能
componento install nunit /version 2.5.0.9122 、NUnitライブラリバージョン2.5.0.9122をインストールでき、componentoでは
componento uninstall nunit /force /recursive NUnitとすべての依存関係を削除できます。
さらに、ComponentoはSubversionリポジトリ、フォルダー、Zipファイルからインストールできます。 たとえば、
componento install bltoolkit /source svn+http://bl-toolkit.googlecode.com/svn/trunk/は、指定されたリポジトリからすべてのBLToolkitソースを取得します（HTTPまたはHTTPS経由でリポジトリにアクセスする場合は、
svn+プレフィックスが必要です） ） そして、
componento install myproject /source d:\projects\myproject.zip 、
myproject.zipアーカイブ
componento install myproject /source d:\projects\myproject.zip 「インストール」し
myproject.zip 。
そして、依存関係についてのいくつかの言葉。 Componentoが指定されたコンポーネントをインストールするルートフォルダーに、次の内容の
dependencies.txtファイル
dependencies.txt ：
nhibernate-linfu file:///e:/lib/nhibernate-linfu
nhibernate-castle file:///e:/lib/nhibernate-castle
その後、Componentoはすべての依存関係を再帰的にインストールし、その後バージョンの競合をチェックします。依存関係がある場合、コンポーネントを簡単に削除することはできません。
短所と欠陥
たくさんあります。 まず、パッケージ形式自体はありません。 つまり、コンポーネントに関するメタデータはまったくありません（バージョンと名前があることを除く）。 第二に、ローカルフォルダーとアーカイブの操作は完全に考慮されていません。 第三に、中央リポジトリでコンポーネントを公開する方法はまだありません（Webインターフェイスとコンポーネントを公開するための別のAPIの両方のアイデア）。 第4に、プラットフォームサポートはフレーム化されていません（たとえば、コンポーネントをSilverlight、.NET 2.0、.NET 3.0などのコンポーネントに分離するなど）。 まあ、一般的に-これは最初のアルファです。
結論の代わりに
私はまだこの創造物を英語圏の人々の法廷に置く準備ができていません。 まず、より実質的なものを取得する必要があります。 提案、提案、コメント、批判を歓迎します。 既に.NETのパッケージマネージャーをビルドしましょう！