次の方法で共有

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>

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

Package sources from parent nuget config

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

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

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

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

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

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

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

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

ポータブル ライブラリ対応

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

例えば、次の移植可能なクラス ライブラリの使用可能なターゲットにするプラットフォームを検討します。

Portable library creation dialog

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

Portable library package layout

ご覧のように、ポータブル ライブラリ フォルダー名前付け規則は、フレームワーク識別子が既存 のフレームワーク名とバージョン規則に従うパターン '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 Storeと Windows Phone 8 プロジェクトの両方に新しいフレームワーク モニカーが提供されます。また、Windows Storeおよび Windows Phone プロジェクト向けの新しい一般的なモニカーも用意されており、それぞれのプラットフォームの将来のバージョンで管理しやすくなります。

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

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

Windows Phone プロジェクトの場合、識別子は次のようになります。
Phone OS .NET 2.0 以前 NuGet 2.1
Windows Phone 7 silverlight3-wp wp, wp7, WindowsPhone, WindowsPhone7
Windows Phone 7.5 (Mango) 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 のキャッシュ プレビューパッケージFINDを実行するとします。 このパッケージの適切な検索クエリは、"Azure Cache" であることがあります。 以前のバージョンのパッケージ マネージャー ダイアログでは、必要なパッケージは結果の最初のページに表示されません。 ただし、NuGet 2.1 では、必要なパッケージが検索結果の上部に表示されるようになりました。

Package manager dialog search

パッケージの強制更新

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 では、構成ユーザー インターフェイスの最初のクラス関数として更新をサポートして、このワークフローが改善されています。

Package manager configuration dialog

バグ修正

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)を参照してください。