NuGet.org アカウントの質問など、NuGet.org に関してよく寄せられる質問については、「NuGet.org に関してよく寄せられる質問」を参照してください。
UI とコマンド ライン ツールの両方に関するすべての情報は、インストール ガイドで入手できます。
コマンドライン ツール nuget.exe
、通常は Windows でビルドおよび実行されます。 NuGet は、 mono
を使用して Unix オペレーティング システムで実行できますが、 NuGet のサポート ポリシーでは正式にはサポートされていません。
パッケージについて学習するための主なソースとして、nuget.org (または別のプライベート フィード) のリスト ページがあります。 nuget.org の各パッケージ ページには、パッケージ、そのバージョン履歴、使用状況の統計の説明が含まれます。 パッケージ ページの [情報] セクションには、プロジェクトの Web サイトへのリンクも含まれています。通常はこのサイトで、パッケージの使用方法について学習する際に役立つ多くの例とその他のドキュメントを見つけます。
詳細については、「パッケージの検索と選択」を参照してください。
- Windows の Visual Studio では、パッケージ マネージャー UI とパッケージ マネージャー コンソールがサポートされます。
- 「プロジェクトに NuGet パッケージを含める」で説明されているように、Visual Studio for Mac には NuGet 機能が組み込まれています。
- Visual Studio Code (すべてのプラットフォーム) には、直接 NuGet は統合されていません。 NuGet CLI または dotnet CLI を使用してください。
- Azure DevOps には、NuGet パッケージを復元するためのビルド ステップがあります。 Azure DevOps でプライベート NuGet パッケージ フィードをホストすることもできます。
Visual Studio で、[ヘルプ > Microsoft Visual Studio の情報] コマンドを使用して、[NuGet パッケージ マネージャー] の横に表示されるバージョンを確認します。
または、パッケージ マネージャー コンソールを起動 ([ツール > NuGet パッケージ マネージャー > パッケージ マネージャー コンソール] の順に選択) し、「$host
」と入力して、バージョンを含む NuGet に関する情報を表示します。
通常、NuGet は .NET 言語に対して動作し、プロジェクトに .NET ライブラリを取り込むように設計されています。 また、いくつかのプロジェクトの種類で MSBuild と Visual Studio オートメーションがサポートされるため、程度の差はありますが他のプロジェクトと言語もサポートされます。
最新バージョンの NuGet では C#、Visual Basic、F#、WiX、C++、Q# がサポートされます。
NuGet では、Windows、Web、クラウド、SharePoint、Wix などのさまざまなプロジェクト テンプレートが完全にサポートされます。
パッケージ マネージャー UI の [更新] タブに移動して、[すべて更新] を選択するか、パッケージ マネージャー コンソールで Update-Package
コマンドを使用します。
テンプレート自体を更新するには、テンプレート リポジトリを手動で更新する必要があります。 これについては、Xavier Decoster のブログを参照してください。 最新バージョンのすべての依存関係が相互に互換性がない場合、手動で更新するとテンプレートが壊れる可能性があるため、これは自身の責任で行うことに注意してください。
はい。NuGet はコマンド ラインから直接動作します。 インストール ガイドと CLI 参照に関するページを参照してください。
インストール ガイドを参照してください。 現在インストールされているツールのバージョンを確認するには、nuget help
を使用します。
MIT ライセンスの条件に従って、nuget.exe を再配布できます。 再配布を選択した nuget.exe のコピーを更新および修正するのは、お客様の責任です。
はい。Archive.org から利用可能な Rob Reynold の投稿で説明されているように、nuget.exe
にカスタム コマンドを追加することができます。
Visual Studio オートメーション オブジェクト モデルのトップ レベル オブジェクトは、DTE (開発ツール環境) オブジェクトと呼ばれます。 コンソールでは、$DTE
という名前の変数を通じてこれが提供されます。 詳細については、Visual Studio 機能拡張ドキュメントの「オートメーション モデルの概要」を参照してください。
$DTE 変数を DTE2 型にキャストしようとしましたが、""EnvDTE.DTEClass" 型の "EnvDTE.DTEClass" 値を "EnvDTE80.DTE2" 型に変換できません" という内容のエラーが表示されました。 理由
これは、PowerShell が COM オブジェクトと対話する方法に関する既知の問題です。 次の操作を試してみてください。
`$dte2 = Get-Interface $dte ([EnvDTE80.DTE2])`
Get-Interface
は、NuGet PowerShell ホストによって追加されたヘルパー関数です。
「パッケージの作成と発行」を参照してください。
複数の .NET Framework バージョンとプロファイルのサポートに関するページを参照してください。
パッケージのホスティングの概要に関するページを参照してください。
「Bulk publishing NuGet packages」 (NuGet パッケージの一括発行) (jeffhandly.com) を参照してください。
はい。Scott Hanselman のブログ投稿「How to access NuGet when nuget.org is down (or you're on a plane)」 (nuget.org がダウンしたとき (または飛行機内で) NuGet にアクセスする方法) (hanselman.com) を参照してください。
nuget config -set repositoryPath=<path>
を使用して、Nuget.Config
で repositoryPath
を設定します。
Nuget.Config
の disableSourceControlIntegration
を true
に設定します。 このキーはソリューション レベルで動作するため、$(Solutiondir)\.nuget\Nuget.Config
ファイルに追加する必要があります。 Visual Studio からのパッケージの復元を有効にすると、このファイルは自動的に作成されます。
「パッケージの復元の有効化と無効化」を参照してください。
プロジェクトにローカル パッケージをインストールする場合は、すべてのソースを選択する必要があります。 これにより、フィードを 1 つだけ使用するのではなく、すべて集約することになります。 このエラーが表示されるのは、ローカル リポジトリのユーザーは、多くの場合、企業ポリシーにより、リモート パッケージが誤ってインストールされないようにする必要があるためです。
別個のプロジェクトが別個のフォルダーに存在するほとんどのプロジェクトでは、NuGet で各プロジェクトの packages.config
ファイルが特定されるため、これは問題ではありません。 NuGet 3.3+ では、同じフォルダーに複数のプロジェクトがある場合、プロジェクトの名前を packages.config
ファイル名に挿入できます (パターン packages.{project-name}.config
を使用)。NuGet はそのファイルを使用します。
各プロジェクト ファイルには独自の依存関係リストが含まれるため、PackageReference を使用する場合、これは問題ではありません。
- 自分のソース リストに
https://api.nuget.org/v3/index.json
を追加します。または、 %appdata%\.nuget\NuGet.Config
(Windows) または~/.nuget/NuGet/NuGet.Config
(Mac/Linux) を削除し、NuGet で自動的に再作成します。
packages.config プロジェクトでは、build
プロパティまたはターゲットを含むパッケージがインストールされると、NuGet によって EnsureNuGetPackageBuildImports
ターゲットが追加され、ビルド前にパッケージの msbuild コンテンツがインポートされたことが確認されます。
target
が手動で変更された場合、移行時に削除する必要があることが NuGet によって検出できない場合があります。
プロジェクトが PackageReference
であり、プロジェクト ファイルにこのターゲットがまだある場合は、削除しても問題ありません。