次の方法で共有

NuGet 2.1 リリース ノート

NuGet 2.0 リリース ノート | NuGet 2.2 リリース ノート

NuGet 2.1 は 2012 年 10 月 4 日にリリースされました。

階層型 Nuget.Config

NuGet 2.1 を使用すると、フォルダー構造を再帰的に調べることで、 NuGet.Config ファイルを探し、検出されたすべてのファイルのセットから構成を構築することで、NuGet の設定をより柔軟に制御できます。 たとえば、チームに他の内部依存関係の CI ビルド用の内部パッケージ リポジトリがあるシナリオを考えてみましょう。 個々のプロジェクトのフォルダー構造は次のようになります。

C:\
C:\myteam\
C:\myteam\solution1
C:\myteam\solution1\project1

さらに、ソリューションに対してパッケージの復元が有効になっている場合は、次のフォルダーも存在します。

C:\myteam\solution1\.nuget

チームが作業するすべてのプロジェクトでチームの内部パッケージ リポジトリを使用できるようにするには、コンピューター上のすべてのプロジェクトで使用できるようにせずに、新しい Nuget.Config ファイルを作成し、c:\myteam フォルダーに配置します。 プロジェクトごとにパッケージ フォルダーを特定する方法はありません。

<configuration>
    <packageSources>
    <add key="Official project team source" value="http://teamserver/api/v2/" />
    </packageSources>
    <disabledPackageSources />
    <activePackageSource>
    <add key="Official project team source" value="http://teamserver/api/v2/" />
    </activePackageSource>
</configuration>

次に示すように、c:\myteam の下の任意のフォルダーから 'nuget.exe sources' コマンドを実行して、ソースが追加されたことを確認できます。

親 nuget 構成からのパッケージ ソース

NuGet.Config ファイルは次の順序で検索されます。

  1. .nuget\Nuget.Config
  2. プロジェクトフォルダーからルートへの再帰的な探索
  3. グローバル Nuget.Config (%appdata%\NuGet\Nuget.Config)

構成は 逆の順序で適用されます。つまり、上記の順序に基づいて、グローバル Nuget.Config が最初に適用され、次にルートからプロジェクト フォルダーに検出された Nuget.Config ファイルが適用され、その後に .nuget\Nuget.Config が適用されます。 これは、 <clear/> 要素を使用して一連の項目を構成から削除する場合に特に重要です。

'packages' フォルダーの場所を指定する

以前は、NuGet はソリューションのルート フォルダーの下にある既知の "パッケージ" フォルダーからソリューションのパッケージを管理してきました。 NuGet パッケージがインストールされているさまざまなソリューションを持つ開発チームの場合、同じパッケージがファイル システムのさまざまな場所にインストールされる可能性があります。

NuGet 2.1 では、repositoryPath ファイル内の NuGet.Config 要素を使用して、パッケージ フォルダーの場所をより細かく制御できます。 階層型 Nuget.Config サポートの前の例に基づいて、C:\myteam\ のすべてのプロジェクトが同じパッケージ フォルダーを共有することを想定しています。 これを実現するには、次のエントリを c:\myteam\Nuget.Configに追加するだけです。

<configuration>
    <config>
    <add key="repositoryPath" value="C:\myteam\teampackages" />
    </config>
    ...
</configuration>

この例では、共有 Nuget.Config ファイルは、深さに関係なく、C:\myteam の下に作成されるすべてのプロジェクトの共有パッケージ フォルダーを指定します。 ソリューション ルートの下に既存のパッケージ フォルダーがある場合は、NuGet が新しい場所にパッケージを配置する前に削除する必要があることに注意してください。

ポータブル ライブラリのサポート

ポータブル ライブラリ は、.NET 4 で初めて導入された機能です。これにより、the.NET Framework から Silverlight、Windows Phone、さらには Xbox 360 まで、さまざまな Microsoft プラットフォームで変更なしで動作できるアセンブリを構築できます (現時点では、NuGet は Xbox ポータブル ライブラリ ターゲットをサポートしていません)。 NuGet 2.1 では、フレームワークのバージョンとプロファイルの パッケージ規則 を拡張することで、複合フレームワークとプロファイル ターゲットの lib フォルダーを含むパッケージを作成できるようにすることで、ポータブル ライブラリをサポートするようになりました。

たとえば、次のポータブル クラス ライブラリの使用可能なターゲット プラットフォームについて考えてみましょう。

ポータブル ライブラリの作成ダイアログ

ライブラリがビルドされ、コマンド nuget.exe pack MyPortableProject.csproj が実行されると、生成された NuGet パッケージの内容を調べることで、新しいポータブル ライブラリ パッケージ フォルダー構造を確認できます。

ポータブル ライブラリ パッケージのレイアウト

ご覧のように、ポータブル ライブラリ フォルダー名規則は、フレームワーク識別子が既存の フレームワーク名とバージョン規則に従うパターン 'portable-{framework 1}+{framework n}' に従っています。 Windows Phone で使用されるフレームワーク識別子には、名前とバージョンの規則に対する例外が 1 つあります。 このモニカーは、フレームワーク名 'wp' (wp7、wp71、または wp8) を使用する必要があります。 たとえば、'silverlight-wp7' を使用すると、エラーが発生します。

