パッケージマネージャは，Linux の世界では広く知られた存在である。必要とする依存対象パッケージ (dependency) をさまざまな場所から集めることが，Linux では重要であるためだ。優れたパッケージマネージャを使えば，ライブラリあるいはアプリケーションのある場所に関係なく，それが依存するパッケージの適切なバージョンもすべて合わせて，統一された方法で獲得することができる。Ruby プログラマにとって最も一般的なパッケージマネージャは RubyGems である。また Perl に関しては，総合的な Perl アーカイブネットワーク 上にホストされた CPAN module がある。
.NET 開発者にとって，本当の意味でこれに相当するものは存在しない。たとえ Microsoft が提供するコンポーネントに固執したところで，ライブラリは Microsoft の数多くの Web サイトのみならず，SourceForge や CodePlex などの独立サイトにまでも散らばっているのだ。Castle Windsor や NHibernate といった非 Microsoft のプロジェクトが存在感を増していることも，問題を複雑にしている。
Progressive.NET でのプレゼンテーションで Sebastien Lambla 氏は，バイナリ形式の依存パッケージ管理を目的とする OpenWrap プロジェクトを紹介した。Robert Pickering 氏が，動作の概要を次のように説明する。
パッケージはセントラルサーバに ZIP圧縮形式でストアされています。OpenWrap の定義する DSL (Domain Specific Language) を使って，必要なパッケージの適切なバージョンを指定することができます (ここでの構文はバージョンを最小と最大で指定できる，非常にフレキシブルなものです)。OpenWrap に用意されている msbuild ターゲットのセットを使用することで，この DSL で記述した内容をビルドプロセスに組み込むことができます。もちろん Visual Studio にも組み込み可能です。これらの msbuild ターゲットが必要なプロジェクトと依存パッケージをダウンロードして，ローカルマシン上の一元的キャッシュ (centralized cache) に配置する処理を行います。プロジェクトをビルドする時のライブラリ参照に，この一元的キャッシュが使用されるのです。
.NET エコシステムに参入するパッケージマネージャはこれが最初ではない。最近発表された，現時点ではコマンドラインツールである Bricks や，どういった理由からか Apache を必要とする WebGAC などがある。
OpenWrap はまだ初期段階なので，C# コンパイラの代わりに OpenWrap がコールされるようにするために，プロジェクトファイルを手作業で編集する必要がある。依存対象パッケージを “wrap descriptor” ファイルにリストしておくと, そのファイルが自動的にダウンロードされ，プロジェクトに追加される。参照対象は OpenWrap によって管理されているため，ソリューションエクスプローラの参照フォルダには表示されない。
OpenWrap のパッケージは ZIP フォーマットをベースにしている。これには Windows プログラマにはなじみ深いフォーマットであることに加えて，ヘッダ情報がファイルの末尾に置かれているために拡張性が高い，という利点がある。ヘッダ情報以降がデッドスペースと認識されるため，ディジタル署名をストアするのに好都合な場所になっているのだ。