このフォルダー構造から作成されたパッケージをインストールするときに、NuGet は、フォルダー名に指定されている複数のターゲットにフレームワークとプロファイルルールを適用できるようになりました。 NuGet の照合ルールの背後にあるのは、"より具体的な" ターゲットが "より具体的でない" ターゲットよりも優先されるという原則です。 つまり、特定のプラットフォームをターゲットとするモニカーは、両方ともプロジェクトと互換性がある場合、ポータブルプラットフォームよりも常に優先されます。 さらに、複数のポータブル ターゲットがプロジェクトと互換性がある場合、NuGet は、サポートされているプラットフォームのセットがパッケージを参照するプロジェクトに "最も近い" ものを優先します。

Windows 8 および Windows Phone 8 プロジェクトを対象とする

NuGet 2.1 では、ポータブル ライブラリ プロジェクトを対象とするサポートが追加されるだけでなく、Windows 8 ストアと Windows Phone 8 プロジェクトの両方に新しいフレームワーク モニカーが用意されています。また、Windows ストアおよび Windows Phone プロジェクト向けの新しい一般的なモニカーも用意されており、将来のバージョンの各プラットフォームで管理しやすくなります。

Windows 8 ストア アプリケーションの場合、識別子は次のようになります。

NuGet 2.0 以前 NuGet 2.1
winRT45, .NETCore45 Windows、Windows8、win、win8

Windows Phone プロジェクトの場合、識別子は次のようになります。
携帯電話OS NuGet 2.0 以前 NuGet 2.1
Windows Phone 7 silverlight3-wp wp、wp7、WindowsPhone、WindowsPhone7
Windows Phone 7.5 (マンゴー) silverlight4-wp71 wp71、WindowsPhone71
Windows Phone 8 (サポートされていません) wp8、WindowsPhone8

上記のすべての変更では、古いフレームワーク名は NuGet 2.1 で引き続き完全にサポートされます。 今後、新しい名前は、それぞれのプラットフォームの将来のバージョンで安定するため、使用する必要があります。 ただし、新しい名前は 2.1 より前のバージョンの NuGet ではサポートされません。そのため、切り替えのタイミングに応じて計画してください。

[パッケージ マネージャー] ダイアログでの検索の改善

過去のいくつかのイテレーションで、NuGet ギャラリーに変更が導入され、パッケージ検索の速度と関連性が大幅に向上しました。 ただし、これらの機能強化は、nuget.org Web サイトに限定されていました。 NuGet 2.1 を使用すると、NuGet パッケージ マネージャー ダイアログで検索エクスペリエンスが向上します。 たとえば、Windows Azure Caching Preview パッケージを見つけたいとします。 このパッケージの適切な検索クエリは、"Azure Cache" である可能性があります。 以前のバージョンのパッケージ マネージャー ダイアログでは、目的のパッケージは結果の最初のページに表示されません。 ただし、NuGet 2.1 では、目的のパッケージが検索結果の上部に表示されるようになりました。

パッケージ マネージャー ダイアログの検索

パッケージの強制的な更新

NuGet 2.1 より前では、バージョン番号が高くない場合、NuGet はパッケージの更新をスキップしていました。 これにより、特定のシナリオ (特に、チームがビルドごとにパッケージのバージョン番号をインクリメントしたくないビルドまたは CI シナリオの場合) に摩擦が発生しました。 望ましい動作は、関係なく強制的に更新を行う方法でした。 NuGet 2.1 では、"再インストール" フラグを使用してこれに対処します。 たとえば、以前のバージョンの NuGet では、より新しいバージョンのパッケージがないパッケージを更新しようとすると、次のようになります。

PM> Update-Package Moq
No updates available for 'Moq' in project 'MySolution.MyConsole'.

再インストール フラグを使用すると、新しいバージョンがあるかどうかに関係なく、パッケージが更新されます。

PM> Update-Package Moq -Reinstall
Successfully removed 'Moq 4.0.10827' from MySolution.MyConsole.
Successfully uninstalled 'Moq 4.0.10827'.
Successfully installed 'Moq 4.0.10827'.
Successfully added 'Moq 4.0.10827' to MySolution.MyConsole.

再インストール フラグが有益であることが証明されるもう 1 つのシナリオは、フレームワークの再ターゲットです。 プロジェクトのターゲット フレームワーク (.NET 4 から .NET 4.5 など) を変更する場合、Update-Package -Reinstall は、プロジェクトにインストールされているすべての NuGet パッケージの適切なアセンブリへの参照を更新できます。

Visual Studio でパッケージ ソースを編集する

以前のバージョンの NuGet では、Visual Studio オプション ダイアログ内からパッケージ ソースを更新するには、パッケージ ソースの削除と再追加が必要でした。 NuGet 2.1 では、構成ユーザー インターフェイスの最初のクラス関数として更新をサポートすることで、このワークフローが改善されています。

パッケージ マネージャーの構成ダイアログ

バグの修正

NuGet 2.1 には、多くのバグ修正が含まれています。 NuGet 2.0 で修正された作業項目の完全な一覧については、 [NuGet Issue Tracker for this release](http://nuget.codeplex.com/workitem/list/advanced?keyword=&status=Fixed&type=All&priority=All&release=NuGet%202.1&assignedTo=All&component=All&sortField=LastUpdatedDate&sortDirection=Descending&page=0)を参照してください。

  • Last updated on