diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS new file mode 100644 index 000000000..a8838bc78 --- /dev/null +++ b/.github/CODEOWNERS @@ -0,0 +1,14 @@ +# These owners will be the default owners for everything in +# the repo. Unless a later match takes precedence, +# review when someone opens a pull request. +# For more on how to customize the CODEOWNERS file - https://help.github.com/en/articles/about-code-owners +* @NuGet/nuget-client @NuGet/nuget-pm + +# @NuGet/core-team owns any file in the `/docs/nuget-org/` directory +# in the root of your repository and any of its subdirectories. +/docs/nuget-org/ @NuGet/nuget-client @NuGet/nuget-pm @NuGet/gallery-team +/docs/api/ @NuGet/nuget-client @NuGet/nuget-pm @NuGet/gallery-team + +# @NuGet/core-team owns any file in the `/docs/policies/` directory +# in the root of your repository and any of its subdirectories. +/docs/policies/ @NuGet/nuget-client @NuGet/nuget-pm @NuGet/gallery-team diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md new file mode 100644 index 000000000..344d2e2ad --- /dev/null +++ b/.github/copilot-instructions.md @@ -0,0 +1,56 @@ +# .NET Documentation Guidelines + +## Disclosure + +For any Markdown files generated by AI, always disclose that they were created with the assistance of AI. Add the following frontmatter key/value pair: + +```markdown +ai-usage: ai-generated +``` + +## Terminology + +Unless otherwise specified, all .NET content refers to modern .NET (not .NET Framework). + +## Writing Style + +Follow [Microsoft Writing Style Guide](https://learn.microsoft.com/en-us/style-guide/welcome/) with these specifics: + +### Voice and Tone + +- Active voice, second person addressing reader directly. +- Conversational tone with contractions. +- Present tense for instructions/descriptions. +- Imperative mood for instructions ("Call the method" not "You should call the method"). +- Use "might" instead of "may" for possibility. +- Use "can" instead of "may" for permissible actions. +- Avoid "we"/"our" referring to documentation authors or product teams. + +### Structure and Format + +- Sentence case headings (no gerunds in titles). +- Be concise, break up long sentences. +- Oxford comma in lists. +- Use bullets for unordered lists. +- Number all ordered list items as "1." (not sequential numbering like "1.", "2.", "3.", etc.) +- Ordered and unordered lists should use complete sentences with proper punctuation, ending with a period if it's more than three words. +- Avoid "etc." or "and so on" - provide complete lists or use "for example". +- Use "for example" instead of "e.g.". +- Use "that is" instead of "i.e.". +- No consecutive headings without content between them. + +### Formatting Conventions + +- **Bold** for UI elements. +- `Code style` for file names, folders, custom types, non-localizable text. +- Raw URLs in angle brackets. +- Use relative links for files in this repo. +- Remove `https://learn.microsoft.com/en-us` from learn.microsoft.com links. + +## File Naming + +New Markdown files: lowercase with hyphens, omit filler words (the, a, etc.). + +## Special Cases + +- When you (Copilot) are assigned an issue in GitHub, after you've completed your work and the workflows (status checks) have run, check to make sure there are no build warnings under the OpenPublishing.Build status check. If there are, open the build report (under View Details) and resolve any build warnings you introduced. diff --git a/.github/fabricbot.json b/.github/fabricbot.json new file mode 100644 index 000000000..8dc051bb6 --- /dev/null +++ b/.github/fabricbot.json @@ -0,0 +1,410 @@ +{ + "version": "1.0", + "tasks": [ + { + "taskType": "trigger", + "capabilityId": "IssueResponder", + "subCapability": "IssueCommentResponder", + "version": "1.0", + "config": { + "conditions": { + "operator": "and", + "operands": [ + { + "name": "isAction", + "parameters": { + "action": "created" + } + }, + { + "name": "hasLabel", + "parameters": { + "label": "WaitingForCustomer" + } + }, + { + "name": "isOpen", + "parameters": {} + }, + { + "operator": "or", + "operands": [ + { + "operator": "and", + "operands": [ + { + "name": "hasLabel", + "parameters": { + "label": "Transferred issue" + } + }, + { + "operator": "not", + "operands": [ + { + "name": "activitySenderHasPermissions", + "parameters": { + "permissions": "write" + } + } + ] + } + ] + }, + { + "name": "isActivitySender", + "parameters": { + "user": { + "type": "author" + } + } + } + ] + } + ] + }, + "eventType": "issue", + "eventNames": [ + "issue_comment" + ], + "taskName": "[Manage \"WaitingFor\" labels] Replace tag \"WaitingForCustomer\" with \"WaitingForNuGetTeam\" when the author comments on an issue. Also remove `Status:No recent activity` if it's been set.", + "actions": [ + { + "name": "removeLabel", + "parameters": { + "label": "WaitingForCustomer" + } + }, + { + "name": "addLabel", + "parameters": { + "label": "WaitingForNuGetTeam" + } + }, + { + "name": "removeLabel", + "parameters": { + "label": "Status:No recent activity" + } + } + ] + }, + "disabled": false + }, + { + "taskType": "trigger", + "capabilityId": "IssueResponder", + "subCapability": "IssuesOnlyResponder", + "version": "1.0", + "config": { + "conditions": { + "operator": "and", + "operands": [ + { + "name": "isAction", + "parameters": { + "action": "closed" + } + }, + { + "operator": "or", + "operands": [ + { + "name": "hasLabel", + "parameters": { + "label": "WaitingForNuGetTeam" + } + }, + { + "name": "hasLabel", + "parameters": { + "label": "WaitingForCustomer" + } + } + ] + } + ] + }, + "eventType": "issue", + "eventNames": [ + "issues", + "project_card" + ], + "taskName": "[Manage \"WaitingFor\" labels] Remove any \"WaitingFor\" label when the issue is closed", + "actions": [ + { + "name": "removeLabel", + "parameters": { + "label": "WaitingForNuGetTeam" + } + }, + { + "name": "removeLabel", + "parameters": { + "label": "WaitingForCustomer" + } + } + ] + }, + "disabled": false + }, + { + "taskType": "trigger", + "capabilityId": "IssueResponder", + "subCapability": "IssueCommentResponder", + "version": "1.0", + "config": { + "conditions": { + "operator": "and", + "operands": [ + { + "name": "isAction", + "parameters": { + "action": "created" + } + }, + { + "name": "hasLabel", + "parameters": { + "label": "WaitingForNuGetTeam" + } + }, + { + "name": "isOpen", + "parameters": {} + }, + { + "name": "activitySenderHasPermissions", + "parameters": { + "permissions": "write" + } + } + ] + }, + "eventType": "issue", + "eventNames": [ + "issue_comment" + ], + "taskName": "[Manage \"WaitingFor\" labels] Replace tag \"WaitingForNuGetTeam\" with \"WaitingForCustomer\" when NuGet team comments on an issue.", + "actions": [ + { + "name": "removeLabel", + "parameters": { + "label": "WaitingForNuGetTeam" + } + }, + { + "name": "addLabel", + "parameters": { + "label": "WaitingForCustomer" + } + } + ] + }, + "disabled": false + }, + { + "taskType": "scheduled", + "capabilityId": "ScheduledSearch", + "subCapability": "ScheduledSearch", + "version": "1.0", + "config": { + "frequency": [ + { + "weekDay": 0, + "hours": [ + 6 + ], + "timezoneOffset": -7 + }, + { + "weekDay": 1, + "hours": [ + 6 + ], + "timezoneOffset": -7 + }, + { + "weekDay": 2, + "hours": [ + 6 + ], + "timezoneOffset": -7 + }, + { + "weekDay": 3, + "hours": [ + 6 + ], + "timezoneOffset": -7 + }, + { + "weekDay": 4, + "hours": [ + 6 + ], + "timezoneOffset": -7 + }, + { + "weekDay": 5, + "hours": [ + 6 + ], + "timezoneOffset": -7 + }, + { + "weekDay": 6, + "hours": [ + 6 + ], + "timezoneOffset": -7 + } + ], + "searchTerms": [ + { + "name": "hasLabel", + "parameters": { + "label": "WaitingForCustomer" + } + }, + { + "name": "noActivitySince", + "parameters": { + "days": 14 + } + }, + { + "name": "isIssue", + "parameters": {} + }, + { + "name": "isOpen", + "parameters": {} + }, + { + "name": "noLabel", + "parameters": { + "label": "Status:No recent activity" + } + } + ], + "taskName": "[Manage stale WaitingForCustomer issues] Search for WaitingForCustomer issues with no activity over 14 days and warn.", + "actions": [ + { + "name": "addLabel", + "parameters": { + "label": "Status:No recent activity" + } + }, + { + "name": "addReply", + "parameters": { + "comment": "This issue has been automatically marked as stale because we have not received a response in 14 days. It will be closed if no further activity occurs within another 14 days of this comment." + } + } + ] + } + }, + { + "taskType": "scheduled", + "capabilityId": "ScheduledSearch", + "subCapability": "ScheduledSearch", + "version": "1.0", + "config": { + "frequency": [ + { + "weekDay": 0, + "hours": [ + 6 + ], + "timezoneOffset": -7 + }, + { + "weekDay": 1, + "hours": [ + 6 + ], + "timezoneOffset": -7 + }, + { + "weekDay": 2, + "hours": [ + 6 + ], + "timezoneOffset": -7 + }, + { + "weekDay": 3, + "hours": [ + 6 + ], + "timezoneOffset": -7 + }, + { + "weekDay": 4, + "hours": [ + 6 + ], + "timezoneOffset": -7 + }, + { + "weekDay": 5, + "hours": [ + 6 + ], + "timezoneOffset": -7 + }, + { + "weekDay": 6, + "hours": [ + 6 + ], + "timezoneOffset": -7 + } + ], + "searchTerms": [ + { + "name": "hasLabel", + "parameters": { + "label": "Status:No recent activity" + } + }, + { + "name": "noActivitySince", + "parameters": { + "days": 14 + } + }, + { + "name": "isIssue", + "parameters": {} + }, + { + "name": "isOpen", + "parameters": {} + } + ], + "taskName": "[Close stale WaitingForCustomer issues] Search for stale WaitingForCustomer issues with no activity over 14 days and warn.", + "actions": [ + { + "name": "closeIssue", + "parameters": {} + }, + { + "name": "removeLabel", + "parameters": { + "label": "Status:No recent activity" + } + }, + { + "name": "addLabel", + "parameters": { + "label": "Resolution:NeedMoreInfo" + } + } + ] + } + } + ], + "userGroups": [] + } \ No newline at end of file diff --git a/.gitignore b/.gitignore index 42594a1c0..13ade8981 100644 --- a/.gitignore +++ b/.gitignore @@ -6,4 +6,7 @@ _themes/ _themes.MSDN.Modern/ _themes.VS.Modern/ +# Visual Studio +.vs/ + .openpublishing.buildcore.ps1 \ No newline at end of file diff --git a/.openpublishing.build.ps1 b/.openpublishing.build.ps1 deleted file mode 100644 index aadef7620..000000000 --- a/.openpublishing.build.ps1 +++ /dev/null @@ -1,17 +0,0 @@ -param( - [string]$buildCorePowershellUrl = "https://opbuildstorageprod.blob.core.windows.net/opps1container/.openpublishing.buildcore.ps1", - [string]$parameters -) -# Main -$errorActionPreference = 'Stop' - -# Step-1: Download buildcore script to local -echo "download build core script to local with source url: $buildCorePowershellUrl" -$repositoryRoot = Split-Path -Parent $MyInvocation.MyCommand.Definition -$buildCorePowershellDestination = "$repositoryRoot\.openpublishing.buildcore.ps1" -Invoke-WebRequest $buildCorePowershellUrl -OutFile "$buildCorePowershellDestination" - -# Step-2: Run build core -echo "run build core script with parameters: $parameters" -& "$buildCorePowershellDestination" "$parameters" -exit $LASTEXITCODE diff --git a/.openpublishing.publish.config.json b/.openpublishing.publish.config.json index a646e7a6c..39be778c5 100644 --- a/.openpublishing.publish.config.json +++ b/.openpublishing.publish.config.json @@ -18,41 +18,51 @@ } ], "notification_subscribers": [], + "sync_notification_subscribers": null, "branches_to_filter": [], "git_repository_url_open_to_public_contributors": "https://github.com/NuGet/docs.microsoft.com-nuget", - "git_repository_branch_open_to_public_contributors": "master", + "git_repository_branch_open_to_public_contributors": "main", "skip_source_output_uploading": false, + "need_preview_pull_request": true, "contribution_branch_mappings": {}, "dependent_repositories": [ { "path_to_root": "_themes", "url": "https://github.com/Microsoft/templates.docs.msft", - "branch": "master", + "branch": "main", "branch_mapping": {} }, { "path_to_root": "_themes.pdf", "url": "https://github.com/Microsoft/templates.docs.msft.pdf", - "branch": "master", + "branch": "main", + "branch_mapping": {} + }, + { + "path_to_root": "nuget-samples", + "url": "https://github.com/NuGet/Samples", + "branch": "main", "branch_mapping": {} } ], - "branch_target_mapping": { - "live": [ - "Publish", - "Pdf" + "branch_target_mapping": { + "live": [ + "Publish", + "Pdf" ], - "master": [ + "main": [ "Publish", "PDF" ] }, "need_generate_pdf_url_template": true, - "need_preview_pull_request": true, "Targets": { "Pdf": { "template_folder": "_themes.pdf" } }, - "need_generate_pdf": false -} + "need_generate_pdf": false, + "docs_build_engine": { + "name": "docfx_v3" + } +} \ No newline at end of file diff --git a/.openpublishing.redirection.json b/.openpublishing.redirection.json index ce0335103..be80d09e9 100644 --- a/.openpublishing.redirection.json +++ b/.openpublishing.redirection.json @@ -27,7 +27,7 @@ }, { "source_path": "docs/create-packages/Dependency-Versions.md", - "redirect_url": "/nuget/reference/package-versioning", + "redirect_url": "/nuget/concepts/package-versioning", "redirect_document_id": false }, { @@ -62,7 +62,7 @@ }, { "source_path": "docs/Schema/analyzers-conventions.md", - "redirect_url": "/nuget/reference/analyzers-conventions", + "redirect_url": "/nuget/guides/analyzers-conventions", "redirect_document_id": false }, { @@ -99,7 +99,7 @@ "source_path": "docs/Quickstart/Create-and-publish-a-package.md", "redirect_url": "/nuget/quickstart/create-and-publish-a-package-using-visual-studio", "redirect_document_id": false - }, + }, { "source_path": "docs/Quickstart/Use-a-Package.md", "redirect_url": "/nuget/quickstart/install-and-use-a-package-in-visual-studio", @@ -107,12 +107,42 @@ }, { "source_path": "docs/policies/command-line-reference.md", - "redirect_url": "/nuget/tools/nuget-exe-cli-reference", + "redirect_url": "/nuget/reference/nuget-exe-cli-reference", "redirect_document_id": false }, { "source_path": "docs/policies/nuget-faq.md", - "redirect_url": "/nuget/faqs/nuget-faq", + "redirect_url": "/nuget/resources/nuget-faq", + "redirect_document_id": false + }, + { + "source_path": "docs/faqs/nuget-faq.md", + "redirect_url": "/nuget/resources/nuget-faq", + "redirect_document_id": false + }, + { + "source_path": "docs/reference/migrate-packages-config-to-package-reference.md", + "redirect_url": "/nuget/consume-packages/migrate-packages-config-to-package-reference", + "redirect_document_id": false + }, + { + "source_path": "docs/reference/analyzers-conventions.md", + "redirect_url": "/nuget/guides/analyzers-conventions", + "redirect_document_id": false + }, + { + "source_path": "docs/create-packages/native-packages.md", + "redirect_url": "/nuget/guides/native-packages", + "redirect_document_id": false + }, + { + "source_path": "docs/consume-packages/dependency-resolution.md", + "redirect_url": "/nuget/concepts/dependency-resolution", + "redirect_document_id": false + }, + { + "source_path": "docs/reference/package-versioning.md", + "redirect_url": "/nuget/concepts/package-versioning", "redirect_document_id": false }, { @@ -334,6 +364,31 @@ "source_path": "docs/tools/ps-ref-update-package.md", "redirect_url": "/nuget/reference/ps-reference/ps-ref-update-package", "redirect_document_id": false + }, + { + "source_path": "docs/reference/errors-and-warnings/NU1901.md", + "redirect_url": "/nuget/reference/errors-and-warnings/NU1901-NU1904", + "redirect_document_id": false + }, + { + "source_path": "docs/reference/errors-and-warnings/NU1902.md", + "redirect_url": "/nuget/reference/errors-and-warnings/NU1901-NU1904", + "redirect_document_id": false + }, + { + "source_path": "docs/reference/errors-and-warnings/NU1903.md", + "redirect_url": "/nuget/reference/errors-and-warnings/NU1901-NU1904", + "redirect_document_id": false + }, + { + "source_path": "docs/reference/errors-and-warnings/NU1904.md", + "redirect_url": "/nuget/reference/errors-and-warnings/NU1901-NU1904", + "redirect_document_id": false + }, + { + "source_path": "docs/guides/create-packages-for-xamarin.md", + "redirect_url": "/nuget", + "redirect_document_id": false } ] } diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 000000000..2f1b58d08 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,39 @@ +# Contributing + +No contribution is too big or too small. + +1. Visit the page to edit in the [NuGet documentation](https://learn.microsoft.com/nuget/), then click the **Edit** button on the top right. This brings you to the appropriate markdown page in the repo. +1. Edit the markdown: + 1. If you're including images (use PNGs, generally), place them in the media folder that's in the topic's folder. Links are then `media/.png`. + 1. Relative links to other pages in this docset should be in the form `..//.md` including the training `.md`. If you're linking to another topic in the same folder, then `..//` can be omitted. When using anchors, always remember to include the `.md` before the `#`. + 1. When using external links, especially to Microsoft Learn, omit any language tag like "en-us" so that a reader in another language lands on a target page in that same language if it's available. +1. When you're done, enter a commit message below, and click **Propose file change**. +1. Send a pull request for your change. We review PRs on a regular basis. +1. Thank you! + +If you're creating a new topic, keep the following in mind as well: + +1. Always place the new topic in an appropriate subfolder, and follow the conventions for filenames as you see them used here. + +1. You must include a metadata block as you see on other topics. Typical defaults (such as for `ms.workload` and `ms.reviewer`) are set within `docs/docjx.json`, so you need only change the following: + + - title: The title that appears in search results. For SEO, this ideally isn't the same as the top-level # (H1) of the article. + - description: The abstract of the article that appears in search results. + - author: the author's GitHub ID, to which issues files for this article are assigned. + - ms.author: if the author is a Microsoft employee, this is the Microsoft alias. Used for reporting and forwarding feedback from other channels. + - manager: Microsoft alias of the author's manager, if applicable. + - ms.date: the date of the last revision or review of the article in mm/dd/yyyy format (use leading zeros). This is a communication to the reader about freshness, so it's not updated for minor changes, only for more significant revisions OR when the article has reverified even if there are no changes. + - ms.topic: used to categorize the article in reports. See table below. Most articles are "conceptual". + +1. In addition to adding your page, edit `docs/TOC.md` to add a link to that page. + +1. If you're adding a top-level node to the TOC, also make an entry for it in `docs/index.md`. + +| ms.topic category | Description | +| --- | --- | +| conceptual | Use for any content that doesn't fall into another. This is set as the default in docfx.json. | +| overview | Use for any overview or user-guide articles, typically only those that live under an "Overview" node in the TOC. | +| quickstart | Anything under the "Quickstart" node in the TOC that's authored according to Quickstart guidelines. | +| tutorial | Anything under the "Tutorial" node in the TOC that's authored according to Tutorial guidelines. | +| reference | Any reference-type article that isn't auto-generated. | +| article | Use for community-contributed content (that is, anything from outside the engineering team or the content team at Microsoft. | diff --git a/README.md b/README.md index 087489c93..36a0aa314 100644 --- a/README.md +++ b/README.md @@ -1,48 +1,51 @@ -# docs.microsoft.com-nuget +# NuGet Docs -The NuGet documentation contained in this repository is hosted on docs.microsoft.com/nuget. This repository was migrated from the former NuGetDocs repository, https://github.com/NuGet/NuGetDocs, which is no longer in active use. +The NuGet documentation contained in this repository is hosted in [NuGet documentation](https://learn.microsoft.com/nuget/). This repository was migrated from the former NuGetDocs repository, https://github.com/NuGet/NuGetDocs, which is no longer in active use. -Contributions to this docset are welcome. Please submit PRs to the *master* branch. (The master branch is used for staging changes which is periodically merged into the *live* branch which is what's published to the live docs site.) +Contributions to this docset are welcome. Please submit PRs to the *main* branch. The main branch is used for staging changes which is periodically merged into the *live* branch which is what's published to the live Microsoft Learn site. NuGet follows the [.NET Foundation Contributors Code of Conduct](https://github.com/dotnet/home/blob/master/guidance/be-nice.md). Please take a few minutes to review it. -## Respository structure +## Repository structure -- All markdown files are in the docs folder and various subfolders. -- The docs/index.md file defines the landing (hub) page as it appears on docs.microsoft.com/nuget. -- The docs/TOC.md file defines the left-hand navigation panel that appears when you navigate to any page other than the hub page. +- All markdown files are in the `docs` folder and various subfolders. +- The `docs/index.md` file defines the landing (hub) page as it appears in the [NuGet documentation](https://learn.microsoft.com/nuget). +- The `docs/TOC.md` file defines the left-hand navigation panel that appears when you navigate to any page other than the hub page. - Images are contained within media folders within each subfolder. -- The docs/docfx.json file contains various defaults, especially for metadata. -- The docs/.openpublishing.redirection.json file contains redirects for old filenames; if you rename a file, create an entry here that maps the old to the new. -- The docs/_breadcrumb/toc.yml file defines the breadcrumbs that appear on the site and their target pages. Be mindful of this if you make changes to filenames or placement of articles. +- The `docs/docfx.json` file contains various defaults, especially for metadata. +- The `docs/.openpublishing.redirection.json` file contains redirects for old filenames; if you rename a file, create an entry here that maps the old to the new. +- The `docs/_breadcrumb/toc.yml` file defines the breadcrumbs that appear on the site and their target pages. Be mindful of this if you make changes to filenames or placement of articles. ## Contribution workflow -No contribution is too big or too small-- +No contribution is too big or too small. -1. Visit the page to edit on [docs.microsoft.com/nuget](https://docs.microsoft.com/nuget/), then click the **Edit** button on the top right. This brings you to the appropriate markdown page in the repo. +1. Visit the page to edit in [NuGet documentation](https://learn.microsoft.com/nuget/), then click the **Edit** button on the top right. This brings you to the appropriate markdown page in the repo. 1. Edit the markdown: 1. If you're including images (use PNGs, generally), place them in the media folder that's in the topic's folder. Links are then `media/.png`. - 1. Relative links to other pages in this docset should be in the form `..//.md` including the training `.md`. If you're linking to another topic in the same folder, then `..//` can be omitted. When using anchors, always remember to include the `.md` before the `#`. - 1. When using external links, especially to docs.microsoft.com (or msdn.microsoft.com for any older content), omit any language tag like "en-us" so that a reader in another language lands on a target page in that same language if it's available. + 1. Relative links to other pages in this docset should be in the form `..//.md` including the trailing `.md`. If you're linking to another topic in the same folder, then `..//` can be omitted. When using anchors, always remember to include the `.md` before the `#`. + 1. When using external links, especially to Microsoft Learn, omit any language tag like "en-us" so that a reader in another language lands on a target page in that same language if it's available. 1. When you're done, enter a commit message below, and click **Propose file change**. -1. Send a pull request for your change. We review PRs on a regular basis. +1. Send a pull request for your change. Review requests are automatic and we review PRs on a regular basis. 1. Thank you! If you're creating a new topic, keep the following in mind as well: 1. Always place the new topic in an appropriate subfolder, and follow the conventions for filenames as you see them used here. -1. You must include a metadata block as you see on other topics. Typical defaults (such as for ms.workload and ms.reviewer) are set within docs/docjx.json, so you need only change the following: - - - title: The title that appears in search results. For SEO, this ideally isn't the same as the top-level # (H1) of the article. - - description: The abstract of the article that appears in search results. - - author: the author's GitHub ID, to which issues files for this article are assigned. - - ms.author: if the author is a Microsoft employee, this is the Microsoft alias. Used for reporting and forwarding feedback from other channels. - - manager: Microsoft alias of the author's manager, if applicable. - - ms.date: the date of the last revision or review of the article in mm/dd/yyyy format (use leading zeros). This is a communication to the reader about freshness, so it's not updated for minor changes, only for more significant revisions OR when the article has reverified even if there are no changes. - - ms.topic: used to categorize the article in reports. See table below. Most articles are "conceptual". -1. In addition to adding your page, edit docs/TOC.md to add a link to that page. -1. If you're adding a top-level node to the TOC, also make an entry for it in docs/index.md. + +1. You must include a metadata block as you see on other topics. Typical defaults (such as for `ms.workload` and `ms.reviewer`) are set within `docs/docjx.json`, so you need only change the following: + + - title: The title that appears in search results. For SEO, this ideally isn't the same as the top-level # (H1) of the article. + - description: The abstract of the article that appears in search results. + - author: the author's GitHub ID, to which issues files for this article are assigned. + - ms.author: if the author is a Microsoft employee, this is the Microsoft alias. Used for reporting and forwarding feedback from other channels. + - manager: Microsoft alias of the author's manager, if applicable. + - ms.date: the date of the last revision or review of the article in mm/dd/yyyy format (use leading zeros). This is a communication to the reader about freshness, so it's not updated for minor changes, only for more significant revisions OR when the article has reverified even if there are no changes. + - ms.topic: used to categorize the article in reports. See table below. Most articles are "conceptual". + +1. In addition to adding your page, edit `docs/TOC.md` to add a link to that page. + +1. If you're adding a top-level node to the TOC, also make an entry for it in `docs/index.md`. | ms.topic category | Description | | --- | --- | @@ -51,7 +54,14 @@ If you're creating a new topic, keep the following in mind as well: | quickstart | Anything under the "Quickstart" node in the TOC that's authored according to Quickstart guidelines. | | tutorial | Anything under the "Tutorial" node in the TOC that's authored according to Tutorial guidelines. | | reference | Any reference-type article that isn't auto-generated. | -| article | Use for community-contributed content (that is, anything from outside the engineering team or the docs team at Microsoft. | +| article | Use for community-contributed content (that is, anything from outside the engineering team or the content team at Microsoft. | + +## Merging to the live branch + +NuGet team members have permissions to merge to `live` branch manually, at their own discretion. +Otherwise, a regular (about once a month) Reverse Integration (RI) will be performed from `main` -> `live` branch. +Based on the urgency of the docs, this may happen frequently. +It is very important that the RI pull requests are *merged* and *not squashed*. ## Conventions @@ -59,7 +69,7 @@ In general, if you don't see something described here, look in editing markdown ## Language level and terms -Because our docs can be localized into many languages other than English, topics should be written at what's called the "fifth-grade" reading level, or what a typical 11-12-year-old child would understand. In other words, avoid using college-level words if possible. +Because content can be localized into many languages other than English, topics should be written at what's called the "fifth-grade" reading level, or what a typical 11-12-year-old child would understand. In other words, avoid using college-level words if possible. To keep the tone more casual, use contractions like "you'll" and "don't". @@ -96,7 +106,7 @@ With boldface used for UI elements, use *italics* for emphasis in the text. ### Tables -Use standard markdown tables, starting with "| heading | heading | heading |", followed by "| --- | --- | --- |", followed by your rows. The row with "---" is necessary for docs.microsoft.com to read the markdown as a table. +Use standard markdown tables, starting with "| heading | heading | heading |", followed by "| --- | --- | --- |", followed by your rows. The row with "---" is necessary for Microsoft Learn to read the markdown as a table. Items in the first column are bolded by default, so you don't need to do that explicitly. @@ -128,7 +138,7 @@ Markdown and HTML are ignored within inline code. ### Code blocks -Code blocks on docs.microsoft.com are delineated by with three grave accents (backticks), ```, at the beginning and the end. You do not need to indent code blocks unless they are contained within a list. +Code blocks on Microsoft Learn are delineated by with three grave accents (backticks), ```, at the beginning and the end. You do not need to indent code blocks unless they are contained within a list. The opening ``` should be followed by a language code for proper syntax coloring, such as "xml", "json", "csharp", etc. Use "cli" for command-line examples and "output" for command-line results. @@ -136,27 +146,27 @@ The only case when you should use ``` without a language tag is when creating a ### Callouts -docs.microsoft.com uses blockquotes for callouts, that is, lines starting with ">". +Microsoft Learn uses blockquotes for callouts, that is, lines starting with ">". -Callout sections with ">" only will appear with a solid gray line to the left. See [Creating NuGet packages](https://docs.microsoft.com/nuget/create-packages/creating-a-package) for examples. +Callout sections with ">" only will appear with a solid gray line to the left. See [Creating NuGet packages](https://learn.microsoft.com/nuget/create-packages/creating-a-package) for examples. You can also use one of the following callout tags on the first line that will create a shaded callout in the indicated color: | Tag | Callout use | Topic with examples | | --- | --- | --- | -| `> [!Note]` | Callouts without any special emphasis. | [Creating NuGet packages](https://docs.microsoft.com/nuget/create-packages/creating-a-package) | -| `> [!Tip]` | Callouts that share special tips and tricks or other helpful knowledge. | [Package consumption overview](https://docs.microsoft.com/nuget/consume-packages/overview-and-workflow) | -| `> [!Important]` | Callouts that describe cautions. | [NuGet.Server](https://docs.microsoft.com/nuget/hosting-packages/nuget-server) | -| `> [!Warning]` | Callouts that warn readers about situations that could cause data loss or unexpected consequences. | [Dependency resolution](https://docs.microsoft.com/nuget/consume-packages/dependency-resolution) | +| `> [!Note]` | Callouts without any special emphasis. | [Creating NuGet packages](https://learn.microsoft.com/nuget/create-packages/creating-a-package) | +| `> [!Tip]` | Callouts that share special tips and tricks or other helpful knowledge. | [Package consumption overview](https://learn.microsoft.com/nuget/consume-packages/overview-and-workflow) | +| `> [!Important]` | Callouts that describe cautions. | [NuGet.Server](https://learn.microsoft.com/nuget/hosting-packages/nuget-server) | +| `> [!Warning]` | Callouts that warn readers about situations that could cause data loss or unexpected consequences. | [Dependency resolution](https://learn.microsoft.com/nuget/consume-packages/dependency-resolution) | ### Links - In general, always use the title of the target page as the link text rather than words like "see here" or "this documentation". - Relative links to other pages in this docset should be in the form `..//.md` including the trailing `.md`. -- Links to other markdown files on docs.microsoft.com are case-insensitive (unlike links to files in GitHub, which are). +- Links to other markdown files on Microsoft Learn are case-insensitive (unlike links to files in GitHub, which are). - If you're linking to another topic in the same folder, then `..//` can be omitted. - When using anchors, always remember to include the `.md` before the `#`. -- When using external links, especially to docs.microsoft.com (or msdn.microsoft.com for any older content), omit any language tag like "en-us" so that a reader in another language lands on a target page in that same language if it's available. +- When using external links, especially to Microsoft Learn, omit any language tag like "en-us" so that a reader in another language lands on a target page in that same language if it's available. - Bare URLs are not automatically converted into links. ### Inline HTML diff --git a/docs/TOC.md b/docs/TOC.md index 05f860e63..19874212c 100644 --- a/docs/TOC.md +++ b/docs/TOC.md @@ -1,11 +1,11 @@ -# [Docs at a glance](index.md) # [What is NuGet?](what-is-nuget.md) # Get started ## [Install NuGet client tools](install-nuget-client-tools.md) ## [Install and use a package (dotnet CLI)](quickstart/install-and-use-a-package-using-the-dotnet-cli.md) ## [Install and use a package (Visual Studio)](quickstart/install-and-use-a-package-in-visual-studio.md) +## [Install and use a package (Visual Studio for Mac)](quickstart/install-and-use-a-package-in-visual-studio-mac.md) ## [Create and publish a NET Standard package (dotnet CLI)](quickstart/create-and-publish-a-package-using-the-dotnet-cli.md) -## [Create and publish a NET Standard package (Visual Studio)](quickstart/create-and-publish-a-package-using-visual-studio.md) +## [Create and publish a NET NuGet package (Visual Studio)](quickstart/create-and-publish-a-package-using-visual-studio.md) ## [Create and publish a NET Framework package (Visual Studio)](quickstart/create-and-publish-a-package-using-visual-studio-net-framework.md) # Consume packages ## [Overview and workflow](consume-packages/overview-and-workflow.md) @@ -17,59 +17,73 @@ ### [nuget.exe CLI](consume-packages/install-use-packages-nuget-cli.md) ### [Package Manager Console (PowerShell)](consume-packages/install-use-packages-powershell.md) ## Configure NuGet +### [Visual Studio options](consume-packages/nuget-visual-studio-options.md) ### Package restore options -#### [Restore options](consume-packages/package-restore.md) +#### [Restore packages](consume-packages/package-restore.md) #### [Troubleshooting](consume-packages/package-restore-troubleshooting.md) +### [Package source mapping](consume-packages/package-source-mapping.md) ### [Reinstall and update packages](consume-packages/reinstalling-and-updating-packages.md) ### [Manage global packages and cache folders](consume-packages/managing-the-global-packages-and-cache-folders.md) ### [Manage package trust boundaries](consume-packages/installing-signed-packages.md) +### [Work with authenticated Feeds](consume-packages/consuming-packages-authenticated-feeds.md) ### [Work with source control systems](consume-packages/packages-and-source-control.md) ### [Common NuGet configurations](consume-packages/configuring-nuget-behavior.md) +### [PackageDownload functionality](consume-packages/packagedownload-functionality.md) ## Reference packages in your project -### [Package references in project files](consume-packages/package-references-in-project-files.md) -### [Migrate packages.config to PackageReference](reference/migrate-packages-config-to-package-reference.md) +### [PackageReference in project files](consume-packages/package-references-in-project-files.md) +### [Migrate packages.config to PackageReference](consume-packages/migrate-packages-config-to-package-reference.md) ### [packages.config](reference/packages-config.md) +### [Central Package Management](consume-packages/Central-Package-Management.md) # Create packages ## [Overview and workflow](create-packages/overview-and-workflow.md) ## [Create a package (dotnet CLI)](create-packages/creating-a-package-dotnet-cli.md) ## [Create a package (nuget.exe CLI)](create-packages/creating-a-package.md) -## [Create a package using MSBuild](reference/msbuild-targets.md) -## [Support multiple target frameworks in your project file](create-packages/multiple-target-frameworks-project-file.md) +## [Create a package (MSBuild)](create-packages/creating-a-package-msbuild.md) +## [Package authoring best practices](create-packages/Package-authoring-best-practices.md) ## [Build a prerelease package](create-packages/prerelease-packages.md) ## [Create a symbol package](create-packages/symbol-packages-snupkg.md) +## [Support multiple target frameworks in your project file](create-packages/multiple-target-frameworks-project-file.md) ## Advanced tasks ### [Support multiple target frameworks](create-packages/supporting-multiple-target-frameworks.md) ### [Modify source code and config files](create-packages/source-and-config-file-transformations.md) ### [Select assemblies referenced by projects](create-packages/select-assemblies-referenced-by-projects.md) ### [Set package type](create-packages/set-package-type.md) ### [Create a localized package](create-packages/creating-localized-packages.md) +### [.NET Packages containing native libraries](create-packages/native-files-in-net-packages.md) ## Guides for specific content -### [Create a UWP package](guides/create-uwp-packages.md) -### [Create a native package](create-packages/native-packages.md) +### [Create a UWP package (C++)](guides/create-uwp-packages.md) +### [Create a UWP package (C#)](guides/create-uwp-packages-CS.md) +### [Create a native package](guides/native-packages.md) ### [Create UI controls as a NuGet package](guides/create-UI-controls.md) -### [Create an analyzer as a NuGet package](reference/analyzers-conventions.md) -### [Create a package for Xamarin with Visual Studio 2015](guides/create-packages-for-xamarin.md) +### [Create an analyzer as a NuGet package](guides/analyzers-conventions.md) ### [Create a package with COM interop assemblies](create-packages/author-packages-with-COM-interop-assemblies.md) ## Sign packages ### [Sign a package](create-packages/sign-a-package.md) -### [Signed package signatures and requirements](reference/signed-packages-reference.md) +### [Signed-package signatures and requirements](reference/signed-packages-reference.md) +### [Signed-package verification options](reference/Signed-Package-Verification-Options.md) # Publish packages ## Publish to NuGet.org ### [Publish a package](nuget-org/publish-a-package.md) ### [API keys](nuget-org/scoped-api-keys.md) ## Publish to a private feed ### [Overview](hosting-packages/overview.md) -### [Azure artifacts](/azure/devops/artifacts/nuget/publish?view=azure-devops) +### [Azure artifacts](/azure/devops/artifacts/nuget/publish) ### [NuGet.Server](hosting-packages/nuget-server.md) ### [Local feeds](hosting-packages/local-feeds.md) # Concepts ## [Package installation process](concepts/package-installation-process.md) -## [Package versioning](reference/package-versioning.md) -## [Dependency resolution](consume-packages/dependency-resolution.md) +## [Package versioning](concepts/package-versioning.md) +## [Dependency resolution](concepts/dependency-resolution.md) +## [Auditing package dependencies for security vulnerabilities](concepts/Auditing-Packages.md) +## [Best practices for a secure software supply chain](concepts/Security-Best-Practices.md) +## [MSBuild .props and .targets](concepts/MSBuild-props-and-targets.md) +## [Troubleshooting Installed Packages](concepts/troubleshooting-installed-packages.md) +## [MCP servers in NuGet packages](concepts/nuget-mcp.md) # Reference ## [.nuspec](reference/nuspec.md) ## [nuget.config file](reference/nuget-config-file.md) ## [Target frameworks](reference/target-frameworks.md) +## [pack and restore as MSBuild targets](reference/msbuild-targets.md) ## [dotnet CLI](reference/dotnet-Commands.md) ## [nuget.exe CLI reference](reference/nuget-exe-cli-reference.md) ### [add](reference/cli-reference/cli-ref-add.md) @@ -84,6 +98,7 @@ ### [pack](reference/cli-reference/cli-ref-pack.md) ### [push](reference/cli-reference/cli-ref-push.md) ### [restore](reference/cli-reference/cli-ref-restore.md) +### [search](reference/cli-reference/cli-ref-search.md) ### [setapikey](reference/cli-reference/cli-ref-setapikey.md) ### [sign](reference/cli-reference/cli-ref-sign.md) ### [sources](reference/cli-reference/cli-ref-sources.md) @@ -103,8 +118,9 @@ ### [Sync-Package](reference/ps-reference/ps-ref-sync-package.md) ### [Uninstall-Package](reference/ps-reference/ps-ref-uninstall-package.md) ### [Update-Package](reference/ps-reference/ps-ref-update-package.md) -## NuGet API +## NuGet Server API ### [Overview](api/overview.md) +### [Server Implementation Guide](api/implementation-guide.md) ### Resources #### [Autocomplete](api/search-autocomplete-service-resource.md) #### [Catalog](api/catalog-resource.md) @@ -113,20 +129,33 @@ #### [Package metadata](api/registration-base-url-resource.md) #### [Push and delete](api/package-publish-resource.md) #### [Push symbol packages](api/symbol-package-publish-resource.md) +#### [README URI](api/readme-template-resource.md) #### [Report abuse URL](api/report-abuse-resource.md) #### [Repository signatures](api/repository-signatures-resource.md) #### [Search](api/search-query-service-resource.md) #### [Service index](api/service-index.md) +#### [Vulnerability info](api/vulnerability-info.md) ### [How-to: query for all packages using the API](guides/api/query-for-all-published-packages.md) ### [Rate limits](api/rate-limits.md) ### [nuget.org protocols](api/nuget-protocols.md) ### [tools.json](api/tools-json.md) -## [NuGet client SDK](reference/nuget-client-sdk.md) +## [NuGet Client SDK](reference/nuget-client-sdk.md) ## [Errors and Warnings](reference/Errors-and-Warnings.md) ### [NU1000](reference/errors-and-warnings/NU1000.md) ### [NU1001](reference/errors-and-warnings/NU1001.md) ### [NU1002](reference/errors-and-warnings/NU1002.md) ### [NU1003](reference/errors-and-warnings/NU1003.md) +### [NU1004](reference/errors-and-warnings/NU1004.md) +### [NU1005](reference/errors-and-warnings/NU1005.md) +### [NU1006](reference/errors-and-warnings/NU1006.md) +### [NU1007](reference/errors-and-warnings/NU1007.md) +### [NU1008](reference/errors-and-warnings/NU1008.md) +### [NU1009](reference/errors-and-warnings/NU1009.md) +### [NU1010](reference/errors-and-warnings/NU1010.md) +### [NU1011](reference/errors-and-warnings/NU1011.md) +### [NU1012](reference/errors-and-warnings/NU1012.md) +### [NU1014](reference/errors-and-warnings/NU1014.md) +### [NU1015](reference/errors-and-warnings/NU1015.md) ### [NU1100](reference/errors-and-warnings/NU1100.md) ### [NU1101](reference/errors-and-warnings/NU1101.md) ### [NU1102](reference/errors-and-warnings/NU1102.md) @@ -136,14 +165,32 @@ ### [NU1106](reference/errors-and-warnings/NU1106.md) ### [NU1107](reference/errors-and-warnings/NU1107.md) ### [NU1108](reference/errors-and-warnings/NU1108.md) +### [NU1109](reference/errors-and-warnings/NU1109.md) +### [NU1110](reference/errors-and-warnings/NU1110.md) ### [NU1201](reference/errors-and-warnings/NU1201.md) ### [NU1202](reference/errors-and-warnings/NU1202.md) ### [NU1203](reference/errors-and-warnings/NU1203.md) +### [NU1204](reference/errors-and-warnings/NU1204.md) +### [NU1211](reference/errors-and-warnings/NU1211.md) +### [NU1212](reference/errors-and-warnings/NU1212.md) +### [NU1213](reference/errors-and-warnings/NU1213.md) +### [NU1301](reference/errors-and-warnings/NU1301.md) +### [NU1302](reference/errors-and-warnings/NU1302.md) ### [NU1401](reference/errors-and-warnings/NU1401.md) +### [NU1402](reference/errors-and-warnings/NU1402.md) +### [NU1403](reference/errors-and-warnings/NU1403.md) ### [NU1500](reference/errors-and-warnings/NU1500.md) ### [NU1501](reference/errors-and-warnings/NU1501.md) ### [NU1502](reference/errors-and-warnings/NU1502.md) ### [NU1503](reference/errors-and-warnings/NU1503.md) +### [NU1504](reference/errors-and-warnings/NU1504.md) +### [NU1505](reference/errors-and-warnings/NU1505.md) +### [NU1506](reference/errors-and-warnings/NU1506.md) +### [NU1507](reference/errors-and-warnings/NU1507.md) +### [NU1508](reference/errors-and-warnings/NU1508.md) +### [NU1509](reference/errors-and-warnings/NU1509.md) +### [NU1510](reference/errors-and-warnings/NU1510.md) +### [NU1511](reference/errors-and-warnings/NU1511.md) ### [NU1601](reference/errors-and-warnings/NU1601.md) ### [NU1602](reference/errors-and-warnings/NU1602.md) ### [NU1603](reference/errors-and-warnings/NU1603.md) @@ -151,7 +198,17 @@ ### [NU1605](reference/errors-and-warnings/NU1605.md) ### [NU1608](reference/errors-and-warnings/NU1608.md) ### [NU1701](reference/errors-and-warnings/NU1701.md) +### [NU1702](reference/errors-and-warnings/NU1702.md) +### [NU1703](reference/errors-and-warnings/NU1703.md) +### [NU1900](reference/errors-and-warnings/NU1900.md) +### [NU1901](reference/errors-and-warnings/NU1901-NU1904.md) +### [NU1902](reference/errors-and-warnings/NU1901-NU1904.md) +### [NU1903](reference/errors-and-warnings/NU1901-NU1904.md) +### [NU1904](reference/errors-and-warnings/NU1901-NU1904.md) +### [NU1905](reference/errors-and-warnings/NU1905.md) ### [NU1801](reference/errors-and-warnings/NU1801.md) +### [NU1802](reference/errors-and-warnings/NU1802.md) +### [NU1803](reference/errors-and-warnings/NU1803.md) ### [NU3000](reference/errors-and-warnings/NU3000.md) ### [NU3001](reference/errors-and-warnings/NU3001.md) ### [NU3002](reference/errors-and-warnings/NU3002.md) @@ -192,6 +249,8 @@ ### [NU3037](reference/errors-and-warnings/NU3037.md) ### [NU3038](reference/errors-and-warnings/NU3038.md) ### [NU3040](reference/errors-and-warnings/NU3040.md) +### [NU3042](reference/errors-and-warnings/NU3042.md) +### [NU3043](reference/errors-and-warnings/NU3043.md) ### [NU5000](reference/errors-and-warnings/NU5000.md) ### [NU5001](reference/errors-and-warnings/NU5001.md) ### [NU5002](reference/errors-and-warnings/NU5002.md) @@ -228,6 +287,13 @@ ### [NU5034](reference/errors-and-warnings/NU5034.md) ### [NU5035](reference/errors-and-warnings/NU5035.md) ### [NU5036](reference/errors-and-warnings/NU5036.md) +### [NU5037](reference/errors-and-warnings/NU5037.md) +### [NU5042](reference/errors-and-warnings/NU5042.md) +### [NU5045](reference/errors-and-warnings/NU5045.md) +### [NU5046](reference/errors-and-warnings/NU5046.md) +### [NU5047](reference/errors-and-warnings/NU5047.md) +### [NU5048](reference/errors-and-warnings/NU5048.md) +### [NU5049](reference/errors-and-warnings/NU5049.md) ### [NU5100](reference/errors-and-warnings/NU5100.md) ### [NU5101](reference/errors-and-warnings/NU5101.md) ### [NU5102](reference/errors-and-warnings/NU5102.md) @@ -253,7 +319,14 @@ ### [NU5123](reference/errors-and-warnings/NU5123.md) ### [NU5124](reference/errors-and-warnings/NU5124.md) ### [NU5125](reference/errors-and-warnings/NU5125.md) +### [NU5126](reference/errors-and-warnings/NU5126.md) +### [NU5127](reference/errors-and-warnings/NU5127.md) +### [NU5128](reference/errors-and-warnings/NU5128.md) +### [NU5129](reference/errors-and-warnings/NU5129.md) +### [NU5130](reference/errors-and-warnings/NU5130.md) +### [NU5131](reference/errors-and-warnings/NU5131.md) ### [NU5500](reference/errors-and-warnings/NU5500.md) +### [NU5501](reference/errors-and-warnings/NU5501.md) ## Archived content ### [project.json management format](archive/project-json.md) ### [project.json and UWP](archive/project-json-and-uwp.md) @@ -275,9 +348,36 @@ ### [NuGet.org policies](nuget-org/policies/data-requests.md) ## Release notes ### [Known Issues](release-notes/known-issues.md) + +### NuGet 6.x +#### [NuGet 6.14](release-notes/NuGet-6.14.md) +#### [NuGet 6.13](release-notes/NuGet-6.13.md) +#### [NuGet 6.12](release-notes/NuGet-6.12.md) +#### [NuGet 6.11](release-notes/NuGet-6.11.md) +#### [NuGet 6.10](release-notes/NuGet-6.10.md) +#### [NuGet 6.9](release-notes/NuGet-6.9.md) +#### [NuGet 6.8](release-notes/NuGet-6.8.md) +#### [NuGet 6.7](release-notes/NuGet-6.7.md) +#### [NuGet 6.6](release-notes/NuGet-6.6.md) +#### [NuGet 6.5](release-notes/NuGet-6.5.md) +#### [NuGet 6.4](release-notes/NuGet-6.4.md) +#### [NuGet 6.3](release-notes/NuGet-6.3.md) +#### [NuGet 6.2](release-notes/NuGet-6.2.md) +#### [NuGet 6.1](release-notes/NuGet-6.1.md) +#### [NuGet 6.0](release-notes/NuGet-6.0.md) ### NuGet 5.x -#### [NuGet 5.1 RTM](release-notes/NuGet-5.1-RTM.md) -#### [NuGet 5.0 RTM](release-notes/NuGet-5.0-RTM.md) +#### [NuGet 5.11](release-notes/NuGet-5.11.md) +#### [NuGet 5.10](release-notes/NuGet-5.10.md) +#### [NuGet 5.9](release-notes/NuGet-5.9.md) +#### [NuGet 5.8](release-notes/NuGet-5.8.md) +#### [NuGet 5.7](release-notes/NuGet-5.7.md) +#### [NuGet 5.6](release-notes/NuGet-5.6.md) +#### [NuGet 5.5](release-notes/NuGet-5.5.md) +#### [NuGet 5.4](release-notes/NuGet-5.4.md) +#### [NuGet 5.3](release-notes/NuGet-5.3.md) +#### [NuGet 5.2](release-notes/NuGet-5.2-RTM.md) +#### [NuGet 5.1](release-notes/NuGet-5.1-RTM.md) +#### [NuGet 5.0](release-notes/NuGet-5.0-RTM.md) ### NuGet 4.x #### [NuGet 4.9 RTM](release-notes/NuGet-4.9-RTM.md) #### [NuGet 4.8 RTM](release-notes/NuGet-4.8-RTM.md) @@ -340,6 +440,6 @@ #### [NuGet 1.3](release-notes/NuGet-1.3.md) #### [NuGet 1.2](release-notes/NuGet-1.2.md) #### [NuGet 1.1](release-notes/NuGet-1.1.md) -## [FAQs](faqs/nuget-faq.md) +## [FAQs](resources/nuget-faq.yml) ## [Project format](resources/check-project-format.md) # [NuGet.org](nuget-org/overview-nuget-org.md) diff --git a/docs/_breadcrumb/toc.yml b/docs/_breadcrumb/toc.yml index 1e7fb93cd..b7cc5248c 100644 --- a/docs/_breadcrumb/toc.yml +++ b/docs/_breadcrumb/toc.yml @@ -6,30 +6,45 @@ tocHref: /nuget/ topicHref: /nuget items: - - name: Quickstart + - name: Get started tocHref: /nuget/quickstart/ topicHref: /nuget/quickstart/install-and-use-a-package-using-the-dotnet-cli - - name: Guides - tocHref: /nuget/guides/ - topicHref: /nuget/guides/create-net-standard-packages-vs2017 - - name: Create packages - tocHref: /nuget/create-packages/ - topicHref: /nuget/create-packages/overview-and-workflow - name: Consume packages tocHref: /nuget/consume-packages/ topicHref: /nuget/consume-packages/overview-and-workflow + - name: Create packages + tocHref: /nuget/create-packages/ + topicHref: /nuget/create-packages/overview-and-workflow + - name: Guides + tocHref: /nuget/guides/ + topicHref: /nuget/guides/create-net-standard-packages-vs2017 + - name: Concepts + tocHref: /nuget/concepts/ + topicHref: /nuget/concepts/package-installation-process - name: Reference tocHref: /nuget/reference/ topicHref: /nuget/reference/nuspec + - name: API + tocHref: /nuget/api/ + topicHref: /nuget/api/overview + - name: Extensibility + tocHref: /nuget/reference/extensibility + topicHref: /nuget/reference/extensibility/nuget-cross-platform-plugins - name: Visual Studio extensibility tocHref: /nuget/visual-studio-extensibility/ topicHref: /nuget/visual-studio-extensibility/nuget-api-in-visual-studio + - name: Publish + tocHref: /nuget/hosting-packages/ + topicHref: /nuget/hosting-packages/overview - name: Policies tocHref: /nuget/policies/ topicHref: /nuget/policies/governance - name: Release notes tocHref: /nuget/release-notes/ - topicHref: /nuget/release-notes/index + topicHref: /nuget/release-notes/known-issues + - name: Resources + tocHref: /nuget/resources/ + topicHref: /nuget/resources/nuget-faq - name: NuGet.org tocHref: /nuget/nuget-org/ topicHref: /nuget/nuget-org/organizations-on-nuget-org diff --git a/docs/api/NuGet-Protocols.md b/docs/api/NuGet-Protocols.md index c64921739..0a027b5c2 100644 --- a/docs/api/NuGet-Protocols.md +++ b/docs/api/NuGet-Protocols.md @@ -3,7 +3,7 @@ title: nuget.org Protocols description: The evolving nuget.org protocols to interact with NuGet clients. author: anangaur ms.author: anangaur -ms.date: 10/30/2017 +ms.date: 01/21/2021 ms.topic: conceptual ms.reviewer: kraigb --- @@ -37,7 +37,9 @@ be used to validate that the package belongs to a particular user (account) on n Clients are required to pass the following header when they make API calls to **push** packages to nuget.org: - X-NuGet-Protocol-Version: 4.1.0 +``` +X-NuGet-Protocol-Version: 4.1.0 +``` Note that the `X-NuGet-Client-Version` header has similar semantics but is reserved to only be used by the official NuGet client. Third party clients should use the `X-NuGet-Protocol-Version` header and value. @@ -52,7 +54,9 @@ If a client interacts with external services and needs to validate whether a pac This API is used to get a verify-scope key for a nuget.org author to validate a package owned by him/her. - POST api/v2/package/create-verification-key/{ID}/{VERSION} +``` +POST api/v2/package/create-verification-key/{ID}/{VERSION} +``` #### Request parameters @@ -75,7 +79,9 @@ X-NuGet-ApiKey | Header | string | yes | For example, `X-NuGet-ApiKey: {USE This API is used to validate a verify-scope key for package owned by the nuget.org author. - GET api/v2/verifykey/{ID}/{VERSION} +``` +GET api/v2/verifykey/{ID}/{VERSION} +``` #### Request parameters diff --git a/docs/api/_data/catalog-package-details.json b/docs/api/_data/catalog-package-details.json index f04ecb8d0..f5cdc865e 100644 --- a/docs/api/_data/catalog-package-details.json +++ b/docs/api/_data/catalog-package-details.json @@ -28,6 +28,13 @@ "packageHash": "2edCwKLcbcgFJpsAwa883BLtOy8bZpWwbQpiIb71E74k5t2f2WzXEGWbPwntRleUEgSrcxJrh9Orm/TAmgO4NQ==", "packageHashAlgorithm": "SHA512", "packageSize": 118348, + "packageTypes": [ + { + "@id": "https://api.nuget.org/v3/catalog0/data/2015.02.01.11.18.40/windowsazure.storage.1.0.0.json#packagetypes/DotnetTool", + "@type": "PackageType", + "name": "DotnetTool" + } + ], "projectUrl": "https://github.com/NuGet/NuGetGallery", "published": "1900-01-01T00:00:00Z", "requireLicenseAcceptance": false, @@ -56,7 +63,8 @@ "id": "WebApi.All", "range": "[0.5.0, )" } - ] + ], + "targetFramework": ".NETFramework4.6" } ], "tags": [ @@ -64,5 +72,13 @@ "V3", "Protocol", "Example" + ], + "vulnerabilities": [ + { + "@id": "https://api.nuget.org/v3/catalog0/data/2015.02.01.11.18.40/windowsazure.storage.1.0.0.json#vulnerability/GitHub/999", + "@type": "Vulnerability", + "advisoryUrl": "https://github.com/advisories/ABCD-1234-5678-9012", + "severity": "2" + } ] } diff --git a/docs/api/_data/package-registration-index.json b/docs/api/_data/package-registration-index.json index 59d3ae709..641dfcfa1 100644 --- a/docs/api/_data/package-registration-index.json +++ b/docs/api/_data/package-registration-index.json @@ -2,11 +2,11 @@ "count": 1, "items": [ { - "@id": "https://api.nuget.org/v3/registration3/nuget.server.core/index.json#page/3.0.0-beta/3.0.0-beta", + "@id": "https://api.nuget.org/v3/registration-sample/nuget.server.core/index.json#page/3.0.0-beta/3.0.0-beta", "count": 1, "items": [ { - "@id": "https://api.nuget.org/v3/registration3/nuget.server.core/3.0.0-beta.json", + "@id": "https://api.nuget.org/v3/registration-sample/nuget.server.core/3.0.0-beta.json", "catalogEntry": { "@id": "https://api.nuget.org/v3/catalog0/data/2017.10.05.18.41.33/nuget.server.core.3.0.0-beta.json", "authors": ".NET Foundation", @@ -18,7 +18,7 @@ "@id": "https://api.nuget.org/v3/catalog0/data/2017.10.05.18.41.33/nuget.server.core.3.0.0-beta.json#dependencygroup/nuget.core", "id": "NuGet.Core", "range": "[2.14.0, )", - "registration": "https://api.nuget.org/v3/registration3/nuget.core/index.json" + "registration": "https://api.nuget.org/v3/registration-sample/nuget.core/index.json" } ] } @@ -37,10 +37,16 @@ "summary": "", "tags": [ "" ], "title": "", - "version": "3.0.0-beta" + "version": "3.0.0-beta", + "vulnerabilities": [ + { + "advisoryUrl": "https://github.com/advisories/ABCD-1234-5678-9012", + "severity": "2" + } + ] }, "packageContent": "https://api.nuget.org/v3-flatcontainer/nuget.server.core/3.0.0-beta/nuget.server.core.3.0.0-beta.nupkg", - "registration": "https://api.nuget.org/v3/registration3/nuget.server.core/index.json" + "registration": "https://api.nuget.org/v3/registration-sample/nuget.server.core/index.json" } ], "lower": "3.0.0-beta", diff --git a/docs/api/_data/package-registration-leaf.json b/docs/api/_data/package-registration-leaf.json index 7eac0c826..ebcc2d92e 100644 --- a/docs/api/_data/package-registration-leaf.json +++ b/docs/api/_data/package-registration-leaf.json @@ -1,8 +1,8 @@ { - "@id": "https://api.nuget.org/v3/registration3/nuget.versioning/4.3.0.json", + "@id": "https://api.nuget.org/v3/registration-sample/nuget.versioning/4.3.0.json", "catalogEntry": "https://api.nuget.org/v3/catalog0/data/2017.08.11.18.24.22/nuget.versioning.4.3.0.json", "listed": true, "packageContent": "https://api.nuget.org/v3-flatcontainer/nuget.versioning/4.3.0/nuget.versioning.4.3.0.nupkg", "published": "2017-08-11T18:24:14.36+00:00", - "registration": "https://api.nuget.org/v3/registration3/nuget.versioning/index.json" + "registration": "https://api.nuget.org/v3/registration-sample/nuget.versioning/index.json" } \ No newline at end of file diff --git a/docs/api/_data/package-registration-page.json b/docs/api/_data/package-registration-page.json index 77fd6726f..3ca362518 100644 --- a/docs/api/_data/package-registration-page.json +++ b/docs/api/_data/package-registration-page.json @@ -1,11 +1,11 @@ { "count": 2, "lower": "1.0.531", - "parent": "https://api.nuget.org/v3/registration3/nuget.protocol.v3.example/index.json", + "parent": "https://api.nuget.org/v3/registration-sample/nuget.protocol.v3.example/index.json", "upper": "1.0.729-unstable", "items": [ { - "@id": "https://api.nuget.org/v3/registration3/nuget.protocol.v3.example/1.0.531.json", + "@id": "https://api.nuget.org/v3/registration-sample/nuget.protocol.v3.example/1.0.531.json", "@type": "Package", "commitId": "e0b9ca79-75b5-414f-9e3e-de9534b5cfd1", "commitTimeStamp": "2017-10-26T14:12:19.3439088Z", @@ -25,10 +25,10 @@ "version": "1.0.531" }, "packageContent": "https://api.nuget.org/v3-flatcontainer/nuget.protocol.v3.example/1.0.531/nuget.protocol.v3.example.1.0.531.nupkg", - "registration": "https://api.nuget.org/v3/registration3/nuget.protocol.v3.example/index.json" + "registration": "https://api.nuget.org/v3/registration-sample/nuget.protocol.v3.example/index.json" }, { - "@id": "https://api.nuget.org/v3/registration3/nuget.protocol.v3.example/1.0.729-unstable.json", + "@id": "https://api.nuget.org/v3/registration-sample/nuget.protocol.v3.example/1.0.729-unstable.json", "@type": "Package", "commitId": "e0b9ca79-75b5-414f-9e3e-de9534b5cfd1", "commitTimeStamp": "2017-10-26T14:12:19.3439088Z", @@ -38,7 +38,7 @@ "authors": "NuGet.org Team", "deprecation": { "reasons": [ - "HasCriticalBugs" + "CriticalBugs" ], "message": "This package is unstable and broken!", "alternatePackage": { @@ -59,7 +59,7 @@ "version": "1.0.729-Unstable" }, "packageContent": "https://api.nuget.org/v3-flatcontainer/nuget.protocol.v3.example/1.0.729-unstable/nuget.protocol.v3.example.1.0.729-unstable.nupkg", - "registration": "https://api.nuget.org/v3/registration3/nuget.protocol.v3.example/index.json" + "registration": "https://api.nuget.org/v3/registration-sample/nuget.protocol.v3.example/index.json" } ] } diff --git a/docs/api/_data/repository-signatures-index.json b/docs/api/_data/repository-signatures-index.json index 5f8ccc84d..b80fc8d76 100644 --- a/docs/api/_data/repository-signatures-index.json +++ b/docs/api/_data/repository-signatures-index.json @@ -1,5 +1,5 @@ { - "allRepositorySigned": false, + "allRepositorySigned": true, "signingCertificates": [ { "fingerprints": { @@ -10,6 +10,26 @@ "notBefore": "2018-04-10T00:00:00.0000000Z", "notAfter": "2021-04-14T12:00:00.0000000Z", "contentUrl": "https://api.nuget.org/v3-index/repository-signatures/certificates/0e5f38f57dc1bcc806d8494f4f90fbcedd988b46760709cbeec6f4219aa6157d.crt" + }, + { + "fingerprints": { + "2.16.840.1.101.3.4.2.1": "5a2901d6ada3d18260b9c6dfe2133c95d74b9eef6ae0e5dc334c8454d1477df4" + }, + "subject": "CN=NuGet.org Repository by Microsoft, O=NuGet.org Repository by Microsoft, L=Redmond, S=Washington, C=US", + "issuer": "CN=DigiCert SHA2 Assured ID Code Signing CA, OU=www.digicert.com, O=DigiCert Inc, C=US", + "notBefore": "2021-02-16T00:00:00.0000000Z", + "notAfter": "2024-05-15T23:59:59.0000000Z", + "contentUrl": "https://api.nuget.org/v3-index/repository-signatures/certificates/5a2901d6ada3d18260b9c6dfe2133c95d74b9eef6ae0e5dc334c8454d1477df4.crt" + }, + { + "fingerprints": { + "2.16.840.1.101.3.4.2.1": "1f4b311d9acc115c8dc8018b5a49e00fce6da8e2855f9f014ca6f34570bc482d" + }, + "subject": "CN=NuGet.org Repository by Microsoft, O=NuGet.org Repository by Microsoft, L=Redmond, S=Washington, C=US", + "issuer": "CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1, O=\"DigiCert, Inc.\", C=US", + "notBefore": "2024-02-23T00:00:00.0000000Z", + "notAfter": "2027-05-18T23:59:59.0000000Z", + "contentUrl": "https://api.nuget.org/v3-index/repository-signatures/certificates/1f4b311d9acc115c8dc8018b5a49e00fce6da8e2855f9f014ca6f34570bc482d.crt" } ] } \ No newline at end of file diff --git a/docs/api/_data/search-result.json b/docs/api/_data/search-result.json index 57dea6b6e..b58fbdaa4 100644 --- a/docs/api/_data/search-result.json +++ b/docs/api/_data/search-result.json @@ -2,9 +2,7 @@ "totalHits": 2, "data": [ { - "@id": "https://api.nuget.org/v3/registration3/nuget.versioning/index.json", - "@type": "Package", - "registration": "https://api.nuget.org/v3/registration3/nuget.versioning/index.json", + "registration": "https://api.nuget.org/v3/registration-sample/nuget.versioning/index.json", "id": "NuGet.Versioning", "version": "4.4.0", "description": "NuGet's implementation of Semantic Versioning.", @@ -15,33 +13,38 @@ "authors": [ "NuGet" ], "totalDownloads": 141896, "verified": true, + "packageTypes": [ + { + "name": "Dependency" + } + ], "versions": [ { "version": "3.3.0", "downloads": 50343, - "@id": "https://api.nuget.org/v3/registration3/nuget.versioning/3.3.0.json" + "@id": "https://api.nuget.org/v3/registration-sample/nuget.versioning/3.3.0.json" }, { "version": "3.4.3", "downloads": 27932, - "@id": "https://api.nuget.org/v3/registration3/nuget.versioning/3.4.3.json" + "@id": "https://api.nuget.org/v3/registration-sample/nuget.versioning/3.4.3.json" }, { "version": "4.0.0", "downloads": 63004, - "@id": "https://api.nuget.org/v3/registration3/nuget.versioning/4.0.0.json" + "@id": "https://api.nuget.org/v3/registration-sample/nuget.versioning/4.0.0.json" }, { "version": "4.4.0", "downloads": 617, - "@id": "https://api.nuget.org/v3/registration3/nuget.versioning/4.4.0.json" + "@id": "https://api.nuget.org/v3/registration-sample/nuget.versioning/4.4.0.json" } ] }, { - "@id": "https://api.nuget.org/v3/registration3/nerdbank.gitversioning/index.json", + "@id": "https://api.nuget.org/v3/registration-sample/nerdbank.gitversioning/index.json", "@type": "Package", - "registration": "https://api.nuget.org/v3/registration3/nerdbank.gitversioning/index.json", + "registration": "https://api.nuget.org/v3/registration-sample/nerdbank.gitversioning/index.json", "id": "Nerdbank.GitVersioning", "version": "2.0.41", "description": "Stamps your assemblies with semver 2.0 compliant git commit specific version information and provides NuGet versioning information as well.", @@ -57,12 +60,12 @@ { "version": "1.6.35", "downloads": 10229, - "@id": "https://api.nuget.org/v3/registration3/nerdbank.gitversioning/1.6.35.json" + "@id": "https://api.nuget.org/v3/registration-sample/nerdbank.gitversioning/1.6.35.json" }, { "version": "2.0.41", "downloads": 1677, - "@id": "https://api.nuget.org/v3/registration3/nerdbank.gitversioning/2.0.41.json" + "@id": "https://api.nuget.org/v3/registration-sample/nerdbank.gitversioning/2.0.41.json" } ] } diff --git a/docs/api/catalog-resource.md b/docs/api/catalog-resource.md index 6f78b826e..e9a347be3 100644 --- a/docs/api/catalog-resource.md +++ b/docs/api/catalog-resource.md @@ -59,7 +59,9 @@ Catalog items are always added to the catalog in a monotonically increasing, chr The following request fetches the catalog index. - GET {@id} +``` +GET {@id} +``` The catalog index is a JSON document that contains an object with the following properties: @@ -96,7 +98,9 @@ URL. ### Sample request - GET https://api.nuget.org/v3/catalog0/index.json +``` +GET https://api.nuget.org/v3/catalog0/index.json +``` ### Sample response @@ -158,7 +162,9 @@ For more details about what each type means, see the [corresponding items type]( ### Sample request - GET https://api.nuget.org/v3/catalog0/page2926.json +``` +GET https://api.nuget.org/v3/catalog0/page2926.json +``` ### Sample response @@ -196,9 +202,12 @@ version combination). A package details catalog item is produced when a package following scenarios: 1. A package is **pushed**. -1. A package is **listed**. +1. A package is **relisted**. 1. A package is **unlisted**. +1. A package is **deprecated**. +1. A package is **undeprecated**. 1. A package is **reflowed**. +1. A package's **vulnerability status** is updated. A package reflow is an administrative gesture that essentially generates a fake push of an existing package with no changes to the package itself. On nuget.org, a reflow is used after fixing a bug in one of the background jobs @@ -227,6 +236,7 @@ minClientVersion | string | no | packageHash | string | yes | The hash of the package, encoding using [standard base 64](https://tools.ietf.org/html/rfc4648#section-4) packageHashAlgorithm | string | yes | packageSize | integer | yes | The size of the package .nupkg in bytes +packageTypes | array of objects | no | The package types specified by the author. projectUrl | string | no | releaseNotes | string | no | requireLicenseAgreement | boolean | no | Assume `false` if excluded @@ -234,6 +244,7 @@ summary | string | no | tags | array of strings | no | title | string | no | verbatimVersion | string | no | The version string as it's originally found in the .nuspec +vulnerabilities | array of objects | no | The security vulnerabilities of the package The package `version` property is the full version string after normalization. This means that SemVer 2.0.0 build data can be included here. @@ -244,14 +255,34 @@ time before the catalog item's commit timestamp. The `packageHashAlgorithm` is a string defined by the server implementation representing the hashing algorithm used to produce the `packageHash`. nuget.org always used the `packageHashAlgorithm` value of `SHA512`. +The `packageTypes` property will only be present if a package type was specified by the author. If it is present, it will always have at least one (1) entry. Each item in the `packageTypes` array is a JSON object with the following properties: + +Name | Type | Required | Notes +--------- | ------- | -------- | ----- +name | string | yes | The name of the package type. +version | string | no | The version of the package type. Only present if the author explicitly specified a version in the nuspec. + The `published` timestamp is the time when the package was last listed. > [!Note] > On nuget.org, the `published` value is set to the year 1900 when the package is unlisted. +#### Vulnerabilities + +An array of `vulnerability` objects. Each vulnerability has the following properties: + +Name | Type | Required | Notes +------------ | ------ | -------- | ----- +advisoryUrl | string | yes | Location of security advisory for the package +severity | string | yes | Severity of advisory: "0" = Low, "1" = Moderate, "2" = High, "3" = Critical + +If the `severity` property contains values other than those listed here, the severity of the advisory is to be treated as Low. + #### Sample request +``` GET https://api.nuget.org/v3/catalog0/data/2015.02.01.11.18.40/windowsazure.storage.1.0.0.json +``` #### Sample response @@ -279,7 +310,9 @@ item's commit timestamp. #### Sample request +``` GET https://api.nuget.org/v3/catalog0/data/2017.11.02.00.40.00/netstandard1.4_lib.1.0.0-test.json +``` #### Sample response diff --git a/docs/api/implementation-guide.md b/docs/api/implementation-guide.md new file mode 100644 index 000000000..136e545ee --- /dev/null +++ b/docs/api/implementation-guide.md @@ -0,0 +1,153 @@ +--- +title: NuGet Server Implementation Guide +description: Guidelines and recommendations to anyone implementing the NuGet Server API in their own package repository +author: zivkan +ms.author: zivkan +ms.date: 07/29/2023 +ms.topic: conceptual +--- + +# NuGet Server Implementation Guide + +In some cases, you may want to implement your own NuGet package feed. +Many [existing implementations exist](../hosting-packages/Overview.md) which allow you to host your own feed in a variety way, but the protocol between the official NuGet client software and a package feed is documented allowing you to build your own feed implementation from scratch. + +The protocol does evolve over time and this guide is aimed at those that wish to or already have implemented a NuGet package server. + +Since the initial release of the NuGet V3 protocol in 2015, NuGet has evolved to provide developers with a richer experience, and this requires package repositories to do additional work in order to provide the additional value their package consumers, beyond simply exacting metadata from hosted packages and returning the metadata in various forms. +For example, the search and package metadata endpoints contain more than just metadata found in the nupkg's nuspec file. + +Note that this guide is focused on the NuGet V3 protocol since the V2 protocol is essentially undocumented and, since 2015, the recommended protocol for NuGet client and server communication is the V3 protocol. For more information read about protocol versioning. + +## Chronology + +To assist authors of existing NuGet repositories keep up to date with NuGet's newest features, here is the chronology of the relevant features mentioned in the remainder of the document. + +|Year|Feature| +|--|--| +|2013|[A blog post explaining how to manage package owners on nuget.org](https://devblogs.microsoft.com/nuget/managing-package-owners/) clarified the owners shown on the website are the accounts that have permission to upload new versions, and therefore [the `owners` metadata in the package is ignored](#owner-field)| +|2017|[Added `verified` to `SearchQueryService` responses.](#verified-search-response-field)| +||[Semantic Versioning 2.0.0 support](#semantic-versioning-200-support) +|2018|[Embedded licenses](#embedded-files)| +|2019|[Embedded icons](#embedded-files)| +||[Package deprecation in `RegistrationBaseUrl` (package metadata resource)](#known-vulnerability-and-deprecation-data)| +|2020|[Package vulnerability information in `RegistrationsBaseUrl` (package metadata resource)](#known-vulnerability-and-deprecation-data)| +||Added `packageTypes` query parameter to `SearchQueryService` requests| +|2021|[Embedded readme](#embedded-files)| +|2023|[PreAuthenticate authenticated requests](#url-structure-for-authenticated-feeds)
[`VulnerabilityInfo` resource](#known-vulnerabilities-database-vulnerabilityinfo)| +|2025|[Enable embedded README downloads](#enable-embedded-readme-downloads)| + +## Owner field + +Consider two of the [package manifest file (`.nuspec`)](../reference/nuspec.md) fields, `` and ``. +Package authors who are packaging third-party content often put the third-party name in the `` field. +The `` field was intended to denote who published the package on a repository, and therefore who should be contacted in case of packing issues or questions. + +This was explained in [a blog post from 2013](https://devblogs.microsoft.com/nuget/managing-package-owners/), so the `` field is considered deprecated in the `.nuspec` file. +If package's manifest contain this metadata, it should be ignored. +Do not return the value of the `.nuspec` file's `` field in the `owners` property in the [search resource](./search-query-service-resource.md) or [package metadata resource](./registration-base-url-resource.md) JSON response. + +If your repository has per-package permissions, it is recommended to report the accounts that have permissions to publish new versions in the `owner` metadata for search and package metadata resources JSON responses. + +## `verified` search response field + +Visual Studio's Package Manager UI shows a blue checkmark next to packages in [search service](./search-query-service-resource.md) results, when a new field `verified` is set to `true`. + +NuGet.org uses this with package prefix data (server side data, not part of the NuGet API), so that this checkmark is only shown to customers when the account that owns the package uploaded the package. +For example, any package with prefix `microsoft.*` is verified only when the package is owned by [the Microsoft account on nuget.org](https://www.nuget.org/profiles/Microsoft). +Anyone who uploaded a package with package id starting with `microsoft.` before reserved prefixes were implemented, will not have this verified checkmark. +NuGet.org also allows prefixes not to be exclusive, so that anyone can upload a package under `Contoso.ToolWithPlugins.Community.*`, but will not get a verified checkmark. + +## Semantic Versioning 2.0.0 support + +NuGet supports [a hybrid between `System.Version` and Semantic Version](../concepts/Package-Versioning.md#where-nugetversion-diverges-from-semantic-versioning), but support for Semantic Version 2.0.0 was added in 2017. +Therefore, NuGet API resources that return versions to client versions lower than 3.6.0 must not return packages that use Semantic 2.0.0 features that are incompatible with Semantic Versioning 1.0.0. + +The most important differences between the two versions are the pre-release labels, and metadata string. +The [Semantic Versioning 1.0.0 spec](https://semver.org/spec/v1.0.0.html) provides `[0-9A-Za-z-]` as a sample Regular Expression string for the only characters allowed as part of the pre-release label, and does not support metadata strings. +The [Semantic Versioning 2.0.0 spec](https://semver.org/spec/v2.0.0.html) allows pre-release identifiers to be separated by `.` characters (and forbids a numeric identifier from having a leading zero), and additionally allows build metadata to be added following a `+`. + +In the [package metadata resource (`RegistrationsBaseUrl`)](./registration-base-url-resource.md), resource versions below 3.6.0 must only return packages that comply with .NET's `System.Version` or Semantic Versioning 1.0.0. +This means packages whose versions are only compliant with Semantic Versioning 2.0.0 are invisible to these client versions. + +Similarly, the [search query service (`SearchQueryService`)](./search-query-service-resource.md) and [autocomplete service (`SearchAutocompleteService`)](./search-autocomplete-service-resource.md) added `&semVerLevel={version}` query parameters. +When `semVerLevel` is missing, assume the value `1.0.0`. +Like the package metadata resource, packages whose version is compatible only with Semantic Versioning 2.0.0 must not be returned when the `semVerLevel` value is below 2.0.0. + +## Embedded files + +Package [icons](../reference/nuspec.md#icon), [license](../reference/nuspec.md#license), and [readme](../reference/nuspec.md#readme) files can be (and are recommended to be) embedded in the package. +These files need a URL endpoint, either extracted and put on a static file server, or a URL that dynamically extracts the files from the `.nupkg` on request, so that they can be viewed without downloading the entire `nupkg`. +If your package repository provides package browsing and viewing package details, you can use the URLs to show customers the embedded content on your website. + +Finally, the [package metadata resource](./registration-base-url-resource.md) and [search resource](./search-query-service-resource.md) must contain the hosted URL in the `iconUrl`, `licenseUrl`, and/or `readmeUrl` properties of the JSON response. +Packages (`.nupkg` files) must not be modified, as client features (lock files and signed packages) will detect modifications as the package having been tampered with. + +Note that the license could be an SPDX expression, or an embedded file (but not both). +Packages that use a license expression, when represented in search and package metadata results, can have the `licenseUrl` set to the license expression, URL encoded, and appended to the end of https://licenses.nuget.org/. +For example, https://licenses.nuget.org/Apache-2.0. +The NuGet.org server team have additional [documentation on licenses.nuget.org](../nuget-org/licenses.nuget.org.md). + +## Known vulnerability and deprecation data + +### Package Metadata Resource (`RegistrationsBaseUrl`) + +The [Package Metadata Resource](./registration-base-url-resource.md) can contain [deprecation](./registration-base-url-resource.md#package-deprecation) and [vulnerability](./registration-base-url-resource.md#vulnerabilities) information. +This allows customers browsing packages in Visual Studio's Package Manager User Interface, or equivalent in other IDEs, to be notified of important security or maintenance issues. + +If your package repository is "up-sourcing" packages from another repository, in order to mirror packages in your own feed, we recommend periodically checking the original source if there is deprecation or vulnerability data, and mirror that metadata in your own repository. +If your package repository is up-sourcing from nuget.org specifically, by keeping state of the last time you checked (a "cursor"), you can use [the `Catalog` resource](./catalog-resource.md) to efficiently check if there are any package updates for packages you're mirroring, without having to download a large number of package metadata JSON files from the upstream feed. +There is [a guide on using the catalog resource](../guides/api/query-for-all-published-packages.md) with sample code that can help you get started. + +### Known Vulnerabilities Database (`VulnerabilityInfo`) + +In order to provide high-performance vulnerability scanning during package restore, NuGet downloads the full list of known vulnerabilities from [the `VulnerabilityInfo` resource](./vulnerability-info.md). +Nuget.org provides vulnerability data for all GitHub reviewed advisories from the [GitHub Advisories database](https://github.com/advisories), which includes packages that are not hosted on nuget.org. + +If your package repository is hosting first-party packages, and you would like to provide vulnerability information to customers using your own feed, but don't yet have any disclosed package vulnerabilities, you should provide a [vulnerability index](./vulnerability-info.md#vulnerability-index) with one or more [vulnerability pages](./vulnerability-info.md#vulnerability-page) whose contents are an empty JSON array (`[]`). + +#### Reusing nuget.org's vulnerability data + +NuGet does not require that resources in the [service index](./service-index.md), or [the vulnerability index](./vulnerability-info.md#vulnerability-index), must be on the same server as the service index itself. +However, there are several reasons why some companies choose to block nuget.org at the firewall, or have on-prem feeds on a disconnected network. +To avoid connectivity issues, we recommend serving vulnerability data from your own web app, so that NuGet clients only make HTTP connections to the host the feed is installed on. + +✔️ DO cache or proxy the vulnerability pages in your own web app + +❌ DO NOT advertise api.nuget.org in your service index or vulnerability index without a configuration to turn this off. + +## `packageTypes` search query + +The .NET CLI allows searching for .NET tool packages with the `dotnet tool search` command. +This is implemented by adding a `&packageTypes={value}` query parameter to the [search query resource](./search-query-service-resource.md), that reads values from the package's `.nuspec` file `` field. + +## URL structure for authenticated feeds + +As described in [the overview of the NuGet API](./overview.md), the starting URL for all NuGet server communication is [the service index](./service-index.md). +This document contains the URLs for all other resources that NuGet clients will query. +As of NuGet 6.7 (Visual Studio & MSBuild 17.7, and .NET SDK 7.0.400), NuGet uses [.NET's `HttpClientHandler.PreAuthenticate`](/dotnet/api/system.net.http.httpclienthandler.preauthenticate), which only avoids anonymous HTTP requests when subsequent URLs are in the same virtual directory, or a subdirectory, of a URL that has previously been authenticated. +This will dramatically reduce the number of unauthenticated HTTP requests sent to the server, and therefore will reduce your server workload. + +Here are some examples: + +|URL|Will PreAuthenticate?| +|--|--| +|https://pkgs.contoso.com/nuget/v3/feed/index.json|N/A, this is the service index.| +|https://pkgs.contoso.com/nuget/v3/search|No, not in the same or sub-directory as the service index.| +|https://search.pkgs.contoso.com/nuget/v3/feed/|No, not on the same host name as the service index.| +|https://pkgs.contoso.com/nuget/v3/feed/search|Yes, in the same directory as the service index.| +|https://pkgs.contoso.com/nuget/v3/registration/|No, not in a subdirectory of the service index.| +|https://pkgs.contoso.com/nuget/v3/feed/registration/|Yes, in a subdirectory of the service index.| +|https://pkgs.contoso.com/nuget/v3/{guid}/registration/|See below| + +In the last example, the server might have a canonical (in this example a guid) name, and have one or more aliases. +If the service index request was authenticated on a non-canonical URL (the "friendly" name, in our example `feed`), then no, any requests to resources under the canonical URL will not match `HttpClientHandler`'s rules for `PreAuthenticate`. +However, if the non-canonical URL is an HTTP redirection to the canonical URL, https://pkgs.contoso.com/nuget/v3/{guid}/index.json, then this URL will be used in `HttpClientHandler`'s credential cache. +In this case, every request to the service index will have additional latency, due to the redirection. + +While NuGet's V3 API was designed to work on a static file server, the search resource is the exception that always requires a dynamic web service to process requests. +If you wish to host search, or indeed any other NuGet API resource, on different servers, in order to benefit from `HttpClientHandler`'s `PreAuthenticate`, you will need to use a reverse proxy to ensure all customer facing URLs in the service index meet the "same or subdirectory" rule. + +## Enable embedded README downloads + +A [new resource](./readme-template-resource.md) was documented for constructing a URL that can be used to download a README for a given package. This will allow client, like the Package Management UI in VS, to display the embedded README for packages which haven't been previously installed by the user. The client will construct this URL and attempt to download the README, using the response to the request to determine if a README is available. This means servers should expect multiple requests to the constructed endpoint as users navigate the PM UI. \ No newline at end of file diff --git a/docs/api/overview.md b/docs/api/overview.md index 199b32ba3..ecf2fd22c 100644 --- a/docs/api/overview.md +++ b/docs/api/overview.md @@ -1,6 +1,6 @@ --- -title: Overview of the NuGet API -description: The NuGet API is a set of HTTP endpoints that can be used to download packages, fetch metadata, publish new packages, etc. +title: Overview of the NuGet Server API +description: The NuGet Server API is a set of HTTP endpoints that can be used to download packages, fetch metadata, publish new packages, etc. author: joelverhagen ms.author: jver ms.date: 10/26/2017 @@ -8,9 +8,9 @@ ms.topic: reference ms.reviewer: kraigb --- -# NuGet API +# NuGet Server API -The NuGet API is a set of HTTP endpoints that can be used to download packages, fetch metadata, publish new packages, +The NuGet Server API is a set of HTTP endpoints that can be used to download packages, fetch metadata, publish new packages, and perform most other operations available in the official NuGet clients. This API is used by the NuGet client in Visual Studio, nuget.exe, and the .NET CLI to perform NuGet operations such as @@ -20,6 +20,8 @@ Note in some cases, nuget.org has additional requirements that are not enforced For a simple enumeration and download of available nuget.exe versions, see the [tools.json](tools-json.md) endpoint. +If you are implementing a NuGet package repository, also see [the implementation guide](./implementation-guide.md) for additional requirements and recommendations. + ## Service index The entry point for the API is a JSON document in a well known location. This document is called the **service index**. The location of the service index for nuget.org is `https://api.nuget.org/v3/index.json`. @@ -59,12 +61,14 @@ Resource name | Required [PackageBaseAddress](package-base-address-resource.md) | yes | Get package content (.nupkg). [PackageDetailsUriTemplate](package-details-template-resource.md) | no | Construct a URL to access a package details web page. [PackagePublish](package-publish-resource.md) | yes | Push and delete (or unlist) packages. +[ReadmeUriTemplate](readme-template-resource.md) | no | Construct a URL to access a package's README. [RegistrationsBaseUrl](registration-base-url-resource.md) | yes | Get package metadata. [ReportAbuseUriTemplate](report-abuse-resource.md) | no | Construct a URL to access a report abuse web page. [RepositorySignatures](repository-signatures-resource.md) | no | Get certificates used for repository signing. [SearchAutocompleteService](search-autocomplete-service-resource.md) | no | Discover package IDs and versions by substring. [SearchQueryService](search-query-service-resource.md) | yes | Filter and search for packages by keyword. [SymbolPackagePublish](symbol-package-publish-resource.md) | no | Push symbol packages. +[VulnerabilityInfo](vulnerability-info.md) | no | Packages with known vulnerabilities. In general, all non-binary data returned by a API resource are serialized using JSON. The response schema returned by each resource in the service index is defined individually for that resource. For more information about diff --git a/docs/api/package-base-address-resource.md b/docs/api/package-base-address-resource.md index ffd11c37e..56416a5d6 100644 --- a/docs/api/package-base-address-resource.md +++ b/docs/api/package-base-address-resource.md @@ -28,31 +28,33 @@ PackageBaseAddress/3.0.0 | The initial release ## Base URL The base URL for the following APIs is the value of the `@id` property associated with the aforementioned -resource `@type` value. In the following document, the placeholder base URL `{@id}` will be used. +resource `@type` value. In the following document, the placeholder base URL `{@id}` will be used. The base URL may change based on implementation or infrastructure changes within the package source so it must be dynamically fetched from the [service index](service-index.md) by the client software. ## HTTP methods -All URLs found in the registration resource support the HTTP methods `GET` and `HEAD`. +All URLs found in the package content resource support the HTTP methods `GET` and `HEAD`. ## Enumerate package versions -If the client knows a package ID and wants to discover which package versions the package source has available, the -client can construct a predictable URL to enumerate all package versions. This list is meant to be a "directory -listing" for the package content API mentioned below. +If the client knows a package ID and wants to discover which package versions the package source has available, the client can construct a predictable URL to enumerate all package versions. +Every version listed in this list must be available for download. +This list is meant to be a "directory listing" for the package content API mentioned below. > [!Note] > This list contains both listed and unlisted package versions. - GET {@id}/{LOWER_ID}/index.json +``` +GET {@id}/{LOWER_ID}/index.json +``` ### Request parameters Name | In | Type | Required | Notes -------- | ------ | ------- | -------- | ----- -LOWER_ID | URL | string | yes | The package ID, lowercase +LOWER_ID | URL | string | yes | The package ID, lowercased The `LOWER_ID` value is the desired package ID lowercased using the rules implemented by .NET's -[`System.String.ToLowerInvariant()`](/dotnet/api/system.string.tolowerinvariant?view=netstandard-2.0#System_String_ToLowerInvariant) method. +[`System.String.ToLowerInvariant()`](/dotnet/api/system.string.tolowerinvariant?view=netstandard-2.0#System_String_ToLowerInvariant&preserve-view=true) method. ### Response @@ -63,10 +65,10 @@ the following property: Name | Type | Required | Notes -------- | ---------------- | -------- | ----- -versions | array of strings | yes | The package IDs available +versions | array of strings | yes | The versions available The strings in the `versions` array are all lowercased, -[normalized NuGet version strings](../reference/package-versioning.md#normalized-version-numbers). The version +[normalized NuGet version strings](../concepts/package-versioning.md#normalized-version-numbers). The version strings do not contain any SemVer 2.0.0 build metadata. The intent is that the version strings found in this array can be used verbatim for the `LOWER_VERSION` tokens found @@ -74,7 +76,11 @@ in the following endpoints. ### Sample request - GET https://api.nuget.org/v3-flatcontainer/owin/index.json +``` +GET https://api.nuget.org/v3-flatcontainer/owin/index.json +``` + +Make sure to fetch the base URL (`https://api.nuget.org/v3-flatcontainer/` in this sample) from the service index as mentioned in the [base URL](#base-url) section. ### Sample response @@ -85,7 +91,9 @@ in the following endpoints. If the client knows a package ID and version and wants to download the package content, they only need to construct the following URL: - GET {@id}/{LOWER_ID}/{LOWER_VERSION}/{LOWER_ID}.{LOWER_VERSION}.nupkg +``` +GET {@id}/{LOWER_ID}/{LOWER_VERSION}/{LOWER_ID}.{LOWER_VERSION}.nupkg +``` ### Request parameters @@ -95,11 +103,11 @@ LOWER_ID | URL | string | yes | The package ID, lowercase LOWER_VERSION | URL | string | yes | The package version, normalized and lowercased Both `LOWER_ID` and `LOWER_VERSION` are lowercased using the rules implemented by .NET's -[`System.String.ToLowerInvariant()`](/dotnet/api/system.string.tolowerinvariant?view=netstandard-2.0#System_String_ToLowerInvariant) +[`System.String.ToLowerInvariant()`](/dotnet/api/system.string.tolowerinvariant?view=netstandard-2.0#System_String_ToLowerInvariant&preserve-view=true) method. The `LOWER_VERSION` is the desired package version normalized using NuGet's version -[normalization rules](../reference/package-versioning.md#normalized-version-numbers). This means that build metadata +[normalization rules](../concepts/package-versioning.md#normalized-version-numbers). This means that build metadata that is allowed by the SemVer 2.0.0 specification must be excluded in this case. ### Response body @@ -111,7 +119,11 @@ If the package does not exist on the package source, a 404 status code is return ### Sample request - GET https://api.nuget.org/v3-flatcontainer/newtonsoft.json/9.0.1/newtonsoft.json.9.0.1.nupkg +``` +GET https://api.nuget.org/v3-flatcontainer/newtonsoft.json/9.0.1/newtonsoft.json.9.0.1.nupkg +``` + +Make sure to fetch the base URL (`https://api.nuget.org/v3-flatcontainer/` in this sample) from the service index as mentioned in the [base URL](#base-url) section. ### Sample response @@ -122,7 +134,9 @@ The binary stream that is the .nupkg for Newtonsoft.Json 9.0.1. If the client knows a package ID and version and wants to download the package manifest, they only need to construct the following URL: - GET {@id}/{LOWER_ID}/{LOWER_VERSION}/{LOWER_ID}.nuspec +``` +GET {@id}/{LOWER_ID}/{LOWER_VERSION}/{LOWER_ID}.nuspec +``` ### Request parameters @@ -132,10 +146,10 @@ LOWER_ID | URL | string | yes | The package ID, lowercase LOWER_VERSION | URL | string | yes | The package version, normalized and lowercased Both `LOWER_ID` and `LOWER_VERSION` are lowercased using the rules implemented by .NET's -[`System.String.ToLowerInvariant()`](/dotnet/api/system.string.tolowerinvariant?view=netstandard-2.0#System_String_ToLowerInvariant) method. +[`System.String.ToLowerInvariant()`](/dotnet/api/system.string.tolowerinvariant?view=netstandard-2.0#System_String_ToLowerInvariant&preserve-view=true) method. The `LOWER_VERSION` is the desired package version normalized using NuGet's version -[normalization rules](../reference/package-versioning.md#normalized-version-numbers). This means that build metadata +[normalization rules](../concepts/package-versioning.md#normalized-version-numbers). This means that build metadata that is allowed by the SemVer 2.0.0 specification must be excluded in this case. ### Response body @@ -147,7 +161,11 @@ If the package does not exist on the package source, a 404 status code is return ### Sample request - GET https://api.nuget.org/v3-flatcontainer/newtonsoft.json/6.0.4/newtonsoft.json.nuspec +``` +GET https://api.nuget.org/v3-flatcontainer/newtonsoft.json/6.0.4/newtonsoft.json.nuspec +``` + +Make sure to fetch the base URL (`https://api.nuget.org/v3-flatcontainer/` in this sample) from the service index as mentioned in the [base URL](#base-url) section. ### Sample response diff --git a/docs/api/package-details-template-resource.md b/docs/api/package-details-template-resource.md index d2e332ef8..b2c7928f3 100644 --- a/docs/api/package-details-template-resource.md +++ b/docs/api/package-details-template-resource.md @@ -55,14 +55,18 @@ Name | Type | Required | Notes The server should accept `{id}` and `{version}` values with any casing. In addition, the server should not be sensitive to whether the version is -[normalized](https://docs.microsoft.com/en-us/nuget/reference/package-versioning#normalized-version-numbers). In other +[normalized](../concepts/package-versioning.md#normalized-version-numbers). In other words, the server should accept also accept non-normalized versions. For example, nuget.org's package details template looks like this: - https://www.nuget.org/packages/{id}/{version} +```http +https://www.nuget.org/packages/{id}/{version} +``` If the client implementation needs to display a link to the package details for NuGet.Versioning 4.3.0, it would produce the following URL and provide it to the user: - https://www.nuget.org/packages/NuGet.Versioning/4.3.0 +```http +https://www.nuget.org/packages/NuGet.Versioning/4.3.0 +``` diff --git a/docs/api/package-publish-resource.md b/docs/api/package-publish-resource.md index 1b59da972..57ffa8e46 100644 --- a/docs/api/package-publish-resource.md +++ b/docs/api/package-publish-resource.md @@ -42,7 +42,9 @@ endpoint, see below. nuget.org supports pushing new packages using the following API. If the package with the provided ID and version already exists, nuget.org will reject the push. Other package sources may support replacing an existing package. - PUT https://www.nuget.org/api/v2/package +``` +PUT https://www.nuget.org/api/v2/package +``` ### Request parameters @@ -84,7 +86,9 @@ implementations are free to interpret this signal as a hard delete, soft delete, [NuGet.Server](https://www.nuget.org/packages/NuGet.Server) (a server implementation only supporting the older V2 API) supports handling this request as either an unlist or a hard delete based on a configuration option. - DELETE https://www.nuget.org/api/v2/package/{ID}/{VERSION} +``` +DELETE https://www.nuget.org/api/v2/package/{ID}/{VERSION} +``` ### Request parameters @@ -109,7 +113,9 @@ HTTP method instead of the `DELETE` method. If the package is already listed, the request still succeeds. - POST https://www.nuget.org/api/v2/package/{ID}/{VERSION} +``` +POST https://www.nuget.org/api/v2/package/{ID}/{VERSION} +``` ### Request parameters diff --git a/docs/api/rate-limits.md b/docs/api/rate-limits.md index 854f5f127..f738504b6 100644 --- a/docs/api/rate-limits.md +++ b/docs/api/rate-limits.md @@ -36,10 +36,9 @@ The following tables list the rate limits for the NuGet.org API. ## Package search > [!Note] -> We recommend using NuGet.org's [V3 APIs](https://docs.microsoft.com/nuget/api/search-query-service-resource) for search that are performant and do not have any limit currently. For V1 and V2 search APIs, the followins limits apply: +> We recommend using NuGet.org's [V3 search APIs](search-query-service-resource.md) as it is not rate limited currently. For V1 and V2 search APIs, the following limits apply: - -| API | Limit Type | Limit Value | API usecase | +| API | Limit Type | Limit Value | API Use Case | |:---|:---|:---|:---| **GET** `/api/v1/Packages` | IP | 1000 / minute | Query NuGet package metadata via v1 OData `Packages` collection | **GET** `/api/v1/Search()` | IP | 3000 / minute | Search for NuGet packages via v1 Search endpoint | @@ -48,7 +47,15 @@ The following tables list the rate limits for the NuGet.org API. ## Package Push and Unlist -| API | Limit Type | Limit Value | API usecase | +| API | Limit Type | Limit Value | API Use Case | |:---|:---|:---|:--- | **PUT** `/api/v2/package` | API Key | 350 / hour | Upload a new NuGet package (version) via v2 push endpoint **DELETE** `/api/v2/package/{id}/{version}` | API Key | 250 / hour | Unlist a NuGet package (version) via v2 endpoint + +## nuget.org website page views + +If you are accessing the nuget.org web pages programmatically, consider investigating our documented [V3 APIs](overview.md). These endpoints allow for simpler access to package metadata and content. The V3 API has better availability and has higher performance than accessing the NuGet Gallery web pages, which are designed for web browser interaction. + +| API | Limit Type | Limit Value | API Use Case | +|:---|:---|:---|:--- | +**GET** `/package/{id}/{version}` | IP | 50 / minute | Display package (version) details page. diff --git a/docs/api/readme-template-resource.md b/docs/api/readme-template-resource.md new file mode 100644 index 000000000..565789ea7 --- /dev/null +++ b/docs/api/readme-template-resource.md @@ -0,0 +1,62 @@ +--- +title: README Uri Template, NuGet API +description: The README uri template allows clients to download the readme for a package, if available. +author: jgonz120 +ms.author: jongonza +ms.date: 1/6/2025 +ms.topic: reference +ms.reviewer: +--- + +# README Uri Template + +It is possible for a client to build a URL that can be used to download a README for a specific package. +This will enable the clients to render the package's README without downloading the entire package. + +The resource used for building this URL is the `ReadmeUriTemplate` resource found in the +[service index](service-index.md). + +## Versioning + +The following `@type` values are used: + +@type value | Notes +--------------------------------- | ----- +ReadmeUriTemplate/6.13.0 | The initial release + +## URL template + +The URL for the following API is the value of the `@id` property associated with one of the aforementioned +resource `@type` values. + +## HTTP methods + +The constructed URL must support the HTTP method `GET` + +## Construct the URL + +Given a known package ID and version, the client implementation can construct a URL to download the README. + +The value of the `@id` is a URL string containing any of the following placeholder tokens: + +### URL placeholders + +Name | Type | Required | Notes +----------- | ------- | -------- | ----- +`{lower_id}` | string | yes | The package ID, lowercased +`{lower_version}` | string | yes | The package version, lowercased + +Both `lower_id` and `lower_version` are lowercased using the rules implemented by .NET's +[`System.String.ToLowerInvariant()`](/dotnet/api/system.string.tolowerinvariant?view=netstandard-2.0#System_String_ToLowerInvariant&preserve-view=true) +method. + +The `lower_version` is the desired package version normalized using NuGet's version +[normalization rules](../concepts/package-versioning.md#normalized-version-numbers). This means that build metadata +that is allowed by the SemVer 2.0.0 specification must be excluded in this case. + +### Response body + +If the package has a readme, a 200 status code is returned. The response body will be the readme +content itself. + +If the package does not have a readme, a 404 status code is returned. diff --git a/docs/api/registration-base-url-resource.md b/docs/api/registration-base-url-resource.md index de972612e..d76d47d2f 100644 --- a/docs/api/registration-base-url-resource.md +++ b/docs/api/registration-base-url-resource.md @@ -15,7 +15,11 @@ metadata can be fetched using the `RegistrationsBaseUrl` resource found in the [ The collection of the documents found under `RegistrationsBaseUrl` are often called "registrations" or "registration blobs". The set of documents under a single `RegistrationsBaseUrl` is referred to as a "registration hive". A -registration hive contains all metadata about every package available on a package source. +registration hive contains metadata about every package available on a package source. + +> [!Note] +> The package metadata resource does not contain all metadata for packages. +> Use the [search resource](search-query-service-resource.md) to find packages' owners, downloads, or prefix reservation status. ## Versioning @@ -50,7 +54,7 @@ For more information about SemVer 2.0.0, see ## Base URL The base URL for the following APIs is the value of the `@id` property associated with the aforementioned -resource `@type` values. In the following document, the placeholder base URL `{@id}` will be used. +resource `@type` values. In the following document, the placeholder base URL `{@id}` will be used. The base URL may change based on implementation or infrastructure changes within the package source so it must be dynamically fetched from the [service index](service-index.md) by the client software. ## HTTP methods @@ -85,9 +89,12 @@ other hand, if the server implementation immediately stores registration leaves must perform more HTTP requests to get the information it needs. The heuristic that nuget.org uses is as follows: if there are 128 or more versions of a package, break the leaves -into pages of size 64. If there are less than 128 versions, inline all leaves into the registration index. +into pages of size 64. If there are less than 128 versions, inline all leaves into the registration index. Note that +this means packages with 65 to 127 versions will have two pages in the index but both pages will be inlined. - GET {@id}/{LOWER_ID}/index.json +``` +GET {@id}/{LOWER_ID}/index.json +``` ### Request parameters @@ -96,7 +103,7 @@ Name | In | Type | Required | Notes LOWER_ID | URL | string | yes | The package ID, lowercased The `LOWER_ID` value is the desired package ID lowercased using the rules implemented by .NET's -[`System.String.ToLowerInvariant()`](/dotnet/api/system.string.tolowerinvariant?view=netstandard-2.0#System_String_ToLowerInvariant) method. +[`System.String.ToLowerInvariant()`](/dotnet/api/system.string.tolowerinvariant?view=netstandard-2.0#System_String_ToLowerInvariant&preserve-view=true) method. ### Response @@ -124,9 +131,9 @@ upper | string | yes | The highest SemVer 2.0.0 version in the p The `lower` and `upper` bounds of the page object are useful when the metadata for a specific page version is needed. These bounds can be used to fetch the only registration page needed. The version strings adhere to -[NuGet's version rules](../reference/package-versioning.md). The version strings are normalized and do not include +[NuGet's version rules](../concepts/package-versioning.md). The version strings are normalized and do not include build metadata. As with all versions in the NuGet ecosystem, comparison of version strings is implemented using -[SemVer 2.0.0's version precedence rules](http://semver.org/spec/v2.0.0.html#spec-item-11). +[SemVer 2.0.0's version precedence rules](https://semver.org/spec/v2.0.0.html#spec-item-11). The `parent` property will only appear if the registration page object has the `items` property. @@ -160,24 +167,28 @@ The `catalogEntry` property in the registration leaf object has the following pr Name | Type | Required | Notes ------------------------ | -------------------------- | -------- | ----- -@id | string | yes | The URL to document used to produce this object +@id | string | yes | The URL to the document used to produce this object authors | string or array of strings | no | dependencyGroups | array of objects | no | The dependencies of the package, grouped by target framework deprecation | object | no | The deprecation associated with the package description | string | no | iconUrl | string | no | id | string | yes | The ID of the package +language | string | no | licenseUrl | string | no | licenseExpression | string | no | listed | boolean | no | Should be considered as listed if absent minClientVersion | string | no | +packageContent | string | no | Duplicate of the same property in the parent object, included only for legacy reasons projectUrl | string | no | published | string | no | A string containing a ISO 8601 timestamp of when the package was published +readmeUrl | string | no | A URL for the rendered (HTML web page) view of the package README requireLicenseAcceptance | boolean | no | summary | string | no | -tags | string or array of string | no | +tags | string or array of strings | no | title | string | no | version | string | yes | The full version string after normalization +vulnerabilities | array of objects | no | The security vulnerabilities of the package The package `version` property is the full version string after normalization. This means that SemVer 2.0.0 build data can be included here. @@ -187,7 +198,10 @@ framework. If the package has no dependencies, the `dependencyGroups` property i `dependencies` property of all groups is empty or missing. The value of the `licenseExpression` property complies with -[NuGet license expression syntax](https://docs.microsoft.com/en-us/nuget/reference/nuspec#license). +[NuGet license expression syntax](../reference/nuspec.md#license). + +> [!Note] +> On nuget.org, the `published` value is set to year 1900 when the package is unlisted. #### Package dependency group @@ -211,11 +225,11 @@ Each package dependency has the following properties: Name | Type | Required | Notes ------------ | ------ | -------- | ----- id | string | yes | The ID of the package dependency -range | object | no | The allowed [version range](../reference/package-versioning.md#version-ranges-and-wildcards) of the dependency +range | object | no | The allowed [version range](../concepts/package-versioning.md#version-ranges) of the dependency registration | string | no | The URL to the registration index for this dependency If the `range` property is excluded or an empty string, the client should default to the version range `(, )`. That is, -any version of the dependency is allowed. +any version of the dependency is allowed. The value of `*` is not allowed for the `range` property. #### Package deprecation @@ -225,7 +239,7 @@ Name | Type | Required | Notes ---------------- | ---------------- | -------- | ----- reasons | array of strings | yes | The reasons why the package was deprecated message | string | no | The additional details about this deprecation -alternatePackage | object | no | The package dependency that should be used instead +alternatePackage | object | no | The alternate package that should be used instead The `reasons` property must contain at least one string and should only contains strings from the following table: @@ -237,9 +251,31 @@ Other | The package is deprecated due to a reason not on this list If the `reasons` property contains strings that are not from the known set, they should be ignored. The strings are case-insensitive, so `legacy` should be treated the same as `Legacy`. There is no ordering restriction on the array, so the strings can arranged in any arbitrary order. Additionally, if the property contains only strings that are not from the known set, it should be treated as if it only contained the "Other" string. +#### Alternate package + +The alternate package object has the following properties: + +Name | Type | Required | Notes +------------ | ------ | -------- | ----- +id | string | yes | The ID of the alternate package +range | object | no | The allowed [version range](../concepts/package-versioning.md#version-ranges), or `*` if any version is allowed + +#### Vulnerabilities + +An array of `vulnerability` objects. Each vulnerability has the following properties: + +Name | Type | Required | Notes +------------ | ------ | -------- | ----- +advisoryUrl | string | yes | Location of security advisory for the package +severity | string | yes | Severity of advisory: "0" = Low, "1" = Moderate, "2" = High, "3" = Critical + ### Sample request - GET https://api.nuget.org/v3/registration3/nuget.server.core/index.json +``` +GET https://api.nuget.org/v3/registration-sample/nuget.server.core/index.json +``` + +Make sure to fetch the base URL (`https://api.nuget.org/v3/registration-sample/` in this sample) from the service index as mentioned in the [base URL](#base-url) section. ### Sample response @@ -251,7 +287,13 @@ fetch metadata about individual package versions. ## Registration page The registration page contains registration leaves. The URL to fetch a registration page is determined by the `@id` -property in the [registration page object](#registration-page-object) mentioned above. +property in the [registration page object](#registration-page-object) mentioned above. The URL is not meant to be +predictable and should always be discovered by means of the index document. + +> [!Warning] +> On nuget.org, the URL for the registration page document coincidentally contains the lower and upper bound of the +> page. However this assumption should never be made by a client since server implementations are free to change the +> shape of the URL as long as the index document has a valid link. When the `items` array is not provided in the registration index, an HTTP GET request of the `@id` value will return a JSON document which has an object as its root. The object has the following properties: @@ -270,7 +312,11 @@ The shape of the registration leaf objects is the same as in the registration in ## Sample request - GET https://api.nuget.org/v3/registration3/ravendb.client/page/1.0.531/1.0.729-unstable.json +``` +GET https://api.nuget.org/v3/registration-sample/ravendb.client/page/1.0.531/1.0.729-unstable.json +``` + +Make sure to fetch the base URL (`https://api.nuget.org/v3/registration-sample/` in this sample) from the service index as mentioned in the [base URL](#base-url) section. ## Sample response @@ -284,7 +330,13 @@ version may not be available in this document. Package metadata should be fetche the registration index). The URL to fetch a registration leaf is obtained from the `@id` property of a registration leaf object in either a -registration index or registration page. +registration index or registration page. As with the page document. the URL is not meant to be predictable and should +always be discovered by means of the registration page object. + +> [!Warning] +> On nuget.org, the URL for the registration leaf document coincidentally contains the package version. However this +> assumption should never be made by a client since server implementations are free to change the shape of the URL as +> long as the parent document has a valid link. The registration leaf is a JSON document with a root object with the following properties: @@ -302,7 +354,11 @@ registration | string | no | The URL to the registration index ### Sample request - GET https://api.nuget.org/v3/registration3/nuget.versioning/4.3.0.json +``` +GET https://api.nuget.org/v3/registration-sample/nuget.versioning/4.3.0.json +``` + +Make sure to fetch the base URL (`https://api.nuget.org/v3/registration-sample/` in this sample) from the service index as mentioned in the [base URL](#base-url) section. ### Sample response diff --git a/docs/api/report-abuse-resource.md b/docs/api/report-abuse-resource.md index b058dd0b6..dd052189a 100644 --- a/docs/api/report-abuse-resource.md +++ b/docs/api/report-abuse-resource.md @@ -57,9 +57,13 @@ whether the version is normalized. For example, nuget.org's report abuse template looks like this: - https://www.nuget.org/packages/{id}/{version}/ReportAbuse +``` +https://www.nuget.org/packages/{id}/{version}/ReportAbuse +``` If the client implementation needs to display a link to the report abuse form for NuGet.Versioning 4.3.0, it would produce the following URL and provide it to the user: - https://www.nuget.org/packages/NuGet.Versioning/4.3.0/ReportAbuse +``` +https://www.nuget.org/packages/NuGet.Versioning/4.3.0/ReportAbuse +``` diff --git a/docs/api/repository-signatures-resource.md b/docs/api/repository-signatures-resource.md index 4edb39e67..4d8befdd0 100644 --- a/docs/api/repository-signatures-resource.md +++ b/docs/api/repository-signatures-resource.md @@ -58,7 +58,9 @@ signing certificate list. The following request fetches the repository signatures index. - GET {@id} +``` +GET {@id} +``` The repository signature index is a JSON document that contains an object with the following properties: @@ -107,7 +109,9 @@ All hash values must be lowercase, hex-encoded string representations of the has ### Sample request - GET https://api.nuget.org/v3-index/repository-signatures/index.json +``` +GET https://api.nuget.org/v3-index/repository-signatures/5.0.0/index.json +``` ### Sample response diff --git a/docs/api/search-autocomplete-service-resource.md b/docs/api/search-autocomplete-service-resource.md index 0ccb08e62..5f8efe82a 100644 --- a/docs/api/search-autocomplete-service-resource.md +++ b/docs/api/search-autocomplete-service-resource.md @@ -22,11 +22,15 @@ The following `@type` values are used: SearchAutocompleteService | The initial release SearchAutocompleteService/3.0.0-beta | Alias of `SearchAutocompleteService` SearchAutocompleteService/3.0.0-rc | Alias of `SearchAutocompleteService` +SearchAutocompleteService/3.5.0 | Includes support for `packageType` query parameter + +### SearchAutocompleteService/3.5.0 +This version introduces support for the `packageType` query parameter, allowing filtering by author defined package types. It is fully backwards compatible with queries to `SearchAutocompleteService`. ## Base URL The base URL for the following APIs is the value of the `@id` property associated with one of the aforementioned -resource `@type` values. In the following document, the placeholder base URL `{@id}` will be used. +resource `@type` values. In the following document, the placeholder base URL `{@id}` will be used. The base URL may change based on implementation or infrastructure changes within the package source so it must be dynamically fetched from the [service index](service-index.md) by the client software. ## HTTP Methods @@ -39,7 +43,9 @@ a package typeahead feature in a user interface integrated with a NuGet package A package with only unlisted versions will not appear in the results. - GET {@id}?q={QUERY}&skip={SKIP}&take={TAKE}&prerelease={PRERELEASE}&semVerLevel={SEMVERLEVEL} +``` +GET {@id}?q={QUERY}&skip={SKIP}&take={TAKE}&prerelease={PRERELEASE}&semVerLevel={SEMVERLEVEL}&packageType={PACKAGETYPE} +``` ### Request parameters @@ -50,9 +56,10 @@ skip | URL | integer | no | The number of results to skip, for p take | URL | integer | no | The number of results to return, for pagination prerelease | URL | boolean | no | `true` or `false` determining whether to include [pre-release packages](../create-packages/prerelease-packages.md) semVerLevel | URL | string | no | A SemVer 1.0.0 version string +packageType | URL | string | no | The package type to use to filter packages (added in `SearchAutocompleteService/3.5.0`) The autocomplete query `q` is parsed in a manner that is defined by the server implementation. nuget.org supports -querying for the prefix of package ID tokens, which are pieces of the ID produced by spliting the original by camel +querying for the prefix of package ID tokens, which are pieces of the ID produced by splitting the original by camel case and symbol characters. The `skip` parameter defaults to 0. @@ -64,11 +71,15 @@ If `prerelease` is not provided, pre-release packages are excluded. The `semVerLevel` query parameter is used to opt-in to [SemVer 2.0.0 packages](https://github.com/NuGet/Home/wiki/SemVer2-support-for-nuget.org-%28server-side%29#identifying-semver-v200-packages). If this query parameter is excluded, only package IDs with SemVer 1.0.0 compatible versions will be returned (with the -[standard NuGet versioning](../reference/package-versioning.md) caveats, such as version strings with 4 integer pieces). +[standard NuGet versioning](../concepts/package-versioning.md) caveats, such as version strings with 4 integer pieces). If `semVerLevel=2.0.0` is provided, both SemVer 1.0.0 and SemVer 2.0.0 compatible packages will be returned. See the [SemVer 2.0.0 support for nuget.org](https://github.com/NuGet/Home/wiki/SemVer2-support-for-nuget.org-%28server-side%29) for more information. +The `packageType` parameter is used to further filter the autocomplete results to only packages that have at least one package type matching the package type name. +If the provided package type is not a valid package type as defined by the [Package Type document](https://github.com/NuGet/Home/wiki/Package-Type-%5BPacking%5D), an empty result will returned. +If the provided package type is empty, no filter will be applied. In other words, passing no value to the `packageType` parameter will behave as if the parameter was not passed. + ### Response The response is JSON document containing up to `take` autocomplete results. @@ -82,7 +93,11 @@ data | array of strings | yes | The package IDs matched by the request ### Sample request - GET https://api-v2v3search-0.nuget.org/autocomplete?q=storage&prerelease=true +``` +GET https://search-sample.nuget.org/autocomplete?q=storage&prerelease=true +``` + +Make sure to fetch the base URL (`https://search-sample.nuget.org/autocomplete` in this sample) from the service index as mentioned in the [base URL](#base-url) section. ### Sample response @@ -95,7 +110,9 @@ versions for a provided package ID. A package version that is unlisted will not appear in the results. - GET {@id}?id={ID}&prerelease={PRERELEASE}&semVerLevel={SEMVERLEVEL} +``` +GET {@id}?id={ID}&prerelease={PRERELEASE}&semVerLevel={SEMVERLEVEL} +``` ### Request parameters @@ -128,7 +145,9 @@ The package versions in the `data` array may contain SemVer 2.0.0 build metadata ### Sample request - GET https://api-v2v3search-0.nuget.org/autocomplete?id=nuget.protocol&prerelease=true +``` +GET https://api-v2v3search-0.nuget.org/autocomplete?id=nuget.protocol&prerelease=true +``` ### Sample response diff --git a/docs/api/search-query-service-resource.md b/docs/api/search-query-service-resource.md index 1de008ab2..e4466d5e1 100644 --- a/docs/api/search-query-service-resource.md +++ b/docs/api/search-query-service-resource.md @@ -22,11 +22,15 @@ The following `@type` values are used: SearchQueryService | The initial release SearchQueryService/3.0.0-beta | Alias of `SearchQueryService` SearchQueryService/3.0.0-rc | Alias of `SearchQueryService` +SearchQueryService/3.5.0 | Includes support for `packageType` query parameter + +### SearchQueryService/3.5.0 +This version introduces support for the `packageType` query parameter and the `packageTypes` response property, allowing filtering by author defined package types. It is fully backwards compatible with queries to `SearchQueryService`. ## Base URL The base URL for the following API is the value of the `@id` property associated with one of the aforementioned -resource `@type` values. In the following document, the placeholder base URL `{@id}` will be used. +resource `@type` values. In the following document, the placeholder base URL `{@id}` will be used. The base URL may change based on implementation or infrastructure changes within the package source so it must be dynamically fetched from the [service index](service-index.md) by the client software. ## HTTP methods @@ -41,7 +45,9 @@ package metadata fields may also be considered. An unlisted package should never appear in search results. - GET {@id}?q={QUERY}&skip={SKIP}&take={TAKE}&prerelease={PRERELEASE}&semVerLevel={SEMVERLEVEL} +``` +GET {@id}?q={QUERY}&skip={SKIP}&take={TAKE}&prerelease={PRERELEASE}&semVerLevel={SEMVERLEVEL}&packageType={PACKAGETYPE} +``` ### Request parameters @@ -52,6 +58,7 @@ skip | URL | integer | no | The number of results to skip, for p take | URL | integer | no | The number of results to return, for pagination prerelease | URL | boolean | no | `true` or `false` determining whether to include [pre-release packages](../create-packages/prerelease-packages.md) semVerLevel | URL | string | no | A SemVer 1.0.0 version string +packageType | URL | string | no | The package type to use to filter packages (added in `SearchQueryService/3.5.0`) The search query `q` is parsed in a manner that is defined by the server implementation. nuget.org supports basic filtering on a [variety of fields](../consume-packages/finding-and-choosing-packages.md#search-syntax). If no @@ -62,16 +69,23 @@ The `skip` parameter defaults to 0. The `take` parameter should be an integer greater than zero. The server implementation may impose a maximum value. +> [!Note] +> nuget.org limits the `skip` parameter to 3,000 and the `take` parameter to 1,000. + If `prerelease` is not provided, pre-release packages are excluded. The `semVerLevel` query parameter is used to opt-in to [SemVer 2.0.0 packages](https://github.com/NuGet/Home/wiki/SemVer2-support-for-nuget.org-%28server-side%29#identifying-semver-v200-packages). If this query parameter is excluded, only packages with SemVer 1.0.0 compatible versions will be returned (with the -[standard NuGet versioning](../reference/package-versioning.md) caveats, such as version strings with 4 integer pieces). +[standard NuGet versioning](../concepts/package-versioning.md) caveats, such as version strings with 4 integer pieces). If `semVerLevel=2.0.0` is provided, both SemVer 1.0.0 and SemVer 2.0.0 compatible packages will be returned. See the [SemVer 2.0.0 support for nuget.org](https://github.com/NuGet/Home/wiki/SemVer2-support-for-nuget.org-%28server-side%29) for more information. +The `packageType` parameter is used to further filter the search results to only packages that have at least one package type matching the package type name. +If the provided package type is not a valid package type as defined by the [Package Type document](https://github.com/NuGet/Home/wiki/Package-Type-%5BPacking%5D), an empty result will returned. +If the provided package type is empty, no filter will be applied. In other words, passing no value to the packageType parameter will behave as if the parameter was not passed. + ### Response The response is JSON document containing up to `take` search results. Search results are grouped by package ID. @@ -97,7 +111,7 @@ versions | array of objects | yes | All of the versions of authors | string or array of strings | no | iconUrl | string | no | licenseUrl | string | no | -owners | string or array of strings | no | +owners | string or array of strings | no | A string represents a single owner's username projectUrl | string | no | registration | string | no | The absolute URL to the associated [registration index](registration-base-url-resource.md#registration-index) summary | string | no | @@ -105,10 +119,11 @@ tags | string or array of strings | no | title | string | no | totalDownloads | integer | no | This value can be inferred by the sum of downloads in the `versions` array verified | boolean | no | A JSON boolean indicating whether the package is [verified](../nuget-org/id-prefix-reservation.md) +packageTypes | array of objects | yes | The package types defined by the package author (added in `SearchQueryService/3.5.0`) On nuget.org, a verified package is one which has a package ID matching a reserved ID prefix and owned by one of the reserved prefix's owners. For more information, see the -[documentation about ID prefix reservation](../reference/id-prefix-reservation.md). +[documentation about ID prefix reservation](../nuget-org/id-prefix-reservation.md). The metadata contained in the search result object is taken from the latest package version. Each item in the `versions` array is a JSON object with the following properties: @@ -119,9 +134,19 @@ Name | Type | Required | Notes version | string | yes | The full SemVer 2.0.0 version string of the package (could contain build metadata) downloads | integer | yes | The number of downloads for this specific package version +The `packageTypes` array will always consist of at least one (1) item. Package type for a given package ID is considered to be the package types defined by the latest version of the package with respect to the other search parameters. Each item in the `packageTypes` array is a JSON object with the following properties: + +Name | Type | Required | Notes +--------- | ------- | -------- | ----- +name | string | yes | The name of the package type. + ### Sample request - GET https://api-v2v3search-0.nuget.org/query?q=NuGet.Versioning&prerelease=false +``` +GET https://search-sample.nuget.org/query?q=NuGet.Versioning&prerelease=false&semVerLevel=2.0.0 +``` + +Make sure to fetch the base URL (`https://search-sample.nuget.org/query` in this sample) from the service index as mentioned in the [base URL](#base-url) section. ### Sample response diff --git a/docs/api/service-index.md b/docs/api/service-index.md index a5a9f5888..369bdbc16 100644 --- a/docs/api/service-index.md +++ b/docs/api/service-index.md @@ -50,7 +50,9 @@ The `@id` is a URL that must be absolute and must either have the HTTP or HTTPS The `@type` is used to identify the specific protocol to use when interacting with resource. The type of the resource is an opaque string but generally has the format: - {RESOURCE_NAME}/{RESOURCE_VERSION} +``` +{RESOURCE_NAME}/{RESOURCE_VERSION} +``` Clients are expected to hard code the `@type` values that they understand and look them up in a package source's service index. The exact `@type` values in use today are enumerated on the individual resource reference documents @@ -63,9 +65,15 @@ There is no requirement that each resource has a unique `@id` or `@type`. It is determine which resource to prefer over another. One possible implementation is that resources of the same or compatible `@type` can be used in a round-robin fashion in case of connection failure or server error. +A resource can use a different host or domain than the service index, but this may cause issues in environments with strict network rules. +In particular, if your service index adds resources that point directly to nuget.org (rather than proxying or caching through your own feed), your feed will not work where access to nuget.org is blocked. +If your feed is going to delegate particular resources to nuget.org, we recommend adding a configuration so that when your feed is deployed, the direct nuget.org reference can be removed from the service index. + ### Sample request - GET https://api.nuget.org/v3/index.json +``` +GET https://api.nuget.org/v3/index.json +``` ### Sample response diff --git a/docs/api/symbol-package-publish-resource.md b/docs/api/symbol-package-publish-resource.md index eeaaeb189..77d7106c9 100644 --- a/docs/api/symbol-package-publish-resource.md +++ b/docs/api/symbol-package-publish-resource.md @@ -1,15 +1,10 @@ --- title: Push Symbol Packages, NuGet API | Microsoft Docs -author: -- cristinamanum -- kraigb -ms.author: -- cmanu -- kraigb +author: cristinamanum +ms.author: cmanu manager: skofman ms.date: 10/30/2018 ms.topic: reference -ms.prod: nuget ms.technology: null description: The publish service allows clients to publish new symbol packages. keywords: NuGet API push symbol package @@ -43,7 +38,9 @@ The `PUT` HTTP method is supported by this resource. nuget.org supports pushing new symbol packages format ([snupkg](../create-packages/Symbol-Packages-snupkg.md)) using the following API. - PUT https://www.nuget.org/api/v2/symbolpackage +``` +PUT https://www.nuget.org/api/v2/symbolpackage +``` Symbol packages with the same ID and version can be submitted multiple times. A symbol package will be rejected in the following cases. diff --git a/docs/api/tools-json.md b/docs/api/tools-json.md index 28ac7e479..692e45b0e 100644 --- a/docs/api/tools-json.md +++ b/docs/api/tools-json.md @@ -29,11 +29,15 @@ unauthenticated HTTP requests. The endpoint can be fetched using the `GET` method: - GET https://dist.nuget.org/tools.json +``` +GET https://dist.nuget.org/tools.json +``` -The [JSON schema](http://json-schema.org/) for the endpoint is available here: +The [JSON schema](https://json-schema.org/) for the endpoint is available here: - GET https://dist.nuget.org/tools.schema.json +``` +GET https://dist.nuget.org/tools.schema.json +``` ## Response @@ -77,7 +81,9 @@ The `NuGet.CommandLine` package on nuget.org is typically only updated with `Rel ### Sample request - GET https://dist.nuget.org/tools.json +``` +GET https://dist.nuget.org/tools.json +``` ### Sample response diff --git a/docs/api/vulnerability-info.md b/docs/api/vulnerability-info.md new file mode 100644 index 000000000..abddc2eaf --- /dev/null +++ b/docs/api/vulnerability-info.md @@ -0,0 +1,128 @@ +--- +title: Vulnerability Info, NuGet API +description: The data that allows clients to check packages for known vulnerabilities. +author: zivkan +ms.author: zivkan +ms.date: 06/16/2023 +ms.topic: reference +--- + +# Vulnerability information + +NuGet client, starting from version 6.7, can download known package vulnerability information to use in scenarios such as checking packages during restore operations. +While the [package metadata resource](./registration-base-url-resource.md) also contains known vulnerability information, if an app needs to check a large number of packages for known vulnerabilities, it's much faster to download a file of known vulnerabilities and lookup locally, rather than making a large number of HTTP requests. +For example, this enables NuGet Restore to quickly check restored packages for known vulnerabilities, which historically never downloaded package details from the package metadata resource. + +The API consists of at least two files, the [vulnerability index](#vulnerability-index) and one or more [vulnerability page files](#vulnerability-page). +Known vulnerability data can be partitioned into multiple files, and the vulnerability index provides clients with information needed to cache files, and update the cache, efficiently. + +The resource used for building this URL is the `VulnerabilityInfo` resource found in the [service index](service-index.md). + +## Suggested partitioning strategy + +The pages listed in the vulnerability index should ideally be optimized to maximize caching, and therefore minimize updates to large files. +This will allow clients to minimize the frequency it needs to download updates. + +A suggested strategy for vulnerability data partitioning is to have two pages, `base.json` and `updates.json`. +The `base.json` file is updated periodically (for example once a month), and contains all known vulnerabilities at the time the file is regenerated. +The `updates.json` file should contain any new advisories published since `base.json` was last regenerated. +This will allow clients to download the large `base.json` infrequently, while the frequently changing `updates.json` file is always relatively small. + +NuGet clients combine the data from multiple files additively, and may load the files in any order. +The data file schema does not allow for modification or redaction of known vulnerability from another file. +Therefore if a server's vulnerability data source (for example the [GitHub Advisories Database](https://github.com/advisories)) modifies an existing advisory, the NuGet server must modify the page that the vulnerability information was previously reported. +One way to achieve this with the suggested partition scheme is to treat all vulnerability modifications and deletions as a trigger to regenerate the complete `base.json` file, and empty `updates.json`. + +If you intend to use nuget.org's vulnerability data in your own NuGet server implementation, you should take into consideration developers who do not have direct access to nuget.org. +[See our implementation guide for more details](./implementation-guide.md#reusing-nugetorgs-vulnerability-data). + +## Versioning + +The following `@type` values are used: + +@type value | Notes +--------------------------------- | ----- +VulnerabilityInfo/6.7.0 | The initial release + +## Vulnerability index + +The vulnerability index is a JSON array of objects with the following properties: + +Name | Type | Required | Notes +-------- | ---------| -------- | ----- +@name | string | yes | A short name for the file, used as a cache key. +@id | string | yes | The full (absolute) URL to a vulnerability data file. +@updated | string | yes | An ISO 8601 string representing the date and time the file was last updated, ideally with the UTC timezone. +comment | string | no | A optional descriptive string. + +The following restrictions apply: + +* The index must be an array of objects with between 1 and 16 items. + If the server does not have any vulnerability data (zero pages), then must remove the `VulnerabilityInfo` resource from the `ServiceIndex`. +* `@name` must be unique within the index, must be between 1 and 32 characters long, and can only use the characters `A` to `Z`, `a` to `z`, `0` to `9`, `-`, or `_`. +* `@id` must be an absolute URL, not a relative URL. + +## Vulnerability page + +Vulnerability page files are a JSON object used as a dictionary. +Property keys are the lower-case package id and property values are an array of the following object with the following properties: + +Name | Type | Required | Notes +-------- | ------- | -------- | ----- +severity | integer | yes | 0 means low, 1 means medium, 2 means high, 3 means critical. +url | string | yes | URL where users can get more information about the vulnerability. +versions | string | yes | The version range that is vulnerable, using [NuGet's version range syntax](../concepts/package-versioning.md#version-ranges). + +Package IDs (the root object's keys) must be lowercased with [`String.ToLowerInvariant`](/dotnet/api/system.string.tolowerinvariant). + +The list of known vulnerabilities for a package should be sorted in descending order of the max version of the version range, followed by descending version of the min version, followed by the ascending order of the URL. +Ranges with null min or max versions (unbounded) in a version range should be sorted to before non-null (bounded) versions. + +An empty page, one that does not provide any known vulnerabilities, must be an empty JSON array (`[]`). + +## Samples + +Here is a sample of a vulnerability index: + +```json +[ + { + "@name": "base", + "@id": "https://nuget.contoso.com/v3/vulnerabilities/3bb6b300-2f74-45bc-af06-746fd21c024b.json", + "@updated": "2023-06-01T06:14:58.4159909Z", + "comment": "The base data for vulnerability update periodically" + }, + { + "@name": "update", + "@id": "https://nuget.contoso.com/v3/vulnerabilities/ffd572cd-33f3-4372-8714-a9cab2e86b45.json", + "@updated": "2023-06-14T11:35:30.3155764Z", + "comment": "The patch data for the vulnerability. Contains all the vulnerabilities since base was last updated." + } +] +``` + +Here is a sample of a vulnerability data file: + +```json +{ + "contoso.library": [ + { + "url": "https://cve.contoso.com/advisories/1", + "severity": 1, + "versions": "(, 2.0.0)" + }, + { + "url": "https://cve.contoso.com/advisories/2", + "severity": 2, + "versions": "(1.0.0, 2.0.0)" + } + ], + "contoso.utilities": [ + { + "url": "https://cve.contoso.com/advisories/3", + "severity": 3, + "versions": "(, 1.0.0)" + } + ] +} +``` diff --git a/docs/archive/config-priority-order.md b/docs/archive/config-priority-order.md deleted file mode 100644 index ff7e66e55..000000000 --- a/docs/archive/config-priority-order.md +++ /dev/null @@ -1,29 +0,0 @@ -### Priority ordering - -It can also help to think about the "priority order" in which settings are applied, which is essentially the reverse of the processing order. For example, if a project is located in `c:\A\B\C`, then NuGet applies settings in the following priority order, meaning settings found higher up in the order win: - - (For solution-level packages only in NuGet 2.x; ignored in NuGet 3.x) - c:\A\B\C\.nuget\NuGet.Config - - (For all version of NuGet) - c:\A\B\C\NuGet.Config - c:\A\B\NuGet.Config - c:\A\NuGet.Config - c:\NuGet.Config - - configFile, if specified - - (Ignored in NuGet 3.4 and later if -configFile is used) - %AppData%\NuGet\NuGet.Config - - (NuGet 2.6 to 3.5) - %ProgramData%\NuGet\Config\{IDE}\{Version}\{SKU}\NuGet.Config - %ProgramData%\NuGet\Config\{IDE}\{Version}\NuGet.Config - %ProgramData%\NuGet\Config\{IDE}\NuGet.Config - %ProgramData%\NuGet\Config\NuGet.Config - - (NuGet 4.0+) - %ProgramFiles(x86)%\NuGet\Config\{IDE}\{Version}\{SKU}\NuGet.Config - %ProgramFiles(x86)%\NuGet\Config\{IDE}\{Version}\NuGet.Config - %ProgramFiles(x86)%\NuGet\Config\{IDE}\NuGet.Config - %ProgramFiles(x86)%\NuGet\Config\NuGet.Config \ No newline at end of file diff --git a/docs/archive/media/project-json-migrator.png b/docs/archive/media/project-json-migrator.png new file mode 100644 index 000000000..4328dfa7f Binary files /dev/null and b/docs/archive/media/project-json-migrator.png differ diff --git a/docs/archive/project-json-and-uwp.md b/docs/archive/project-json-and-uwp.md index f25a464dd..1fc741034 100644 --- a/docs/archive/project-json-and-uwp.md +++ b/docs/archive/project-json-and-uwp.md @@ -1,8 +1,8 @@ --- title: NuGet project.json file with UWP projects description: Description of how the project.json file is used to track NuGet dependencies in Universal Windows Platform (UWP) projects. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 07/17/2017 ms.topic: conceptual --- @@ -10,7 +10,10 @@ ms.topic: conceptual # project.json and UWP > [!Important] -> This content is deprecated. Projects should use either the `packages.config` or PackageReference formats. +> This content is deprecated. Projects should use the PackageReference formats. +> Learn how to [migrate your project.json project to PackageReference](./project-json.md#migrate-projectjson-to-packagereference). +> Visual Studio 2026 automatically migrates project.json at solution load time. +> [.NET 10 SDK & NuGet.exe 7.0](../release-notes/NuGet-7.0.md) do not support project.json projects. This document describes the package structure that employs features in NuGet 3+ (Visual Studio 2015 and later). The `minClientVersion` property of your `.nuspec` can be used to state that you require the features described here by setting it to 3.1. @@ -68,11 +71,13 @@ The behavior of the `lib` folder hasn't changed significantly in NuGet v3. Howev An example lib structure: - lib - ├───net40 - │ MyLibrary.dll - └───wp81 - MyLibrary.dll +``` +lib +├───net40 +│ MyLibrary.dll +└───wp81 + MyLibrary.dll +``` The `lib` folder contains assemblies that are used at runtime. For most packages a folder under `lib` for each of the target TxMs is all that is required. @@ -86,23 +91,25 @@ Mechanically, the assemblies included in the `ref` folder are the reference asse The structure of the `ref` folder is the same as `lib`, for example: - └───MyImageProcessingLib - ├───lib - │ ├───net40 - │ │ MyImageProcessingLibrary.dll - │ │ - │ ├───net451 - │ │ MyImageProcessingLibrary.dll - │ │ - │ └───win81 - │ MyImageProcessingLibrary.dll - │ - └───ref - ├───net40 - │ MyImageProcessingLibrary.dll - │ - └───portable-net451-win81 - MyImageProcessingLibrary.dll +``` +└───MyImageProcessingLib + ├───lib + │ ├───net40 + │ │ MyImageProcessingLibrary.dll + │ │ + │ ├───net451 + │ │ MyImageProcessingLibrary.dll + │ │ + │ └───win81 + │ MyImageProcessingLibrary.dll + │ + └───ref + ├───net40 + │ MyImageProcessingLibrary.dll + │ + └───portable-net451-win81 + MyImageProcessingLibrary.dll +``` In this example the assemblies in the `ref` directories would all be identical. @@ -114,27 +121,29 @@ The runtimes folder contains assemblies and native libraries required to run on The following example shows a package that has a purely managed implementation for several platforms, but uses native helpers on Windows 8 where it can call into Windows 8-specific native APIs. - └───MyLibrary - ├───lib - │ └───net40 - │ MyLibrary.dll - │ - └───runtimes - ├───win8-x64 - │ ├───lib - │ │ └───net40 - │ │ MyLibrary.dll - │ │ - │ └───native - │ MyNativeLibrary.dll - │ - └───win8-x86 - ├───lib - │ └───net40 - │ MyLibrary.dll - │ - └───native - MyNativeLibrary.dll +``` +└───MyLibrary + ├───lib + │ └───net40 + │ MyLibrary.dll + │ + └───runtimes + ├───win8-x64 + │ ├───lib + │ │ └───net40 + │ │ MyLibrary.dll + │ │ + │ └───native + │ MyNativeLibrary.dll + │ + └───win8-x86 + ├───lib + │ └───net40 + │ MyLibrary.dll + │ + └───native + MyNativeLibrary.dll +``` Given the above package the following things happen: @@ -150,23 +159,25 @@ Only a single `lib` folder is ever be picked, so if there is a runtime specific Another way to use runtimes is to ship a package that is purely a managed wrapper over a native assembly. In this scenario you create a package like the following: - └───MyLibrary - └───runtimes - ├───win8-x64 - │ ├───lib - │ │ └───net451 - │ │ MyLibrary.dll - │ │ - │ └───native - │ MyImplementation.dll - │ - └───win8-x86 - ├───lib - │ └───net451 - │ MyLibrary.dll - │ - └───native - MyImplementation.dll +``` +└───MyLibrary + └───runtimes + ├───win8-x64 + │ ├───lib + │ │ └───net451 + │ │ MyLibrary.dll + │ │ + │ └───native + │ MyImplementation.dll + │ + └───win8-x86 + ├───lib + │ └───net451 + │ MyLibrary.dll + │ + └───native + MyImplementation.dll +``` In this case there is no top-level `lib` folder as that folder as there is no implementation of this package that doesn't rely on the corresponding native assembly. If the managed assembly, `MyLibrary.dll`, was exactly the same in both of these cases then we could put it in a top level `lib` folder, but because the lack of a native assembly doesn't cause the package to fail installing if it was installed on a platform that wasn't win-x86 or win-x64 then the top level lib would be used but no native assembly would be copied. diff --git a/docs/archive/project-json-archive.md b/docs/archive/project-json-archive.md deleted file mode 100644 index 381b0e73b..000000000 --- a/docs/archive/project-json-archive.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -title: NuGet project.json archive content -description: Miscellaneous bits of project.json content removed from other areas of the NuGet documentation. -author: karann-msft -ms.author: karann -ms.date: 01/17/2018 -ms.topic: conceptual ---- - -# project.json archive - -The `project.json` management format was introduced with NuGet 3.x and used for certain project types. It was deprecated with the introduction of the PackageReference format, in which dependencies are listed directly in a project file. - -Also see: - -- [project.json schema](project-json.md) -- [project.json impact on package authors](project-json-impact.md) -- [project.json and UWP](project-json-and-uwp.md) - -## project.json management format - -*Originally in [Package restore](../what-is-nuget.md).* - -In the list of management formats: - -- [`project.json`](project-json.md): *(deprecated)* A JSON file that maintains a list of the project's dependencies with an overall package graph in an associated file, `project.lock.json`. This format is deprecated in favor of PackageReference. - -## nuget restore on Mono - -*Originally in [Install NuGet client tools](../install-nuget-client-tools.md).* - -Works with `project.json`. - -## Constraining package versions with restore - -*Originally in [Package restore](../consume-packages/package-restore.md#constrain-package-versions-with-restore).* - -- `project.json`: Specify a version range directly with the dependency's version number. For example: - - ```json - "Newtonsoft.json": "[6, 7)" - ``` - -## NuGet CLI commands - -- `nuget install` does not work with `project.json`. -- `nuget restore`: with projects using `project.json`, generates a `project.lock.json` file and a `.nuget.props` file, if needed. (Both files can be omitted from source control.) The `` argument can point a `project.json` file and has the same behavior as pointing to a `packages.config` or project file. In the priority order for package folders, `%userprofile%\.nuget\packages` is searched first when using `project.json`. -- `nuget update`: On Mono, this command does not work with projects using `project.json`. - -## Dependency resolution with PackageReference - -*Originally in [Dependency resolution](../consume-packages/dependency-resolution.md#dependency-resolution-with-packagereference).* - -The behavior of PackageReference applies also to `project.json`. NuGet restore writes the dependency graph into a file named `project.lock.json` alongside `project.json`. - -## Managing dependency assets - -*Originally in [Dependency resolution](../consume-packages/dependency-resolution.md#managing-dependency-assets).* - -When using the `project.json` format, you can control which assets from dependencies flow into the top-level project. For details, see [project.json](project-json.md). - -## Excluding references - -*Originally in [Dependency resolution](../consume-packages/dependency-resolution.md#excluding-references).* - -- `project.json`: add `"exclude" : "all"` in the dependency for PackageC: - - ```json - { - "dependencies": { - "PackageC": { - "version": "1.0.0", - "exclude": "all" - } - } - } - ``` - -## Resolving incompatible package errors - -*Originally in [Dependency resolution](../consume-packages/dependency-resolution.md#resolving-incompatible-package-errors).* - -An added means of resolving errors: - -- **Not recommended**: as a temporary solution while you work with the package author, projects targeting `netcore`, `netstandard`, and `netcoreapp` can denote other frameworks as being compatible, thereby allowing packages targeting those other frameworks to be used. See [project.json imports](project-json.md#imports) and [MSBuild restore target PackageTargetFallback](../reference/msbuild-targets.md#packagetargetfallback). This can cause unexpected behaviors, so again, it's best to resolve package incompatibilities by working with the package author on an update. - -## Target frameworks - -*Originally in [Target frameworks](../reference/target-frameworks.md).* - -- [project.json](project-json.md): The `frameworks` node specifies the framework versions that the project can be compiled against. - -## Creating a package - -*Originally in [Creating a package](../create-packages/creating-a-package.md)* - -### Setting a package type - -With .NET Core 1.x, when a DotnetCliTool package is installed, Visual Studio places the package in the `project.json` `tools` node instead of the `dependencies` node. - -Package types are set in `project.json`. - -- `project.json`: Indicate the package type within a `packOptions.packageType` property json: - - ```json - { - // ... - "packOptions": { - "packageType": "DotnetCliTool" - } - } - ``` - -### Adding targets and props for MSBuild - -*Originally in [Create .NET Standard NuGet Packages with Visual Studio 2015](../guides/create-net-standard-packages-vs2015.md).* - -When using `project.json`, targets are not added to the project but are made available through the `project.lock.json`. - -### Package versioning - -*Originally in [Package versioning](../reference/package-versioning.md).* - -When using the `project.json` format, NuGet also supports using a wildcard notation, \*, for Major, Minor, Patch, and pre-release suffix parts of the number. - -### NuGet.Config reference - -*Originally in [NuGet.Config reference](../reference/nuget-config-file.md).* - -`globalPackagesFolder` applies only to `project.json`. (Added note: also applies to PackageReference.) - -### nuspec file reference - -*Originally in [nuspec reference](../reference/nuspec.md).* - -The `` element is used instead of `` with `project.json`. - -### Package manager options control - -*Originally in [Package Manager UI reference](../consume-packages/install-use-packages-visual-studio.md).* - -Projects using `project.json` management format show only the **Show preview window** option. - -### Visual Studio Templates - -*Originally in [NuGet Packages in Visual Studio templates](../visual-studio-extensibility/visual-studio-templates.md).* - -Best practices: templates do not include a `project.json` file, and do not include or any references or content that would be added when NuGet packages are installed. \ No newline at end of file diff --git a/docs/archive/project-json-impact.md b/docs/archive/project-json-impact.md index ead94cce1..c8985f3ce 100644 --- a/docs/archive/project-json-impact.md +++ b/docs/archive/project-json-impact.md @@ -1,8 +1,8 @@ --- title: project.json impact on NuGet package authors description: Details on how the implementation of project.json in NuGet 3.x affects package authors, such as unsupported features, content, and package format. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 01/18/2018 ms.topic: conceptual --- @@ -10,7 +10,10 @@ ms.topic: conceptual # Impact of project.json when creating packages > [!Important] -> This content is deprecated. Projects should use either the `packages.config` or PackageReference formats. +> This content is deprecated. Projects should use the PackageReference formats. +> Learn how to [migrate your project.json project to PackageReference](./project-json.md#migrate-projectjson-to-packagereference). +> Visual Studio 2026 automatically migrates project.json at solution load time. +> [.NET 10 SDK & NuGet.exe 7.0](../release-notes/NuGet-7.0.md) do not support project.json projects. The `project.json` system used in NuGet 3+ affects package authors in several ways as described in the following sections. @@ -20,7 +23,7 @@ Traditional NuGet packages support a set of features that are not carried over t ### Install and uninstall scripts are ignored -The transitive restore model, described in [Dependency resolution](../consume-packages/dependency-resolution.md#dependency-resolution-with-packagereference), does not have a concept of "package install time". A package is either present or not present, but there is no consistent process that occurs when a package is installed. +The transitive restore model, described in [Dependency resolution](../concepts/dependency-resolution.md#dependency-resolution-with-packagereference), does not have a concept of "package install time". A package is either present or not present, but there is no consistent process that occurs when a package is installed. Also, install scripts were supported only in Visual Studio. Other IDEs had to mock the Visual Studio extensibility API to attempt to support such scripts, and no support was available in common editors and command-line tools. diff --git a/docs/archive/project-json.md b/docs/archive/project-json.md index 8d2833dca..6e039d251 100644 --- a/docs/archive/project-json.md +++ b/docs/archive/project-json.md @@ -1,15 +1,21 @@ --- title: project.json File Reference for NuGet description: In some project types, project.json maintains the list of NuGet packages used in the project. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 07/27/2017 ms.topic: reference --- # project.json reference -*NuGet 3.x+* +> [!Important] +> This content is deprecated. Projects should use the PackageReference formats. +> Learn how to [migrate your project.json project to PackageReference](#migrate-projectjson-to-packagereference). +> Visual Studio 2026 automatically migrates project.json at solution load time. +> [.NET 10 SDK & NuGet.exe 7.0](../release-notes/NuGet-7.0.md) do not support project.json projects. + +*NuGet 3.x* The `project.json` file maintains a list of packages used in a project, known as a package management format. It supersedes `packages.config` but is in turn superseded by [PackageReference](../consume-packages/package-references-in-project-files.md) with NuGet 4.0+. @@ -34,6 +40,38 @@ The [`project.lock.json`](#projectlockjson) file (described below) is also used } ``` +## Migrate project.json to PackageReference + +The migration between project.json and PackageReference is straightforward. + +### Automatic migration in Visual Studio 2026 + +Visual Studio 2026 and later automatically migrates project.json projects to PackageReference when you open a solution containing project.json projects. +The migration happens at solution load time: + +1. Open a solution containing project.json projects in Visual Studio 2026 or later. +1. Visual Studio automatically detects project.json files and migrates them to PackageReference format. +1. To check migration status, open the [Output Window](/visualstudio/ide/output-window) and select Show output from "Package Manager". +You should see messages like "Migrating project.json project..." followed by "Migration Succeeded" for each project. +Any errors will appear in the Error List. +1. A backup of the original project file and project.json file is created in a `Backup` folder in the root of the project directory. +1. The migration converts all package dependencies to PackageReference format in the project file. + + +### Manual migration in Visual Studio 2022 + +For Visual Studio 2022 and earlier, you can use the built-in migrator: + +1. Load the project.json project in Visual Studio. +1. Go to the solution explorer of the project.json project and find the dependencies node. +1. Right-click and select `Migrate project.json to PackageReference...` + +![Migrating from project.json to PackageReference](media/project-json-migrator.png) + +### Alternative migration methods + +Alternatively, you may use the [dotnet migrate](/dotnet/core/tools/dotnet-migrate) command-line tool, or do the migration manually by taking all of the content from the project.json file and replacing it with the equivalent [PackageReference syntax](../consume-packages/Package-References-in-Project-Files.md). + ## Dependencies Lists the NuGet package dependencies of your project in the following form: @@ -57,7 +95,7 @@ The Package id corresponds to the id of the package on nuget.org , the same as t When restoring packages, the version constraint of `"5.0.0"` implies `>= 5.0.0`. That is, if 5.0.0 is not available on the server but 5.0.1 is, NuGet installs 5.0.1 and warns you about the upgrade. NuGet otherwise picks the lowest possible version on the server matching the constraint. -See [Dependency resolution](../consume-packages/dependency-resolution.md) for more details on resolution rules. +See [Dependency resolution](../concepts/dependency-resolution.md) for more details on resolution rules. ### Managing dependency assets diff --git a/docs/archive/readme.md b/docs/archive/readme.md deleted file mode 100644 index 3b83194e7..000000000 --- a/docs/archive/readme.md +++ /dev/null @@ -1 +0,0 @@ -This folder a holding location for content being removed from the main documentation, typically material that applies to earlier versions that will likely be moved into a permanent archive location. \ No newline at end of file diff --git a/docs/concepts/Auditing-Packages.md b/docs/concepts/Auditing-Packages.md new file mode 100644 index 000000000..fff6752b3 --- /dev/null +++ b/docs/concepts/Auditing-Packages.md @@ -0,0 +1,208 @@ +--- +title: Auditing package dependencies for security vulnerabilities +description: How to audit package dependencies for security vulnerabilities and acting on security audit reports. +author: JonDouglas +ms.author: jodou +ms.topic: conceptual +ms.date: 10/01/2025 +--- + +# Auditing package dependencies for security vulnerabilities + +## About security audits + +A security audit for package managers like NuGet is a process that involves analyzing the security of the packages that are included in a software project. +This involves identifying vulnerabilities, evaluating risks, and making recommendations for improving security. +The audit can include a review of the packages themselves, as well as any dependencies and their associated risks. +The goal of the audit is to identify and mitigate any security vulnerabilities that could be exploited by attackers, such as code injection or cross-site scripting attacks. + +We also have a [blog post](https://devblogs.microsoft.com/nuget/nugetaudit-2-0-elevating-security-and-trust-in-package-management/) which discusses our recommended method for taking action when a package with a known vulnerability is found to be used by your project, and tools to help get more information. + +### Feature availability + +| NuGet | .NET SDK | Visual Studio | Feature | +|-------|----------|---------------|---------| +| [5.9](../release-notes/NuGet-5.9.md) | .NET 5 SDK (5.0.200) | N/A | [`dotnet list package --vulnerable`](#dotnet-list-package---vulnerable) | +| [6.8](../release-notes/NuGet-6.8.md) | .NET 8 SDK (8.0.100) | Visual Studio 2022 17.8 | [NuGetAudit](#running-a-security-audit-with-restore) for PackageReference | +| [6.10](../release-notes/NuGet-6.10.md) | N/A | Visual Studio 2022 17.10 | [NuGetAudit](#running-a-security-audit-with-restore) for packages.config| +| [6.11](../release-notes/NuGet-6.11.md) | .NET 8 SDK (8.0.400) | Visual Studio 2022 17.11 | [NuGetAuditSuppress](#excluding-advisories) for PackageReference | +| [6.12](../release-notes/NuGet-6.12.md) | .NET 9 SDK (9.0.100) | Visual Studio 2022 17.12 | [Audit sources](#audit-sources). [NuGetAuditSuppress](#excluding-advisories) for packages.config. | +| [7.0](../release-notes/NuGet-7.0.md) | .NET 10 SDK (10.0.100) | Visual Studio 2026 | [NuGetAuditMode default changes for .NET 10](#configuring-nuget-audit). [`dotnet package update --vulnerable`](#security-vulnerabilities-found-with-updates) | + +## Running a security audit with `restore` + +The `restore` command automatically runs when you do a common package operation such as loading a project for the first time, adding a new package, updating a package version, or removing a package from your project in your favorite IDE. +Your dependencies are checked against a list of known vulnerabilities provided by your [audit sources](#audit-sources). + +1. On the command line, navigate to your project or solution directory. +1. Run `restore` using your preferred tooling (i.e. dotnet, MSBuild, NuGet.exe, VisualStudio etc). +1. Review the warnings and address the known security vulnerabilities. + +### Configuring NuGet Audit + +Audit can be configured via MSBuild properties in a `.csproj` or MSBuild file being evaluated as part of your project. +We recommend that audit is configured at a repository level. + +| MSBuild Property | Default | Possible values | Notes | +|------------------|---------|-----------------|-------| +| NuGetAuditMode | See 1 below | `direct` and `all` | If you'd like to audit top-level dependencies only, you can set the value to `direct`. NuGetAuditMode is not applicable for packages.config projects. | +| NuGetAuditLevel | low | `low`, `moderate`, `high`, and `critical` | The minimum severity level to report. If you'd like to see `moderate`, `high`, and `critical` advisories (exclude `low`), set the value to `moderate` | +| NuGetAudit | true | `true` and `false` | If you wish to not receive security audit reports, you can opt-out of the experience entirely by setting the value to `false` | + +1. `NuGetAuditMode` defaults to `all` when a project targets `net10.0` or higher. + Otherwise `NuGetAuditMode` defaults to `direct`. + When a project multi-targets, if any one target framework selects `all`, then audit will use this value for all target frameworks. + +#### Audit Sources + +Restore downloads a server's [`VulnerabilityInfo` resource](../api/vulnerability-info.md) to check against the list of packages each project is using. +The list of sources are defined by [the `auditSources` element in NuGet.Config](../reference/nuget-config-file.md#auditsources), and [warning NU1905](#warning-codes) is raised if any of the audit sources do not provide any vulnerability info. +If `auditSources` is not defined or is cleared without adding any sources, then `packageSources` will be used and warning NU1905 is suppressed. + +Since a common mitigation for package substitution attacks is [to use a single package source that upstreams from nuget.org, so that NuGet is not configured to use nuget.org as a package source](Security-Best-Practices.md#nuget-feeds), audit sources can be used to use nuget.org (or any other source that provides vulnerability information) without also using it as a package source. + +The data source for nuget.org's vulnerability database is [GitHub Advisory Database](https://github.com/advisories?query=type%3Areviewed+ecosystem%3Anuget). +Note that the [V2 protocol is deprecated](../nuget-org/overview-nuget-org.md#api-endpoint-for-nugetorg), so if your nuget.config is still using the V2 endpoint, you must migrate to the V3 endpoint. + +```xml + + + + + + +``` + +**Note**: The table below lists features that support Audit Sources. + +| Introduced In | Feature Supporting Audit Sources | +| -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | +| [NuGet 6.12, .NET 9.0.100 SDK, and Visual Studio 2022 17.12](../release-notes/NuGet-6.12.md) | Restore | +| [NuGet 6.14, .NET 9.0.300 SDK](../release-notes/NuGet-6.14.md) | `dotnet package list --vulnerable` | +| Not yet supported | NuGet AuditSources support in the Visual Studio Package Manager UI | + +#### Excluding advisories + +You can choose to exclude specific advisories from the audit report by adding a new `NuGetAuditSuppress` MSBuild item for each advisory. +Define a `NuGetAuditSuppress` item with the `Include=` metadata set to the advisory URL you wish to suppress. + +```xml + + + +``` + +Similar to the other NuGet audit configuration properties, `NuGetAuditSuppress` items can be defined at the project or repository level. + +`NuGetAuditSuppress` is available for PackageReference projects starting from [NuGet 6.11, Visual Studio 17.11, and the .NET 8.0.400 SDK](../release-notes/NuGet-6.11.md). +It is available for packages.config from [Visual Studio 17.12 and NuGet 6.12](../release-notes/NuGet-6.12.md). + +### Warning codes + +| Warning Code | Reason | +|--------------|----------| +| [NU1900](../reference/errors-and-warnings/NU1900.md) | Error communicating with package source, while getting vulnerability information. | +| [NU1901](../reference/errors-and-warnings/NU1901-NU1904.md) | Package with low severity detected | +| [NU1902](../reference/errors-and-warnings/NU1901-NU1904.md) | Package with moderate severity detected | +| [NU1903](../reference/errors-and-warnings/NU1901-NU1904.md) | Package with high severity detected | +| [NU1904](../reference/errors-and-warnings/NU1901-NU1904.md) | Package with critical severity detected | +| [NU1905](../reference/errors-and-warnings/NU1905.md) | An audit source does not provide a vulnerability database | + +You can customize your build to treat these warnings as errors to [treat warnings as errors, or treat warnings not as errors](/dotnet/csharp/language-reference/compiler-options/errors-warnings#warningsaserrors-and-warningsnotaserrors). +For example, if you're already using `` to treat all (C#, NuGet, MSBuild, etc) warnings as errors, you can use `$(WarningsNotAsErrors);NU1901;NU1902;NU1903;NU1904` to prevent vulnerabilities discovered in the future from breaking your build. +Alternatively, if you want to keep low and moderate vulnerabilities as warnings, but treat high and critical vulnerabilities as errors, and you're not using `TreatWarningsAsErrors`, you can use `$(WarningsAsErrors);NU1903;NU1904`. + +> [!NOTE] +> MSBuild properties for message severity such as `NoWarn` and `TreatWarningsAsErrors` are not supported for packages.config projects. + +## Ensure restore audited projects + +NuGet in MSBuild 17.13 and .NET 9.0.200 added output properties `RestoreProjectCount`, `RestoreSkippedCount` and `RestoreProjectsAuditedCount` on the restore task. +This can be used to enforce that audit ran during a restore. +Note that these output properties are not available with [static graph restore](../reference/msbuild-targets.md#restoring-with-msbuild-static-graph-evaluation). + +Since MSBuild is a scripting language, this can be achieved a number of different ways, but also has the same restrictions as MSBuild has. +One example is to create a file *Directory.Solution.targets* in the same directory as your solution file, whose contents has a target similar to the following. +Note that *Directory.Build.props* is commonly used, but is imported by projects. +However, NuGet's restore target and task runs at the solution level, so needs to be in MSBuild's solution extensibility file, not the project/build file. + +```xml + + + + + +``` + +Depending on your use-case, you may wish to use condition `'$(RestoreProjectCount)' != '$([MSBuild::Add($(RestoreProjectsAuditedCount), $(RestoreSkippedCount))'` on the error message, to account for projects that restore skipped because they were already up to date. +Similarly, think about if you want this error to happen everywhere, or only in CI pipelines, and what environment variables are defined in your CI environment, and factor this into the target's condition. +Again, since MSBuild is a scripting language, you can use any of its capabilities to customize your repo however you want. +Viewing [MSBuild's metaproj](/visualstudio/msbuild/how-to-build-specific-targets-in-solutions-by-using-msbuild-exe#troubleshooting) and [binlogs](/visualstudio/msbuild/msbuild-command-line-reference#switches-for-loggers) are useful to develop and troubleshoot solution level targets. + +## `dotnet list package --vulnerable` + +Once a project is successfully restored, [`dotnet list package`](/dotnet/core/tools/dotnet-list-package) has a `--vulnerable` argument to filter the packages based on which packages have known vulnerabilities. +Note that `--include-transitive` is not default, so should be included. + +## Actions when packages with known vulnerabilities are reported + +We also have a [blog post](https://devblogs.microsoft.com/nuget/nugetaudit-2-0-elevating-security-and-trust-in-package-management/) which discusses our recommended method for taking action when a package with a known vulnerability is found to be used by your project, and tools to help get more information. + +### Security vulnerabilities found with updates + +If security vulnerabilities are found and updates are available for the package, you can either: + +- Edit the `.csproj` or other package version location (`Directory.Packages.props`) with a newer version containing a security fix. +- Use the NuGet package manager user interface in Visual Studio to update the individual package. +- Run the `dotnet package update --vulnerable` command to update all vulnerable packages in a project to the first version without known vulnerabilities. +- Run the `dotnet package update` or `dotnet package add` commands with the respective package ID to update to the latest version. Use [`dotnet add package` when using .NET 9 or earlier](/dotnet/core/whats-new/dotnet-10/sdk#more-consistent-command-order). + +#### Transitive Packages + +If a known vulnerability exists in a top-level package's transitive dependencies, you have these options: + +- Add the fixed package version as a direct package reference. **Note:** Be sure to remove this reference when a new package version update becomes available and be sure to maintain the defined attributes for the expected behavior. +- Use [Central Package Management with the transitive pinning functionality](../consume-packages/Central-Package-Management.md#transitive-pinning). +- [Suppress the advisory](#excluding-advisories) until it can be addressed. +- File an issue in the top-level package's tracker to request an update. + +### Security vulnerabilities found with no updates + +In the case that a known vulnerability exists in a package without a security fix, you can do the following. + +- Check for any mitigating factors outlined in the advisory report. +- Use a suggested package if the package is marked deprecated or is abandoned. +- If the package is open source, consider contributing a fix. +- Open an issue in the package's issue tracker. + +#### Check for mitigating factors + +Review the security advisor for any mitigating factors that may allow you to continue using the package with the vulnerability. +The vulnerability may only exist when the code is used on a specific framework, operating system, or a special function is called. + +#### Use a suggested package + +In the case that a security advisory is reported for the package you're using and the package is marked deprecated or seems abandoned, consider using any suggested alternate package the package author has declared or a package comprising of similar functionality that is maintained. + +#### Contribute a fix + +If a fix does not exist for the security advisory, you may want to suggest changes that addresses the vulnerability in a pull request on package's open source repository or contact the author through the `Contact owners` section on the NuGet.org package detail page. + +#### Open an issue + +If you do not want to fix the vulnerability or are unable to update or replace the package, open an issue in the package's issue tracker or preferred contact method. +On NuGet.org, you can navigate to the package details page and click `Report package` which will guide you to get in contact with the author. + +### No security vulnerabilities found + +If no security vulnerabilities are found, this means that packages with known vulnerabilities were not found in your package graph at the present moment of time you checked. +Since the advisory database can be updated at any time, we recommend regularly checking your `dotnet restore` output and ensuring the same in your continuous integration process. + +## Summary + +Security auditing features are crucial for maintaining the security and integrity of software projects. +These features provide you with an additional layer of protection against security vulnerabilities and ensures that you can use open source packages with confidence. diff --git a/docs/consume-packages/Dependency-Resolution.md b/docs/concepts/Dependency-Resolution.md similarity index 54% rename from docs/consume-packages/Dependency-Resolution.md rename to docs/concepts/Dependency-Resolution.md index 90a0d5282..81cb86f50 100644 --- a/docs/consume-packages/Dependency-Resolution.md +++ b/docs/concepts/Dependency-Resolution.md @@ -1,8 +1,8 @@ --- title: NuGet Package Dependency Resolution description: Details on the process through which a NuGet package's dependencies are resolved and installed in both NuGet 2.x and NuGet 3.x+. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 08/14/2017 ms.topic: conceptual --- @@ -17,19 +17,20 @@ When multiple packages have the same dependency, then the same package ID can ap ## Dependency resolution with PackageReference -When installing packages into projects using the PackageReference format, NuGet adds references to a flat package graph in the appropriate file and resolves conflicts ahead of time. This process is referred to as *transitive restore*. Reinstalling or restoring packages is then a process of downloading the packages listed in the graph, resulting in faster and more predictable builds. You can also take advantage of wildcard (floating) versions, such as 2.8.\*, avoiding expensive and error prone calls to `nuget update` on the client machines and build servers. +When installing packages into projects using the PackageReference format, NuGet adds references to a flat package graph in the appropriate file and resolves conflicts ahead of time. This process is referred to as *transitive restore*. Reinstalling or restoring packages is then a process of downloading the packages listed in the graph, resulting in faster and more predictable builds. -When the NuGet restore process runs prior to a build, it resolves dependencies first in memory, then writes the resulting graph to a file called `project.assets.json`. -The assets file is located at `MSBuildProjectExtensionsPath`, which defaults to the project's 'obj' folder. +You can also take advantage of floating versions, such as 2.8.\*, to avoid modifying the project to use the latest version of a package. When using floating versions, we recommend enabling the [lock file functionality](../consume-packages/package-references-in-project-files.md#locking-dependencies) to ensure repeatability. + +When the NuGet restore process runs prior to a build, it resolves dependencies first in memory, then writes the resulting graph to a file called `project.assets.json`. + +The assets file is located at `MSBuildProjectExtensionsPath`, which defaults to the project's 'obj' folder. MSBuild then reads this file and translates it into a set of folders where potential references can be found, and then adds them to the project tree in memory. -The lock file is temporary and should not be added to source control. It's listed by default in both `.gitignore` and `.tfignore`. See [Packages and source control](packages-and-source-control.md). +The `project.assets.json` file is temporary and should not be added to source control. It's listed by default in both `.gitignore` and `.tfignore`. See [Packages and source control](../consume-packages/packages-and-source-control.md). ### Dependency resolution rules -Transitive restore applies four main rules to resolve dependencies: lowest applicable version, floating versions, nearest-wins, and cousin dependencies. - - +Transitive restore applies four main rules to resolve dependencies: [lowest applicable version](#lowest-applicable-version), [floating versions](#floating-versions), [direct-dependency-wins](#direct-dependency-wins), and [cousin dependencies](#cousin-dependencies). #### Lowest applicable version @@ -37,60 +38,95 @@ The lowest applicable version rule restores the lowest possible version of a pac In the following figure, for example, 1.0-beta is considered lower than 1.0 so NuGet chooses the 1.0 version: -![Choosing the lowest applicable version](media/projectJson-dependency-1.png) +![Choosing the lowest applicable version](media/lowest-applicable-version-1.png) In the next figure, version 2.1 is not available on the feed but because the version constraint is >= 2.1 NuGet picks the next lowest version it can find, in this case 2.2: -![Choosing the next lowest version available on the feed](media/projectJson-dependency-2.png) +![Choosing the next lowest version available on the feed](media/lowest-applicable-version-2.png) When an application specifies an exact version number, such as 1.2, that is not available on the feed, NuGet fails with an error when attempting to install or restore the package: -![NuGet generates an error when an exact package version is not available](media/projectJson-dependency-3.png) +![NuGet generates an error when an exact package version is not available](media/lowest-applicable-version-3.png) - +#### Floating versions -#### Floating (wildcard) versions +A floating dependency version is specified with the \* character. For example, `6.0.*`. This version specification says "use the latest 6.0.x version"; `4.*` means "use the latest 4.x version." Using a floating version reduces changes to the project file, while keeping up to date with the latest version of a dependency. +Floating versions can only be specified at the project level. -A floating or wildcard dependency version is specified with the \* wildcard, as with 6.0.\*. This version specification says "use the latest 6.0.x version"; 4.\* means "use the latest 4.x version." Using a wildcard allows a dependency package to continue evolving without requiring a change to the consuming application (or package). +When using a floating version, NuGet resolves the highest version of a package that matches the version pattern, for example `6.0.*` gets the highest version of a package that starts with 6.0: -When using a wildcard, NuGet resolves the highest version of a package that matches the version pattern, for example 6.0.\* gets the highest version of a package that starts with 6.0: +![Choosing version 6.0.1 when a floating version 6.0.* is requested](media/floating-versions-1.png) -![Choosing version 6.0.1 when a floating version 6.0.* is requested](media/projectJson-dependency-4.png) +| Version | Versions present on server | Resolution | Reason | Notes | +|----------|--------------|-------------|-------------|-------------| +| * | 1.1.0
1.1.1
1.2.0
1.3.0-alpha | 1.2.0 | The highest stable version. | +| 1.1.* | 1.1.0
1.1.1
1.1.2-alpha
1.2.0-alpha | 1.1.1 | The highest stable version that respects the specified pattern.| +| \*-\* | 1.1.0
1.1.1
1.1.2-alpha
1.3.0-beta | 1.3.0-beta | The highest version including the not stable versions. | Available in Visual Studio version 16.6, NuGet version 5.6, .NET Core SDK version 3.1.300 | +| 1.1.\*-\* | 1.1.0
1.1.1
1.1.2-alpha
1.1.2-beta
1.3.0-beta | 1.1.2-beta | The highest version respecting the pattern and including the not stable versions. | Available in Visual Studio version 16.6, NuGet version 5.6, .NET Core SDK version 3.1.300 | +| 1.2.0-rc.* | 1.1.0
1.2.0-rc.1
1.2.0-rc.2
1.2.0 | 1.2.0 | Despite this being a version range with a prerelease part, stables are allowed if they match the stable part. Given that 1.2.0 > 1.2.0-rc.2, it is chosen. | | > [!Note] -> For information on the behavior of wildcards and pre-release versions, see [Package versioning](../reference/package-versioning.md#version-ranges-and-wildcards). +> Floating version resolution does not take into account whether or not a package is listed. +> Floating version resolution will be resolved locally if the conditions can be satisfied with packages in the Global Package Folder. + +#### Direct dependency wins +When the package graph for an application contains different versions of a package in the same subgraph, and one of those versions is a direct dependency in that subgraph, that version would be chosen for that subgraph and the rest will be ignored. +This behavior allows an application to override any particular package version in the dependency graph. - +In the example below, the application depends directly on Package B with a version constraint of >=2.0.0. The application also depends on Package A which in turn also depends on Package B, but with a >=1.0.0 constraint. Because the dependency on Package B 2.0.0 is direct dependency to the application in the graph, that version is used: -#### Nearest wins +![Application using the Direct dependency wins rule](media/direct-dependency-1.png) -When the package graph for an application contains different versions of the same package, NuGet chooses the package that's closest to the application in the graph and ignores all others. This behavior allows an application to override any particular package version in the dependency graph. +>[!Warning] +> The Direct dependency wins rule can result in a downgrade of the package version, thus potentially breaking other dependencies in the graph. When a package is downgraded, NuGet adds a [warning to alert the user](..\reference\errors-and-warnings\NU1605.md). -In the example below, the application depends directly on Package B with a version constraint of >=2.0. The application also depends on Package A which in turn also depends on Package B, but with a >=1.0 constraint. Because the dependency on Package B 2.0 is nearer to the application in the graph, that version is used: +This rule also results in greater efficiency with a large dependency graph. +When a closer dependency in the same subgraph has a higher version than a further one, then NuGet ignores that dependency, and NuGet also ignores all remaining dependencies on that branch of the graph. -![Application using the Nearest Wins rule](media/projectJson-dependency-5.png) +In the diagram below, for example, because Package C 2.0.0 is used, NuGet ignores any branches in that subgraph that refer to an earlier version of Package C: ->[!Warning] -> The Nearest Wins rule can result in a downgrade of the package version, thus potentially breaking other dependencies in the graph. Hence this rule is applied with a warning to alert the user. +![When NuGet ignores a package in the graph, it ignores that entire branch](media/direct-dependency-2.png) -This rule also results in greater efficiency with a large dependency graph (such as those with the BCL packages) because once a given dependency is ignored, NuGet also ignores all remaining dependencies on that branch of the graph. In the diagram below, for example, because Package C 2.0 is used, NuGet ignores any branches in the graph that refer to an older version of Package C: +Through this rule, NuGet tries to honor the intent of the package author. +In the diagram below, the author of Package A has explicitly downgraded to Package C 1.0.0 from Package C 2.0.0. -![When NuGet ignores a package in the graph, it ignores that entire branch](media/projectJson-dependency-6.png) +![When a package author explicitly downgrades, NuGet honors that.](media/direct-dependency-3.png) - +The application owner can choose to upgrade Package C to a version higher than 2.0.0, thus no further downgrading the version for Package C. In this case, no warning is raised. + +![When an application honor adds a direct dependency for a downgraded package, NuGet honors that.](media/direct-dependency-4.png) #### Cousin dependencies -When different package versions are referred to at the same distance in the graph from the application, NuGet uses the lowest version that satisfies all version requirements (as with the [lowest applicable version](#lowest-applicable-version) and [floating versions](#floating-versions) rules). In the image below, for example, version 2.0 of Package B satisfies the other >=1.0 constraint, and is thus used: +When different package versions are referred in different subgraphs in the graph from the application, NuGet uses the lowest version that satisfies all version requirements (as with the [lowest applicable version](#lowest-applicable-version) and [floating versions](#floating-versions) rules). In the image below, for example, version 2.0.0 of Package B satisfies the other >=1.0.0 constraint, and is thus used: + +![Resolving cousin dependencies using the lower version that satisfies all constraints](media/cousin-dependencies-1.png) -![Resolving cousin dependencies using the lower version that satisfies all constraints](media/projectJson-dependency-7.png) +Note that the packages do not need to be on the same distance for the cousin dependencies rule to apply. In the diagram below, Package D 2.0.0 is chosen in the Package C subgraph and Package D 3.0.0 is chosen in the subgraph of Package A. In the Application subgraph, there is no direct dependency to Package D, so the the [lowest applicable version](#lowest-applicable-version) rule is applied and version 3.0.0 is chosen. -In some cases, it's not possible to meet all version requirements. As shown below, if Package A requires exactly Package B 1.0 and Package C requires Package B >=2.0, then NuGet cannot resolve the dependencies and gives an error. +![Resolving cousin dependencies using the lower version that satisfies all constraints at different distances](media/cousin-dependencies-2.png) -![Unresolvable dependencies due to an exact version requirement](media/projectJson-dependency-8.png) +In some cases, it's not possible to meet all version requirements. As shown below, if Package A requires exactly Package B 1.0.0 and Package C requires Package B >=2.0.0, then NuGet cannot resolve the dependencies and gives an error. -In these situations, the top-level consumer (the application or package) should add its own direct dependency on Package B so that the [Nearest Wins](#nearest-wins) rule applies. +![Unresolvable dependencies due to an exact version requirement](media/cousin-dependencies-3.png) + +In these situations, the top-level consumer (the application or package) should add its own direct dependency on Package B so that the [Direct dependency wins](#direct-dependency-wins) rule applies. + +### Version ranges and prerelease versions with PackageReference + +It is not unusual for a package to have both stable and prerelease versions available. +When resolving a dependency graph, NuGet decides whether to consider prerelease versions for a package based on a single rule: +`If the project or any packages within the graph request a prerelease version of a package, then include both prerelease or stable versions, otherwise consider stable versions only.` + +In practice, under the lowest applicable rule, this means: + +| Version Range | Available versions | Selected version | +|---------------|--------------------|------------------| +| [1.0.0, 2.0.0) | 1.2.0-beta.1, 1.2.0, | 1.2.0 | +| [1.0.0, 2.0.0-0) | 1.2.0-beta.1, 1.2.0, | 1.2.0-beta.1 | +| [1.0.0, 2.0.0) | 1.2.0-beta.1, 2.0.0-beta.3 | None, [NU1103](../reference/errors-and-warnings/NU1103.md) is raised. | +| [1.0.0, 2.0.0-rc) | 1.2.0-beta.1, 2.0.0-beta.3 | 1.2.0-beta.1 | ## Dependency resolution with packages.config @@ -98,13 +134,18 @@ With `packages.config`, a project's dependencies are written to `packages.config With `packages.config`, NuGet attempts to resolve dependency conflicts during the installation of each individual package. That is, if Package A is being installed and depends on Package B, and Package B is already listed in `packages.config` as a dependency of something else, NuGet compares the versions of Package B being requested and attempts to find a version that satisfies all version constraints. Specifically, NuGet selects the lower *major.minor* version that satisfies dependencies. -By default, NuGet 2.8 looks for the lowest patch version (see [NuGet 2.8 release notes](../release-notes/nuget-2.8.md#patch-resolution-for-dependencies)). You can control this setting through the `DependencyVersion` attribute in `Nuget.Config` and the `-DependencyVersion` switch on the command line. +By default, NuGet 2.8 looks for the lowest patch version (see [NuGet 2.8 release notes](../release-notes/nuget-2.8.md#patch-resolution-for-dependencies)). You can control this setting through the `DependencyVersion` attribute in `NuGet.Config` and the `-DependencyVersion` switch on the command line. The `packages.config` process for resolving dependencies gets complicated for larger dependency graphs. Each new package installation requires a traversal of the whole graph and raises the chance for version conflicts. When a conflict occurs, installation is stopped, leaving the project in an indeterminate state, especially with potential modifications to the project file itself. This is not an issue when using other package management formats. +### Version ranges and prerelease versions with packages.config + +packages.config resolution does not allow mixing of stable and pre-release dependency in a graph. +If a dependency is expressed with a range like `[1.0.0, 2.0.0)`, pre-release packages are not allowed in the graph. + ## Managing dependency assets -When using the PackageReference format, you can control which assets from dependencies flow into the top-level project. For details, see [PackageReference](package-references-in-project-files.md#controlling-dependency-assets). +When using the PackageReference format, you can control which assets from dependencies flow into the top-level project. For details, see [PackageReference](../consume-packages/package-references-in-project-files.md#controlling-dependency-assets). When the top-level project is itself a package, you also have control over this flow by using the `include` and `exclude` attributes with dependencies listed in the `.nuspec` file. See [.nuspec Reference - Dependencies](../reference/nuspec.md#dependencies). @@ -153,3 +194,4 @@ To resolve incompatibilities, do one of the following: - Retarget your project to a framework that is supported by the packages you want to use. - Contact the author of the packages and work with them to add support for your chosen framework. Each package listing page on [nuget.org](https://www.nuget.org/) has a **Contact Owners** link for this purpose. +[!INCLUDE [nugetsolver-tool](../includes/nugetsolver-tool.md)] diff --git a/docs/concepts/MSBuild-props-and-targets.md b/docs/concepts/MSBuild-props-and-targets.md new file mode 100644 index 000000000..10e630270 --- /dev/null +++ b/docs/concepts/MSBuild-props-and-targets.md @@ -0,0 +1,78 @@ +--- +title: MSBuild props and targets in a package +description: Describes MSBuild props and targets in NuGet packages +author: nkolev92 +ms.author: nikolev +ms.date: 07/13/2022 +ms.topic: conceptual +--- + +# MSBuild .props and .targets in a package + +In additional to the more traditional assemblies, NuGet packages may sometimes add custom build targets or properties to projects that consume that package. +This can be achieved by adding a valid MSBuild file, in the form `.targets` or `.props` (such as `Contoso.Utility.UsefulStuff.targets`) within the build folders of the project. + +## Build folders + +As NuGet has evolved, various different folders for build `.props` and `.targets` have been added. + +| Folder | NuGet Version | Use | +|--------|---------------|-----| +| build | 2.5+ | Build logic for every framework of a project. | +| buildMultiTargeting | 4.0+ | Build logic for the `outer build` for projects that target multiple frameworks. PackageReference only. | +| buildTransitive | 5.0+ | Build logic for assets that flow transitively to any consuming project. See the [feature](https://github.com/NuGet/Home/wiki/Allow-package--authors-to-define-build-assets-transitive-behavior) page. PackageReference only. | + +## Framework specific build folder + +All 3 build folder follow the same pattern for deciding the most suitable file based on the project target framework. + +Files in the root build folder, `build/.targets` and `build/.props` are considered suitable for all target frameworks. + +To provide framework-specific files, first place them within appropriate subfolders, such as the following: + +```text + \build + \netstandard1.4 + \Contoso.Utility.UsefulStuff.props + \Contoso.Utility.UsefulStuff.targets + \net462 + \Contoso.Utility.UsefulStuff.props + \Contoso.Utility.UsefulStuff.targets +``` + +Prefer using framework-specific build folders whenever appropriate to avoid false positive installations in projects that may not be supported by your package. + +Note that if a package does not have any files in the `lib` or `ref` folders and only files under a framework specific build folder, that package will be considered compatible with all projects. Up to date versions of the pack tooling, raise the [NU5127](..\reference\errors-and-warnings\NU5127.md) warning when such packages are created. + +## Projects consuming packages with build files + +### PackageReference projects + +`.props` and `.targets` are not added to the project file but are instead made available through `{projectName}.nuget.g.targets` and `{projectName}.nuget.g.props`. These files are automatically generated when restore is run. + +When a project targets more than one framework, the imports to these files are conditioned on the target framework name. + +MSBuild `.props` and `.targets` files for multi-framework targeting can be placed in the `\buildMultiTargeting` folder. +When the imports are generated, a condition that the MSBuild property `$(TargetFramework)` is empty is set. + +### packages.config projects + +When NuGet installs a package with `\build` files, it adds MSBuild `` elements in the project file pointing to the `.targets` and `.props` files. (`.props` is added at the top of the project file; `.targets` is added at the bottom.) A separate conditional MSBuild `` element is added for each target framework. + +## Authoring packages with MSBuild props and targets + +You can use any of the following tools to include MSBuild `.props` and `.targets` in your package. + +- [NuGet.exe pack](..\create-packages\Creating-a-Package.md#include-msbuild-props-and-targets-in-a-package) +- [dotnet.exe pack](..\create-packages\creating-a-package-dotnet-cli.md) +- [MSBuild.exe pack](..\create-packages\creating-a-package-msbuild.md) + +### Guidance for the content of MSBuild props and targets + +NuGet does not limit how you author `.props` and `.targets` as they will vary based on the need of the package author and the target projects themselves. + +There are a few things that must not be done in packages' `.props` and `.targets`, such as not specifying properties and items that affect restore, as those will be automatically excluded. + +- Some examples of properties that must not be added or updated: TargetFramework, TargetFrameworkMoniker, TargetPlatformMoniker, AssetTargetFallback etc. + +- Some examples of items that must not be added or updated: PackageReference, PackageVersion, PackageDownload, etc. diff --git a/docs/reference/Package-Versioning.md b/docs/concepts/Package-Versioning.md similarity index 61% rename from docs/reference/Package-Versioning.md rename to docs/concepts/Package-Versioning.md index 4a5ae0724..eb29a1da6 100644 --- a/docs/reference/Package-Versioning.md +++ b/docs/concepts/Package-Versioning.md @@ -1,8 +1,8 @@ --- title: NuGet Package Version Reference description: Exact details on specifying version numbers and ranges for other packages upon which a NuGet package depends, and how dependencies are installed. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 03/23/2018 ms.topic: reference ms.reviewer: anangaur @@ -14,11 +14,15 @@ A specific package is always referred to using its package identifier and an exa When creating a package, you assign a specific version number with an optional pre-release text suffix. When consuming packages, on the other hand, you can specify either an exact version number or a range of acceptable versions. +The following document follows the [Semantic Versioning 2.0.0](https://semver.org/spec/v2.0.0.html) standard, supported by NuGet 4.3.0+ and Visual Studio 2017 version 15.3+. +Certain [semantics of SemVer v2.0.0](#semantic-versioning-200) are not supported in older clients. + In this topic: - [Version basics](#version-basics) including pre-release suffixes. -- [Version ranges and wildcards](#version-ranges-and-wildcards) +- [Version ranges](#version-ranges) - [Normalized version numbers](#normalized-version-numbers) +- [Semantic Versioning 2.0.0](#semantic-versioning-200) ## Version basics @@ -27,14 +31,16 @@ A specific version number is in the form *Major.Minor.Patch[-Suffix]*, where the - *Major*: Breaking changes - *Minor*: New features, but backwards compatible - *Patch*: Backwards compatible bug fixes only -- *-Suffix* (optional): a hyphen followed by a string denoting a pre-release version (following the [Semantic Versioning or SemVer 1.0 convention](http://semver.org/spec/v1.0.0.html)). +- *-Suffix* (optional): a hyphen followed by a string denoting a pre-release version (following the [Semantic Versioning or SemVer](https://semver.org/) convention). **Examples:** - 1.0.1 - 6.11.1231 - 4.3.1-rc - 2.2.44-beta1 +``` +1.0.1 +6.11.1231 +4.3.1-rc +2.2.44-beta.1 +``` > [!Important] > nuget.org rejects any package upload that lacks an exact version number. The version must be specified in the `.nuspec` or project file used to create the package. @@ -49,57 +55,58 @@ That said, package developers generally follow recognized naming conventions: - `-beta`: Beta release, typically one that is feature complete for the next planned release, but may contain known bugs. - `-rc`: Release candidate, typically a release that's potentially final (stable) unless significant bugs emerge. -> [!Note] -> NuGet 4.3.0+ supports [SemVer 2.0.0](http://semver.org/spec/v2.0.0.html), which supports pre-release numbers with dot notation, as in *1.0.1-build.23*. Dot notation is not supported with NuGet versions before 4.3.0. You can use a form like *1.0.1-build23*. - -When resolving package references and multiple package versions differ only by suffix, NuGet chooses a version without a suffix first, then applies precedence to pre-release versions in reverse alphabetical order. For example, the following versions would be chosen in the exact order shown: +When ordering versions by precedence, NuGet follows the SemVer standard and chooses a version without a suffix first, then applies precedence to pre-release versions in reverse alphabetical order and treats dot notation numbers with numerical order. - 1.0.1 - 1.0.1-zzz - 1.0.1-rc - 1.0.1-open - 1.0.1-beta - 1.0.1-alpha2 - 1.0.1-alpha - 1.0.1-aaa - -## Semantic Versioning 2.0.0 - -With NuGet 4.3.0+ and Visual Studio 2017 version 15.3+, NuGet supports [Semantic Versioning 2.0.0](http://semver.org/spec/v2.0.0.html). +> [!Note] +> Prerelease numbers with dot notation, as in *1.0.1-build.23*, are considered part of the [SemVer 2.0.0](https://semver.org/spec/v2.0.0.html) standard, and as such are [only supported with NuGet 4.3.0+](#semantic-versioning-200). -Certain semantics of SemVer v2.0.0 are not supported in older clients. NuGet considers a package version to be SemVer v2.0.0 specific if either of the following statements is true: +### [SemVer 2.0 sorting](#tab/semver20sort) -- The pre-release label is dot-separated, for example, *1.0.0-alpha.1* -- The version has build-metadata, for example, *1.0.0+githash* +``` +1.0.1 +1.0.1-zzz +1.0.1-rc.10 +1.0.1-rc.2 +1.0.1-open +1.0.1-beta +1.0.1-alpha2 +1.0.1-alpha10 +1.0.1-aaa +``` -For nuget.org, a package is defined as a SemVer v2.0.0 package if either of the following statements is true: +Note that 1.0.1-alpha10 is sorted strictly in reverse alphabetical order, whereas 1.0.1-rc.10 is greater precedence than 1.0.1-rc.2. -- The package's own version is SemVer v2.0.0 compliant but not SemVer v1.0.0 compliant, as defined above. -- Any of the package's dependency version ranges has a minimum or maximum version that is SemVer v2.0.0 compliant but not SemVer v1.0.0 compliant, defined above; for example, *[1.0.0-alpha.1, )*. +### [SemVer 1.0 sorting](#tab/semver10sort) -If you upload a SemVer v2.0.0-specific package to nuget.org, the package is invisible to older clients and available to only the following NuGet clients: +``` +1.0.1 +1.0.1-zzz +1.0.1-open +1.0.1-beta05 +1.0.1-beta02 +1.0.1-beta +1.0.1-alpha2 +1.0.1-alpha10 +1.0.1-aaa +``` -- NuGet 4.3.0+ -- Visual Studio 2017 version 15.3+ -- Visual Studio 2015 with [NuGet VSIX v3.6.0](https://dist.nuget.org/visualstudio-2015-vsix/latest/NuGet.Tools.vsix) -- dotnet - - dotnetcore.exe (.NET SDK 2.0.0+) +Note that versions such as `1.0.1-rc.10` and `1.0.1-rc.2` are not parsable by older versions of the client, and such packages with those versions won't be available for download with those clients. -Third-party clients: +If you use numerical suffixes with pre-release tags that might use double-digit numbers (or more), use leading zeroes as in beta01 and beta05 to ensure that they sort correctly when the numbers get larger. +This recommendation only applies this schema. -- JetBrains Rider -- Paket version 5.0+ +Despite the ordering shown above, NuGet does not always consider both stable & prerelease packages during dependency resolution. Those rules are detailed in [Dependency Resolution](./Dependency-Resolution.md). - - +--- -## Version ranges and wildcards +## Version ranges When referring to package dependencies, NuGet supports using interval notation for specifying version ranges, summarized as follows: | Notation | Applied rule | Description | |----------|--------------|-------------| | 1.0 | x ≥ 1.0 | Minimum version, inclusive | +| [1.0,) | x ≥ 1.0 | Minimum version, inclusive | | (1.0,) | x > 1.0 | Minimum version, exclusive | | [1.0] | x == 1.0 | Exact version match | | (,1.0] | x ≤ 1.0 | Maximum version, inclusive | @@ -109,38 +116,43 @@ When referring to package dependencies, NuGet supports using interval notation f | [1.0,2.0) | 1.0 ≤ x < 2.0 | Mixed inclusive minimum and exclusive maximum version | | (1.0) | invalid | invalid | -When using the PackageReference format, NuGet also supports using a wildcard notation, \*, for Major, Minor, Patch, and pre-release suffix parts of the number. Wildcards are not supported with the `packages.config` format. - -> [!Note] -> Pre-release versions are not included when resolving version ranges. Pre-release versions *are* included when using a wildcard (\*). The version range *[1.0,2.0]*, for example, does not include 2.0-beta, but the wildcard notation _2.0-*_ does. See [issue 912](https://github.com/NuGet/Home/issues/912) for further discussion on pre-release wildcards. - -### Examples +### Best Practice -Always specify a version or version range for package dependencies in project files, `packages.config` files, and `.nuspec` files. Without a version or version range, NuGet 2.8.x and earlier chooses the latest available package version when resolving a dependency, whereas NuGet 3.x and later chooses the lowest package version. Specifying a version or version range avoids this uncertainty. +Always specify a version or version range for package dependencies in project files, `packages.config` files, and `.nuspec` files. Without a version or version range, when resolving a dependency, consistent restore results are not guaranteed. +Avoid specifying an upper bound to version ranges to packages you don't own unless you know of a compatibility problem. Upper bounds to version ranges harm adoption, discourage consumers from getting valuable updates to dependencies, and in some cases may lead them to use unsupported versions of dependencies. #### References in project files (PackageReference) ```xml - + - + - + + + + used to guarantee a dependency with a specific bug fix. + Will resolve to the smallest acceptable stable version.--> + recommended because it can be difficult to determine the lowest version. + Will resolve to the smallest acceptable stable version. + --> - + - + ``` @@ -202,21 +214,60 @@ The `version` attribute in a `` element describes the range versions ## Normalized version numbers > [!Note] -> This is a breaking change for NuGet 3.4 and later. +> This is a breaking change for NuGet 3.4+. When obtaining packages from a repository during install, reinstall, or restore operations, NuGet 3.4+ treats version numbers as follows: - Leading zeroes are removed from version numbers: - - 1.00 is treated as 1.0 - 1.01.1 is treated as 1.1.1 - 1.00.0.1 is treated as 1.0.0.1 + - 1.00 is treated as 1.0 + - 1.01.1 is treated as 1.1.1 + - 1.00.0.1 is treated as 1.0.0.1 - A zero in the fourth part of the version number will be omitted + - 1.0.0.0 is treated as 1.0.0 + - 1.0.01.0 is treated as 1.0.1 - 1.0.0.0 is treated as 1.0.0 - 1.0.01.0 is treated as 1.0.1 +- SemVer 2.0.0 build metadata is removed + - 1.0.7+r3456 is treated as 1.0.7 -This normalization does not affect the version numbers in the packages themselves; it affects only how NuGet matches versions when resolving dependencies. +`pack` and `restore` operations normalize versions whenever possible. For packages already built, this normalization does not affect the version numbers in the packages themselves; it affects only how NuGet matches versions when resolving dependencies. However, NuGet package repositories must treat these values in the same way as NuGet to prevent package version duplication. Thus a repository that contains version *1.0* of a package should not also host version *1.0.0* as a separate and different package. + +## Semantic Versioning 2.0.0 + +Certain semantics of SemVer v2.0.0 are not supported in older clients. +NuGet considers a package version to be SemVer v2.0.0 specific if either of the following statements is true: + +- The pre-release label is dot-separated, for example, *1.0.0-alpha.1* +- The version has build-metadata, for example, *1.0.0+githash* + +For nuget.org, a package is defined as a SemVer v2.0.0 package if either of the following statements is true: + +- The package's own version is SemVer v2.0.0 compliant but not SemVer v1.0.0 compliant, as defined above. +- Any of the package's dependency version ranges has a minimum or maximum version that is SemVer v2.0.0 compliant but not SemVer v1.0.0 compliant, defined above; for example, *[1.0.0-alpha.1, )*. + +If you upload a SemVer v2.0.0-specific package to nuget.org, the package is invisible to older clients and available to only the following NuGet clients: + +- NuGet 4.3.0+ +- Visual Studio 2017 version 15.3+ +- Visual Studio 2015 with [NuGet VSIX v3.6.0](https://dist.nuget.org/visualstudio-2015-vsix/latest/NuGet.Tools.vsix) +- .NET SDK 2.0.0+ + +Third-party clients: + +- JetBrains Rider +- Paket version 5.0+ + + + + +## Where NuGetVersion diverges from Semantic Versioning + +If you want to programatically use NuGet package versions, it is strongly recommended to use [the package NuGet.Versioning](https://www.nuget.org/packages/NuGet.Versioning). The static method `NuGetVersion.Parse(string)` can be used to parse the version strings, and `VersionComparer` can be used to sort `NuGetVersion` instances. + +If you are implementing NuGet functionality in a language that does not run on .NET, here are the known list of differences between `NuGetVersion` and Semantic Versioning, and the reasons why an existing Semantic Versioning library might not work for packages already published on nuget.org. + +1. `NuGetVersion` supports a 4th version segment, `Revision`, to be compatible with, or a superset of, [`System.Version`](/dotnet/api/system.version). Therefore, excluding prerelease and metadata labels, a version string is `Major.Minor.Patch.Revision`. As per version normalization described above, if `Revision` is zero, it is omitted from the normalized version string. +2. `NuGetVersion` only requires the major segment to be defined. All others are optional, and are equivalent to zero. This means that `1`, `1.0`, `1.0.0`, and `1.0.0.0` are all accepted and equal. +3. `NuGetVersion` uses case insensitive string comparisons for pre-release components. This means that `1.0.0-alpha` and `1.0.0-Alpha` are equal. diff --git a/docs/concepts/Security-Best-Practices.md b/docs/concepts/Security-Best-Practices.md new file mode 100644 index 000000000..771661ca9 --- /dev/null +++ b/docs/concepts/Security-Best-Practices.md @@ -0,0 +1,319 @@ +--- +title: Best practices for a secure software supply chain +description: Best practices for securing your software supply chain using NuGet & GitHub. +author: JonDouglas +ms.author: jodou +ms.topic: conceptual +--- + +# Best practices for a secure software supply chain + +Open Source is everywhere. +It is in many proprietary codebases and community projects. +For organizations and individuals, the question today is not whether you are or are not using open-source code, but what open-source code you are using, and how much. + +If you're not aware of what is in your software supply chain, an upstream vulnerability in one of your dependencies can be fatal, making you, and your customers, vulnerable to a potential compromise. +In this document, we will dive deeper into what the term “software supply chain” means, why it matters, and how you can help secure your project’s supply chain with best practices. + +![The State of the Octoverse 2020 - Open Source](media/opensource-percent.png) + +## Dependencies + +The term software supply chain is used to refer to everything that goes into your software and where it comes from. +It is the dependencies and properties of your dependencies that your software supply chain depends on. +A dependency is what your software needs to run. +It can be code, binaries, or other components, and where they come from, such as a repository or package manager. + +It includes who wrote the code, when it was contributed, how it was reviewed for security issues, known vulnerabilities, supported versions, license information, and just about anything that touches it at any point of the process. + +Your supply chain also encompasses other parts of your stack beyond a single application, such as your build and packaging scripts or the software that runs the infrastructure your application relies on. + +## Vulnerabilities + +Today, software dependencies are pervasive. +It is quite common for your projects to use hundreds of open-source dependencies for functionality that you did not have to write yourself. +This may mean that most of your application consists of code that you did not author. + +![The State of the Octoverse 2020 - Dependencies](media/dependencies.png) + +Possible vulnerabilities in your third-party or open-source dependencies, are presumably dependencies you cannot control as tightly as the code you write, which can create potential security risks in your supply chain. + +If one of these dependencies has a vulnerability, the chances are you have a vulnerability as well. +This can be scary as one of your dependencies may change without you even knowing. +Even if a vulnerability exists in a dependency today, but is not exploitable, it can be exploitable in the future. + +Being able to leverage the work of thousands of open-source developers and library authors means that thousands of strangers can effectively contribute directly to your production code. +Your product, through your software supply chain, is affected by unpatched vulnerabilities, innocent mistakes, or even malicious attacks against dependencies. + +## Supply chain compromises + +The traditional definition of a supply chain comes from manufacturing; it is the chain of processes required to make and supply something. +It includes planning, supply of materials, manufacturing, and retail. +A software supply chain is similar, except instead of materials, it is code. +Instead of manufacturing, it is development. +Instead of digging ore from the ground, code is sourced from suppliers, commercial or open source, and, in general, the open-source code comes from repositories. +Adding code from a repository means your product takes a dependency on that code. + +One example of a software supply chain attack occurs when malicious code is purposefully added to a dependency, using the supply chain of that dependency to distribute the code to its victims. +Supply chain attacks are real. +There are many methods to attack a supply chain, from directly inserting malicious code as a new contributor, to taking over a contributor’s account without others noticing, or even compromising a signing key to distribute software that is not officially part of the dependency. + +A software supply chain attack is in and of itself rarely the end goal, rather it is the beginning of an opportunity for an attacker to insert malware or provide a backdoor for future access. + +![The State of the Octoverse 2020 - Vulnerability Lifecycle](media/vulnerability-lifecycle.png) + +## Unpatched software + +The use of open source today is significant and is not expected to slow down anytime soon. +Given that we are not going to stop using open-source software, the threat to supply chain security is unpatched software. +Knowing that, how can you address the risk that a dependency of your project has a vulnerability? + +- **Knowing what is in your environment.** This requires discovering your dependencies and any transitive dependencies to understand the risks of those dependencies such as vulnerabilities or licensing restrictions. +- **Manage your dependencies.** When a new security vulnerability is discovered, you must determine whether you are impacted, and if so, update to the latest version and security patch available. + This is especially important to review changes that introduce new dependencies or regularly auditing older dependencies. +- **Monitor your supply chain.** This is by auditing the controls you have in place to manage your dependencies. + This will help you enforce more restrictive conditions to be met for your dependencies. + +![The State of the Octoverse 2020 - Advisories](media/advisories.png) + +We will cover various tools and techniques that NuGet and GitHub provides, which you can use today to address potential risks inside your project. + +## Knowing what is in your environment + +### Packages with known vulnerabilities + +**📦 Package Consumer | 📦🖊 Package Author** + +.NET 8 and Visual Studio 17.8 added [NuGetAudit](Auditing-Packages.md), which will warn about direct packages with known vulnerabilities during restore. +.NET 9 and Visual Studio 17.12 changed the default to warn about transitive packages as well. + +NuGetAudit requires a source to provide a known vulnerabilities database, so if you're not using nuget.org as a package source, you should add it as an [audit source](Auditing-Packages.md#audit-sources). + +By the time that NuGet is warning you, the vulnerability is publicly known. +Attackers can use this public disclosure to develop attacks for targets who have not patched their applications. +Therefore, when you get a warning that a package your project is using has a known vulnerability, you should quickly take action. + +### NuGet dependency graph + +**📦 Package Consumer** + +You can view your NuGet dependencies in your project by looking directly at the respective project file. + +This is typically found in one of two places: + +- [`packages.config`](../reference/packages-config.md) – Located in the project root. +- [``](../consume-packages/package-references-in-project-files.md) – Located in the project file. + +Depending on what method you use to manage your NuGet dependencies, you can also use Visual Studio to view your dependencies directly in [Solution Explorer](/visualstudio/ide/solutions-and-projects-in-visual-studio#solution-explorer) or [NuGet Package Manager](../consume-packages/install-use-packages-visual-studio.md). + +For CLI environments, you can use the [`dotnet list package` command](/dotnet/core/tools/dotnet-list-package) to list out your project or solution’s dependencies. +You can also use the [`dotnet nuget why` command](/dotnet/core/tools/dotnet-nuget-why) to understand why transitive packages (those not directly referenced by your project) are being included in your project's package graph. + +For more information on managing NuGet dependencies, [see the following documentation](../consume-packages/overview-and-workflow.md). + +### GitHub dependency graph + +**📦 Package Consumer | 📦🖊 Package Author** + +You can use GitHub’s dependency graph to see the packages your project depends on and the repositories that depend on it. +This can help you see any vulnerabilities detected in its dependencies. + +For more information on GitHub repository dependencies, [see the following documentation](https://github.co/dependency-graph). + +### Dependency versions + +**📦 Package Consumer | 📦🖊 Package Author** + +To ensure a secure supply chain of dependencies, you will want to ensure that all of your dependencies & tooling are regularly updated to the latest stable version as they will often include the latest functionality and security patches to known vulnerabilities. +Your dependencies can include code you depend on, binaries you consume, tooling you use, and other components. +This may include: + +- [Visual Studio](https://visualstudio.microsoft.com/downloads/) +- [.NET SDK & Runtime](https://dotnet.microsoft.com/download) +- [NuGet](https://www.nuget.org/downloads) +- [NuGet packages](../consume-packages/reinstalling-and-updating-packages.md) + +## Manage your dependencies + +### NuGet deprecated and vulnerable dependencies + +**📦 Package Consumer | 📦🖊 Package Author** + +You can use the [dotnet CLI](/dotnet/core/tools/dotnet-list-package) to list any known deprecated or vulnerable dependencies you may have inside your project or solution. +You can use the command `dotnet list package --deprecated` or `dotnet list package --vulnerable` to provide you a list of any known deprecations or vulnerabilities. +[NuGetAudit](Auditing-Packages.md) can warn you about known vulnerable dependencies, and is enabled by default when [a source provides a vulnerabilities database](Auditing-Packages.md#audit-sources). + +### GitHub vulnerable dependencies + +**📦 Package Consumer | 📦🖊 Package Author** + +If your project is hosted on GitHub, you can leverage [GitHub Security](https://docs.github.com/en/free-pro-team@latest/github/finding-security-vulnerabilities-and-errors-in-your-code/automatically-scanning-your-code-for-vulnerabilities-and-errors) to find security vulnerabilities and errors in your project and Dependabot will fix them by opening up a pull request against your codebase. + +Catching vulnerable dependencies before they are introduced is one goal of the [“Shift Left”](https://en.wikipedia.org/wiki/Shift-left_testing) movement. +Being able to have information about your dependencies such as their license, transitive dependencies, and the age of dependencies helps you do just that. + +For more information about Dependabot alerts & security updates, [see the following documentation](https://docs.github.com/en/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies). + +## NuGet Configuration + +**📦 Package Consumer** + +Add a `nuget.config` file in the root of your project repository. This is considered a best practice as it promotes repeatability and ensures that different users have the same NuGet configuration. +We recommend adding `clear` elements to ensure no user or machine specific configuration is applied. [Read more about how settings are applied](../consume-packages/configuring-nuget-behavior.md#how-settings-are-applied). + +For example: + +```xml + + + + + + + + + +``` + +### NuGet feeds + +**📦 Package Consumer** + +Use package sources that you trust. +When using multiple public & private NuGet source feeds, a package can be downloaded from any of the feeds. +To ensure your build is predictable and secure from known attacks such as [Dependency Confusion](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610), knowing what specific feed(s) your packages are coming from is a best practice. +You can use a single feed or private feed with upstreaming capabilities for protection. + +For more information to secure your package feeds, see [3 Ways to Mitigate Risk When Using Private Package Feeds](https://azure.microsoft.com/resources/3-ways-to-mitigate-risk-using-private-package-feeds/en-us/). + +When using a private feed, refer to the [security best practices for managing credentials](../consume-packages/consuming-packages-authenticated-feeds.md#security-best-practices-for-managing-credentials). + +### Client trust policies + +**📦 Package Consumer** + +There are policies that you can opt-into in which you require the packages you use to be signed. +This allows you to trust a package author, as long as it is author signed, or trust a package if it is owned by a specific user or account that is repository signed by NuGet.org. + +To configure client trust policies, [see the following documentation](../consume-packages/installing-signed-packages.md). + +### Lock files + +**📦 Package Consumer** + +Lock files store the hash of your package’s content. +If the content hash of a package you want to install matches with the lock file, it will ensure package repeatability. + +To enable lock files, [see the following documentation](../consume-packages/package-references-in-project-files.md#locking-dependencies). + +### Package Source mapping + +**📦 Package Consumer** + +Package Source Mapping allows you to centrally declare which source each package in your solution should restore from in your nuget.config file. + +To enable package source mapping, [see the following documentation](../consume-packages/package-source-mapping.md). + +## Secure computers + +### Directory permissions + +**📦 Package Consumer** + +On Windows and Mac, and some Linux distributions, user account home directories are private by default. +However, some Linux distributions make user directories readable by other accounts on the same computer by default. +Additionally, there are [multiple configuration options to redirect NuGet's global packages folder and HTTP cache to non-default locations](../consume-packages/managing-the-global-packages-and-cache-folders.md). +Solutions, projects, and repositories might also be created outside of the user's home directory. + +If you use any packages that are not on nuget.org, then if any other account on the computer can read NuGet's global packages or HTTP cache directories, or the project's build output directory, then these packages might be disclosed to people who should not have access to those packages. + +On Linux, `dotnet nuget update source` will change *nuget.config* file permissions to make it only readable by the file owner. +However, if you edit the *nuget.config* file in any other way, and the file is in a location that other accounts can read the file, there might be information disclosure about package source URL or package source credentials. +You should ensure any nuget.config file cannot be read by other users of the same computer. + +### Solutions within the downloads directory + +**📦 Package Consumer** + +Extra care should be taken if working on solutions or projects in your downloads directory. +NuGet will [accumulate settings from multiple config files](../consume-packages/configuring-nuget-behavior.md), and MSBuild will typically import *Directory.Build.props*, *Directory.NuGet.props*, *Directory.Build.targets*, and potentially other files, from any parent directory, right up to the filesystem root. + +The downloads folder has additional risk, since it's usually the default location that web browsers will download files from the internet + +### Build Agents + +**📦 Package Consumer** + +Build agents (CI agents) that are not reset to an initial state after every build have multiple risks that must be considered. + +To learn about secure ways to manage credentials, [see the docs on consuming packages from authenticated feeds](../consume-packages/consuming-packages-authenticated-feeds.md). + +To learn about modifying the directories that NuGet stores data in, see [the docs on managing the global packages, cache, and temp folders](../consume-packages/managing-the-global-packages-and-cache-folders.md). +These directories should be configured to a directory that the CI agent cleans after every build. + +Note that any packages used by your project might be left in your project's build output directory. +If your project uses packages from authenticated sources, then other users of the same CI agent might gain unauthorized access to the package assemblies. +Therefore, you should also clean your repo at the end of your build, even when the build fails or is cancelled. + +## Monitor your supply chain + +### GitHub secret scanning + +**📦🖊 Package Author** + +GitHub scans repositories for NuGet API keys to prevent fraudulent uses of secrets that were accidentally committed. + +To learn more about secret scanning, see [About secret scanning](https://docs.github.com/en/github/administering-a-repository/about-secret-scanning). + +### Author Package Signing + +**📦🖊 Package Author** + +[Author signing](../reference/signed-packages-reference.md) allows a package author to stamp their identity on a package and for a consumer to verify it came from you. +This protects you against content tampering and serves as a single source of truth about the origin of the package and the package authenticity. +When combined with client trust policies, you can verify a package came from a specific author. + +To author sign a package, see [Sign a package](../create-packages/sign-a-package.md). + +### Reproducible Builds + +**📦🖊 Package Author** + +Reproducible builds creates binaries that are byte-for-byte identical each time you build it, and contain source code links and compiler metadata that enable a package consumer to recreate the binary directly and validate that the build environment has not been compromised. + +To learn more about reproducible builds, see [Producing Packages with Source Link](https://devblogs.microsoft.com/dotnet/producing-packages-with-source-link/) and the [Reproducible Build Validation](https://github.com/dotnet/designs/blob/main/accepted/2020/reproducible-builds.md) spec. + +### Two-Factor Authentication (2FA) + +**📦🖊 Package Author** + +Every account on nuget.org has 2FA enabled. +This adds an extra layer of security when [logging into your GitHub account](https://docs.github.com/en/github/authenticating-to-github/securing-your-account-with-two-factor-authentication-2fa) or your [NuGet.org account](../nuget-org/individual-accounts.md#add-a-new-individual-account). + +### Package ID prefix reservation + +**📦🖊 Package Author** + +To protect the identity of your packages, you can reserve a package ID prefix with your respective namespace to associate a matching owner if your package ID prefix properly falls under the [specified criteria](../nuget-org/id-prefix-reservation.md#id-prefix-reservation-criteria). + +To learn about reserving ID prefixes, see [Package ID prefix reservation](../nuget-org/id-prefix-reservation.md). + +### Deprecating and unlisting a vulnerable package + +**📦🖊 Package Author** + +To protect the .NET package ecosystem when you are aware of a vulnerability in a package you have authored, do your best to deprecate and unlist the package so it is hidden from users searching for packages. +If you are consuming a package that is deprecated and unlisted, you should avoid using the package. + +To learn how to deprecate and unlist a package, see the following documentation on [deprecating](../nuget-org/deprecate-packages.md) and [unlisting packages](../nuget-org/policies/deleting-packages.md#unlisting-a-package). + +Also consider reporting the known to the [GitHub Advisories Database](https://github.com/advisories). + +## Summary + +Your software supply chain is anything that goes into or affects your code. +Even though supply chain compromises are real and growing in popularity, they are still rare; so the most important thing you can do is protect your supply chain by **being aware of your dependencies, managing your dependencies** and **monitoring your supply chain.** + +You learned about various methods that NuGet and [GitHub](/training/modules/maintain-secure-repository-github/) provide that are available to you today to be more effective in viewing, managing, and monitoring your supply chain. + +For more information about securing the world's software, see [The State of the Octoverse 2020 Security Report](https://octoverse.github.com/static/github-octoverse-2020-security-report.pdf). diff --git a/docs/concepts/media/advisories.png b/docs/concepts/media/advisories.png new file mode 100644 index 000000000..8856d78f8 Binary files /dev/null and b/docs/concepts/media/advisories.png differ diff --git a/docs/concepts/media/cousin-dependencies-1.png b/docs/concepts/media/cousin-dependencies-1.png new file mode 100644 index 000000000..fc228e49e Binary files /dev/null and b/docs/concepts/media/cousin-dependencies-1.png differ diff --git a/docs/concepts/media/cousin-dependencies-2.png b/docs/concepts/media/cousin-dependencies-2.png new file mode 100644 index 000000000..e6314a155 Binary files /dev/null and b/docs/concepts/media/cousin-dependencies-2.png differ diff --git a/docs/concepts/media/cousin-dependencies-3.png b/docs/concepts/media/cousin-dependencies-3.png new file mode 100644 index 000000000..807623a38 Binary files /dev/null and b/docs/concepts/media/cousin-dependencies-3.png differ diff --git a/docs/concepts/media/dependencies.png b/docs/concepts/media/dependencies.png new file mode 100644 index 000000000..ee5ff5b9b Binary files /dev/null and b/docs/concepts/media/dependencies.png differ diff --git a/docs/concepts/media/direct-dependency-1.png b/docs/concepts/media/direct-dependency-1.png new file mode 100644 index 000000000..3004ef451 Binary files /dev/null and b/docs/concepts/media/direct-dependency-1.png differ diff --git a/docs/concepts/media/direct-dependency-2.png b/docs/concepts/media/direct-dependency-2.png new file mode 100644 index 000000000..98290bc38 Binary files /dev/null and b/docs/concepts/media/direct-dependency-2.png differ diff --git a/docs/concepts/media/direct-dependency-3.png b/docs/concepts/media/direct-dependency-3.png new file mode 100644 index 000000000..f4f38b64b Binary files /dev/null and b/docs/concepts/media/direct-dependency-3.png differ diff --git a/docs/concepts/media/direct-dependency-4.png b/docs/concepts/media/direct-dependency-4.png new file mode 100644 index 000000000..596475c18 Binary files /dev/null and b/docs/concepts/media/direct-dependency-4.png differ diff --git a/docs/concepts/media/floating-versions-1.png b/docs/concepts/media/floating-versions-1.png new file mode 100644 index 000000000..95b23a6b0 Binary files /dev/null and b/docs/concepts/media/floating-versions-1.png differ diff --git a/docs/concepts/media/lowest-applicable-version-1.png b/docs/concepts/media/lowest-applicable-version-1.png new file mode 100644 index 000000000..c0fec1d60 Binary files /dev/null and b/docs/concepts/media/lowest-applicable-version-1.png differ diff --git a/docs/concepts/media/lowest-applicable-version-2.png b/docs/concepts/media/lowest-applicable-version-2.png new file mode 100644 index 000000000..360d5de64 Binary files /dev/null and b/docs/concepts/media/lowest-applicable-version-2.png differ diff --git a/docs/concepts/media/lowest-applicable-version-3.png b/docs/concepts/media/lowest-applicable-version-3.png new file mode 100644 index 000000000..92079bfcf Binary files /dev/null and b/docs/concepts/media/lowest-applicable-version-3.png differ diff --git a/docs/concepts/media/opensource-percent.png b/docs/concepts/media/opensource-percent.png new file mode 100644 index 000000000..8c09e2d72 Binary files /dev/null and b/docs/concepts/media/opensource-percent.png differ diff --git a/docs/concepts/media/vulnerability-lifecycle.png b/docs/concepts/media/vulnerability-lifecycle.png new file mode 100644 index 000000000..179d33e3a Binary files /dev/null and b/docs/concepts/media/vulnerability-lifecycle.png differ diff --git a/docs/concepts/nuget-mcp.md b/docs/concepts/nuget-mcp.md new file mode 100644 index 000000000..d3c2f5658 --- /dev/null +++ b/docs/concepts/nuget-mcp.md @@ -0,0 +1,81 @@ +--- +title: MCP servers in NuGet packages +description: How can MCP servers be distributed using NuGet? +author: joelverhagen +ms.author: jver +ms.topic: conceptual +ms.date: 07/23/2025 +--- + +# MCP servers in NuGet packages + +NuGet provides a convenient way to package and distribute MCP servers written in .NET. The C# MCP SDK and .NET offer a robust platform for building MCP servers, and NuGet is ideal for delivering your MCP server to end users as a local tool. Self-contained, platform-specific packages reduce runtime compatibility issues, and AOT compilation can further improve the end-user experience. + +For more information about the Model Context Protocol (MCP) in general, see the [introduction on the MCP website](https://modelcontextprotocol.io/introduction). To create your own MCP server and package it using NuGet, see the [quickstart guide](/dotnet/ai/quickstarts/build-mcp-server). + +## Applicable scenarios + +Shipping your MCP server via NuGet does not apply to all situations. The term "MCP client" is used in this document and refers to an application that orchestrates the interaction between an AI agent or LLM and calls made to an MCP server. Some example MCP clients are [Visual Studio Code](https://code.visualstudio.com/docs/copilot/chat/mcp-servers), [Visual Studio](/visualstudio/ide/mcp-servers), [GitHub Copilot coding agent](https://docs.github.com/copilot/concepts/coding-agent/about-copilot-coding-agent), Claude Code, or Cursor. + +Consider the following criteria to determine whether shipping your MCP server as a NuGet package makes sense: + +- ✅ You want your MCP server to run **locally** on the user's system (i.e., in the same context as the MCP client). + - Local MCP servers, such as those shipped in NuGet packages, run in the same context as the MCP client and communicate with the MCP client via standard IO (stdio) transport. The MCP client is responsible for launching the local MCP server process. +- ✅ The .NET SDK is available to the MCP client. + - NuGet MCP servers are [.NET tool packages](/dotnet/core/tools/global-tools), which are installed and executed using `dnx` from the .NET SDK. +- ✅ You have a NuGet package feed to host your MCP server package. + - NuGet.org can be used to publish MCP server packages and provides a tailored MCP browsing and consumption experience. However, any NuGet package feed, such as Azure Artifacts, can be used for hosting MCP servers if you wish to keep your MCP server package private. + +## Benefits of using .NET and NuGet for MCP servers + +There are several benefits to using NuGet for hosting your MCP server: + +- **Official SDK** - the [MCP C# SDK](https://github.com/modelcontextprotocol/csharp-sdk) provides a familiar interface for implementing your MCP server in C# and makes it easy to expose tools to MCP clients. +- **Flexible runtime options** - the .NET SDK provides several options for how your MCP server is compiled and packaged. See the [runtime requirements](#runtime-requirements) section for details. +- **Discoverability and distribution** - NuGet.org provides a way to showcase your MCP server, allowing potential users to find your MCP server and easily use it from inside VS Code or Visual Studio. NuGet.org encourages the use of an embedded [`.mcp/server.json`](https://github.com/modelcontextprotocol/registry/blob/main/docs/server-json/README.md) to declare inputs and an `McpServer` package type to allow MCP servers to be differentiated from other tool or dependency packages. +- **Familiar authoring workflows** - if you already use NuGet for creating dependency packages, creating and publishing an MCP server will be a very similar experience. + +## Package download and execution + +To fetch a local MCP server, the code for the server must be located and downloaded using a mechanism (protocol) specific to the package ecosystem. This is generally done with a "single-shot" command which takes the package name and arguments to download and then execute the package as a command-line application. + +For NuGet-based MCP servers, we recommend using `dnx` (a new command shipped in .NET 10 Preview 6) to acquire and execute the package. `dnx` currently ships with the .NET SDK, but there [is discussion to include `dnx` in the .NET runtime](https://github.com/dotnet/sdk/issues/49796). + +A command to start an MCP server would look something like this: + +```bash +dnx NuGet.Mcp.Server@0.1.2-preview --yes +``` + +Environment variables and command-line arguments can both be used to configure your MCP server in custom ways. These inputs allow you to customize the behavior of your MCP server to suit specific needs. + +This will download the `NuGet.Mcp.Server` package of version `0.1.2-preview` from your configured package sources (NuGet.org by default), and launch the contained CLI tool. For an MCP server, you may see log messages appear in stderr, but the process will appear to hang. This is expected, since the process is waiting for MCP protocol messages over stdin from your MCP client. + +Typically, your MCP client will invoke this command via tool-specific MCP configuration, such as the `mcp.json` file used by Visual Studio Code and Visual Studio. + +All of these tools support installing alternate sources. For example, `dnx` supports installing from Azure DevOps using the `--source` parameter, allowing consumption of private MCP servers, as long as the needed credential or credential providers are configured. + +## Runtime requirements + +Once the package is downloaded, a runtime is needed to execute the code inside the package. .NET tool packages (and by extension NuGet-based MCP servers) support a variety of options for how the tool is compiled and packaged. These options allow you, the MCP server author, to decide which runtime requirements should be placed on the users of your MCP server. + +There are three main options for how to package your MCP server: + +1. **Framework-dependent**: Requires that the MCP client has access to a compatible .NET runtime. If `dnx` is being used to download and execute the package, a runtime will be available. +2. **Self-contained**: Bundles the runtime with the package. [Using trimming](/dotnet/core/deploying/trimming/trimming-options) can reduce the size of the package. Self-contained .NET tools use `true`. +3. **Ahead-of-time (AOT) compiled**: A self-contained package with AOT compilation enabled. See [native AOT deployment](/dotnet/core/deploying/native-aot/) for more information. AOT .NET tools use `true`. + +For MCP servers, we recommend using option #2 (self-contained package without AOT) because it eliminates the need for any specific .NET runtime version present in the user's environment. If you can guarantee a compatible runtime version on the intended execution environment, option #1 is reasonable. Option #3 (using AOT) is also a good option, but it forces you or your dependencies to make your code compatible with AOT compilation. The C# MCP SDK is AOT compatible, but other dependencies you intend to use may not yet be AOT compatible. + +Consider using the `mcpserver` template in the [Microsoft.Extensions.AI.Templates](https://www.nuget.org/packages/Microsoft.Extensions.AI.Templates) template package to use the latest recommended defaults. + +## Comparison to other ecosystems + +Other ecosystems have similar requirements and workflows for packaging and running MCP servers: + +- **NuGet/.NET**: Uses the `dnx` command to download and execute .NET tool packages. Requires the .NET SDK for `dnx`. Additional runtime dependencies can be bundled into the package. +- **npm**: Uses the `npx` command to download and execute npm packages, and install dependencies transitively. Requires Node.js. +- **Python**: Uses the `uvx` command to download and execute Python packages, and install dependencies transitively. Requires a Python runtime. +- **Docker**: Uses the `docker run` command to download and execute images. Requires the Docker Engine. Docker images can target multiple CPU architectures and provide excellent isolation, but are generally larger than NuGet, npm, or Python packages. + +In all of these cases, the MCP client needs to have the necessary ecosystem-specific tool (e.g., `dnx`, `npx`) to download and execute the package-based MCP server. diff --git a/docs/concepts/package-installation-process.md b/docs/concepts/package-installation-process.md index 50e8ab4e9..7ca6863e8 100644 --- a/docs/concepts/package-installation-process.md +++ b/docs/concepts/package-installation-process.md @@ -1,8 +1,8 @@ --- title: What happens when a package is installed? description: Detailed information about the package installation process -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 06/20/2019 ms.topic: conceptual --- @@ -20,7 +20,10 @@ The general process is as follows: 2. Acquire the package: - Check if the package (by exact identifer and version number) is already installed in the *global-packages* folder as described on [Managing the global packages and cache folders](../consume-packages/managing-the-global-packages-and-cache-folders.md). - - If the package is not in the *global-packages* folder, attempt to retrieve it from the sources listed listed in the [configuration files](../consume-packages/Configuring-NuGet-Behavior.md). For online sources, attempt first to retrieve the package from the HTTP cache unless `-NoCache` is specified with `nuget.exe` commands or `--no-cache` is specified with `dotnet restore`. (Visual Studio and `dotnet add package` always use the cache.) If a package is used from the cache, "CACHE" appears in the output. The cache has an expiration time of 30 minutes. + - If the package is not in the *global-packages* folder, attempt to retrieve it from the sources listed in the [configuration files](../consume-packages/Configuring-NuGet-Behavior.md). [Package Source Mapping](../consume-packages/package-source-mapping.md) configurations are applied at this point. For online sources, attempt first to retrieve the package from the HTTP cache unless `-NoHttpCache` is specified with `nuget.exe` commands or `--no-http-cache` is specified with `dotnet restore`. (Visual Studio and `dotnet add package` always use the cache.) If a package is used from the cache, "CACHE" appears in the output. The cache has an expiration time of 30 minutes. + + - If the package has been specified using a [floating version](../consume-packages/Package-References-in-Project-Files.md#floating-versions), or without a minimum version, NuGet *will* contact all sources to figure out the best match. + Example: `1.*`, `(, 2.0.0]`. - If the package is not in the HTTP cache, attempt to download it from the sources listed in the configuration. If a package is downloaded, "GET" and "OK" appear in the output. NuGet logs http traffic on normal verbosity. @@ -34,7 +37,7 @@ The general process is as follows: 4. If downloaded, install the package into the per-user *global-packages* folder. NuGet creates a subfolder for each package identifier, then creates subfolders for each installed version of the package. -5. NuGet installs package dependencies as required. This process might update package versions in the process, as described in [Dependency Resolution](../consume-packages/dependency-resolution.md). +5. NuGet installs package dependencies as required. This process might update package versions in the process, as described in [Dependency Resolution](../concepts/dependency-resolution.md). 6. Update other project files and folders: diff --git a/docs/concepts/troubleshooting-installed-packages.md b/docs/concepts/troubleshooting-installed-packages.md new file mode 100644 index 000000000..1b6c361b9 --- /dev/null +++ b/docs/concepts/troubleshooting-installed-packages.md @@ -0,0 +1,87 @@ +--- +title: Troubleshooting Installed Packages +description: How to find which package source was used for individual packages +author: JonDouglas +ms.author: jodou +ms.date: 03/26/2021 +ms.topic: conceptual +--- + +# Troubleshooting Installed Packages + +Sometimes you might want to validate which source a specific package was installed from. Here are some ways you can check. + +> [!Note] +> Some package sources support a concept known as upstream sources. For example, [Azure Artifacts upstream sources](/azure/devops/artifacts/concepts/upstream-sources). NuGet clients do not know whether a package came from an upstream source. Therefore, any logging of the package source will list the configured source, not the upstream source. + +## `.nupkg.metadata` file in global packages folder + +When a package is extracted into the *global-packages* folder, a file `.nupkg.metadata` is written. Starting from NuGet 5.9.0, NuGet will add the package source. See below to map NuGet versions to Visual Studio or .NET SDK versions. For example: + +```json +{ + "version": 2, + "contentHash": "bw3R9q8cVNhWXNpnvWb0OGP4HadS4zvClq+T1zf7AF+tLY1haZ2AvbHidQekf4PDv1T40c6brZeT/V0IBq7cEQ==", + "source": "https://api.nuget.org/v3/index.json" +} +``` + +> [!Note] +> If your *global-packages* folder has packages extracted before you upgraded to a newer version of tools that has NuGet 5.9.0, the `.nupkg.metadata` file will be version 1 and will not contain the package source. You can [clear your *global-packages* folder](../consume-packages/managing-the-global-packages-and-cache-folders.md#clearing-local-folders) to ensure all packages will contain the package source. + +> [!Tip] +> NuGet writes the `.nupkg.metadata` file to the *global-packages* folder only. Projects using `packages.config` use a solution packages folder, which does not create a `.nupkg.metadata` file. + +## Installed package log message + +Starting from NuGet 5.9.0, NuGet outputs the package source in the restore message informing that a package was installed. For example: + +```text +Installed Moq 4.16.1 from https://api.nuget.org/v3/index.json with content hash bw3R9q8cVNhWXNpnvWb0OGP4HadS4zvClq+T1zf7AF+tLY1haZ2AvbHidQekf4PDv1T40c6brZeT/V0IBq7cEQ==. +``` + +> [!Tip] +> This message is output at normal/informational verbosity. Visual Studio and the `dotnet` CLI default to minimal verbosity, so this message will not be visible by default. The `msbuild` and `nuget` CLI tools default to normal verbosity, so this message will be visible by default. + +## HTTP log message + +When a package is not available locally, either in the *global-packages* folder, a fallback folder, or a local file source, NuGet will download it from any configured package source over HTTP. HTTP requests and responses are logged at the normal verbosity level, and you should see only a single request and response per package version. For example: + +```text +info : GET https://api.nuget.org/v3-flatcontainer/moq/index.json +info : OK https://api.nuget.org/v3-flatcontainer/moq/index.json 56ms +info : GET https://api.nuget.org/v3-flatcontainer/moq/4.16.1/moq.4.16.1.nupkg +info : OK https://api.nuget.org/v3-flatcontainer/moq/4.16.1/moq.4.16.1.nupkg 3ms +``` + +If the files were recently downloaded, they might be retrieved from NuGet's *http-cache* + +```text +CACHE https://api.nuget.org/v3-flatcontainer/moq/index.json +CACHE https://api.nuget.org/v3-flatcontainer/moq/4.16.1/moq.4.16.1.nupkg +``` + +The URL format may be different for different NuGet HTTP server implementations, and whether it's implementing NuGet V2 or V3 HTTP protocol. + +If your `nuget.config` has multiple HTTP sources defined, you will see multiple requests to each package's `index.json` file, one for each source. But there will be only a single `nupkg` download for each version of the package. + +## Package signature log message + +If the package being downloaded is signed, NuGet will validate the signature and will log the following message at detailed verbosity: + +```text +PackageSignatureVerificationLog: PackageIdentity: Moq.4.16.1 Source: https://api.nuget.org/v3/index.json PackageSignatureValidity: True +``` + +This message will be reported whether the package was downloaded from an HTTP package source, or copied from a local package source. It will not be output if the package is already available in the *global-packages* folder or a fallback folder. + +> [!Important] +> Due to [removal of trust of VeriSign CA](https://github.com/dotnet/announcements/issues/180) NuGet has disabled signed package verification on certain platforms, in certain versions of NuGet and the .NET SDK. Therefore, the same packages may have `PackageSignatureVerificationLog` logs, or those logs may be missing, depending on what platform you're running restore on, and which version of .NET or NuGet you're using. + +## NuGet Version Map + +The following versions of NuGet have important changes regarding package source logging: + +|NuGet Version|Visual Studio Version|.NET SDK Version| +|---|---|---| +|NuGet 5.9.0|Visual Studio 2019 16.9.0|.NET 5 SDK 5.0.200| diff --git a/docs/consume-packages/Central-Package-Management.md b/docs/consume-packages/Central-Package-Management.md new file mode 100644 index 000000000..dbbf6b145 --- /dev/null +++ b/docs/consume-packages/Central-Package-Management.md @@ -0,0 +1,275 @@ +--- +title: Central Package Management +description: Manage your dependencies in a central location and learn how to get started with Central Package Management. +author: jondouglas +ms.author: jodou +ms.date: 05/09/2022 +ms.topic: conceptual +--- + +# Central Package Management (CPM) + +Dependency management is a core feature of NuGet. +While managing dependencies for a single project is straightforward, it becomes increasingly complex as the number of projects in a solution grows. + +If you manage common dependencies for many different projects, you can leverage NuGet's Central Package Management (CPM) features to do all of this from a single, central location. + +Central Package Management applies to all ``-based MSBuild projects (including [legacy CSPROJ](https://github.com/dotnet/project-system/blob/main/docs/feature-comparison.md)). + +## Enabling Central Package Management + +To get started with Central Package Management, create a `Directory.Packages.props` file at the root of your repository and set the MSBuild property `ManagePackageVersionsCentrally` to `true`. + +You can create it manually, or use the .NET CLI: + +```shell +dotnet new packagesprops +``` + +Inside `Directory.Packages.props`, define `` elements to specify the package IDs and versions used by your projects. + +```xml + + + true + + + + + + +``` + +In each project file, define `` elements without the `Version` attribute. +The version will be resolved from the corresponding `` entry in `Directory.Packages.props`. + +```xml + + + net6.0 + + + + + +``` + +Now you're using Central Package Management and managing your versions in a central location! + +## Central Package Management Rules + +The `Directory.Packages.props` file has specific rules regarding its location and context within a repository. +Only one `Directory.Packages.props` file is evaluated for a given project by default. + +If you have multiple `Directory.Packages.props` files in your repository, the file closest to a given project's directory will be evaluated for it. +This allows extra control at various levels of your repository. + +Consider the following repository directory structure: + +``` +📂 (root) + ├─📄 Directory.Packages.props + | + ├─📂Solution1 + | ├─ 📄Directory.Packages.props + | | + | └─ 📂 Project1 + | └─📄Project1.csproj + | + └─ 📂 Solution2 + └─ 📂 Project2 + └─ 📄 Project2.csproj +``` + +`Project1.csproj` will use the `Directory.Packages.props` file in the `Repository\Solution1\` directory. +If you want to include settings from a parent `Directory.Packages.props`, you must manually import it. + +```xml + + + + + + +``` + +`Project2.csproj` will evaluate the `Directory.Packages.props` file in the root directory. + +> [!NOTE] +> MSBuild will only automatically import the first `Directory.Packages.props` file it finds in the project directory or any parent directory. +> If you have multiple such files, you must manually import parent files as needed. + +## Getting Started + +To fully onboard your repository, follow these steps: + +1. Create a new file at the root of your repository named `Directory.Packages.props` that declares your centrally defined package versions and set the MSBuild property `ManagePackageVersionsCentrally` to `true`. +2. Declare `` items in your `Directory.Packages.props`. +3. Declare `` items without `Version` attributes in your project files. + +For an example of how Central Package Management may look, refer to our [samples repository](https://github.com/NuGet/Samples/tree/main/CentralPackageManagementExample). + +## Using Different Versions for Different Target Frameworks + +As NuGet packages evolve, package owners may drop support for older target frameworks. +This can cause issues for developers of libraries that still target older frameworks but want to reference newer versions of packages for newer target frameworks. + +For example, if your project targets .NET Standard 2.0, .NET 8.0, and .NET Framework 4.7.2, but `PackageA` no longer supports .NET Standard 2.0 in its latest version, you can specify different versions for each target framework. + +```xml + + + netstandard2.0;net8.0;net472 + + + + + +``` + +In this case, define different versions for each target framework in your `Directory.Packages.props` using [MSBuild conditions](/visualstudio/msbuild/msbuild-conditions): + +```xml + + + true + + + + + + +``` + +## Transitive Pinning + +You can automatically override a transitive package version without an explicit top-level `` item by opting into a feature known as transitive pinning. +This promotes a transitive dependency to a top-level dependency implicitly on your behalf when necessary. + +Note that downgrades are not allowed when transitive pinning a package. +If you attempt to pin a package to a lower version than the one requested by your dependencies, restore will raise a [NU1109](../reference/errors-and-warnings/NU1109.md) error. + +You can enable this feature by setting the MSBuild property `CentralPackageTransitivePinningEnabled` to `true` in a project or in a `Directory.Packages.props` or `Directory.Build.props` import file: + +```xml + + true + +``` + +### Transitive Pinning and Pack + +When a package is transitively pinned, your project uses a higher version than the one requested by your dependencies. +If you create a package from your project, to ensure that your package will work, NuGet will promote the transitively pinned dependencies to explicit dependencies in the nuspec. + +In the following example, `PackageA 1.0.0` has a dependency on `PackageB 1.0.0`. + +```xml + + + + + + +``` + +```xml + + + true + net6.0 + + + + + +``` + +When you use the pack command to create a package, both packages will appear in the dependency group. + +```xml + + + + +``` + +Because of this, the use of transitive pinning should be carefully evaluated when authoring a library, as it may lead to dependencies you did not expect. + +## Overriding Package Versions + +You can override an individual package version by using the `VersionOverride` property on a `` item. +This will take precedence over any centrally defined ``. + +```xml + + + + + + +``` + +```xml + + + net6.0 + + + + + +``` + +You can disable this feature by setting the MSBuild property `CentralPackageVersionOverrideEnabled` to `false` in a project or in a `Directory.Packages.props` or `Directory.Build.props` import file: + +```xml + + false + +``` + +When this feature is disabled, specifying a `VersionOverride` on any `` item will result in an error at restore time indicating that the feature is disabled. + +## Disabling Central Package Management + +To disable Central Package Management for a specific project, set the MSBuild property `ManagePackageVersionsCentrally` to `false`: + +```xml + + false + +``` + +## Global Package References + +> [!NOTE] +> This feature is only available in Visual Studio 2022 17.4 or higher, .NET SDK 7.0.100.preview7 or higher, and NuGet 6.4 or higher. + +A global package reference is used to specify that a package will be used by every project in a repository. +This includes packages that do versioning, extend your build, or any other packages that are needed by all projects. +Global package references are added to the PackageReference item group with the following metadata: + +* `IncludeAssets="Runtime;Build;Native;contentFiles;Analyzers"`
+ This ensures that the package is only used as a development dependency and prevents it from being included as a compile-time assembly reference. +* `PrivateAssets="All"`
+ This prevents global package references from being picked up by downstream dependencies. + +`GlobalPackageReference` items should be placed in your `Directory.Packages.props` to be used by every project in a repository: + +```xml + + + + + +``` + +## NU1507 Warning When Using Multiple Package Sources + +When using Central Package Management, NuGet will log an [`NU1507`](../reference/errors-and-warnings/nu1507.md) warning if more than one package source is defined in your configuration. +To resolve this warning, map your package sources with [package source mapping](https://aka.ms/nuget-package-source-mapping) or specify a single package source. + +``` +There are 3 package sources defined in your configuration. When using Central Package Management, please map your package sources with package source mapping (https://aka.ms/nuget-package-source-mapping) or specify a single package source. +``` diff --git a/docs/consume-packages/Finding-and-Choosing-Packages.md b/docs/consume-packages/Finding-and-Choosing-Packages.md index 31c354e19..7b00fcd89 100644 --- a/docs/consume-packages/Finding-and-Choosing-Packages.md +++ b/docs/consume-packages/Finding-and-Choosing-Packages.md @@ -1,135 +1,202 @@ --- -title: Finding and Choosing NuGet Packages -description: An overview of how to find and choose the best NuGet packages for a project including details on the NuGet search syntax. -author: karann-msft -ms.author: karann -ms.date: 06/04/2018 +title: Find and evaluate NuGet packages +description: Find and evaluate publicly available NuGet packages for your project by using advanced nuget.org search filters and syntax. +author: JonDouglas +ms.author: jodou +ms.date: 03/03/2025 ms.topic: conceptual --- -# Finding and evaluating NuGet packages for your project +# Find and evaluate NuGet packages for your project -When starting any .NET project, or whenever you identify a functional need for your app or service, you can save yourself lots of time and trouble by using existing NuGet packages that fulfill that need. These packages can come from the public collection on [nuget.org](http://www.nuget.org/packages/), or a private source that's provided by your organization or another third party. +When you start a .NET project, or identify a functional need in your app or service, you can often install existing NuGet packages to save the time and trouble of [creating your own packages](../create-packages/overview-and-workflow.md). Existing packages can come from the [nuget.org](https://www.nuget.org/packages) public collection, or from private sources that your organization or another party provide. -## Finding packages +## Find packages -When you visit nuget.org or open the Package Manager UI in Visual Studio, you see a list of packages sorted by total downloads. This immediately shows you the most widely-used packages across the millions of .NET projects. There's a good chance, then, that at least some of the packages listed on the first few pages will be useful in your projects. +You can find packages directly at [https://nuget.org/packages](https://www.nuget.org/packages), or from the [Visual Studio Package Manager UI](install-use-packages-visual-studio.md) or [Package Manager Console](install-use-packages-powershell.md) with nuget.org as a source. All packages from nuget.org are routinely scanned for viruses. -![Default view of nuget.org/packages showing the most popular packages](media/Finding-01-Popularity.png) +At [nuget.org/packages](https://www.nuget.org/packages), you see a list of NuGet packages with the most popular packages across all .NET projects listed first. Some of these packages might be useful for your projects. -Notice the **Include prerelease** option on the upper right of the page. When selected, nuget.org shows all versions of packages including beta and other early releases. To show only stable released, clear the option. +![Screenshot that shows the default view of nuget.org/packages with the most popular packages at the top.](media/Finding-07-MostPopular.png) -For specific needs, searching by tags (within the Visual Studio Package Manager or on a portal like nuget.org) is the most common means of discovering a suitable package. For example, searching on "json" lists all NuGet packages that are tagged with that keyword and thus have some relationship to the JSON data format. +To search for a package, enter the package name or search terms in the Search box at the top of the page. You can use [advanced search syntax](#search-syntax) to filter your search. -![Search results for 'json' on nuget.org](media/Finding-02-SearchResults.png) +### Advanced filtering and sorting -You can also search using the package ID, if you know it. See [Search Syntax](#search-syntax) below. +At nuget.org/packages, you can refine your search results by making use of the advanced filtering and sorting options. -At this time, search results are sorted only by relevance, so you generally want to look through at least the first few pages of results for packages that suit your needs, or refine your search terms to be more specific. +![Screenshot that shows the filtering and sorting options on nuget.org.](media/Finding-08-FiltersAndSorts.png) -### Does the package support my project's target framework? +Use the **Frameworks** filters to show packages targeting specific .NET frameworks (To learn more, see [Target Frameworks](/dotnet/standard/frameworks)): -NuGet installs a package into a project only if that package's supported frameworks include the project's target framework. If the package is not compatible, NuGet issues an error. +- Selecting one of the .NET framework generation checkboxes would filter the search results to packages compatible with any of the individual Target Frameworks within that generation. For example, selecting `.NET` will return packages compatible with any of the modern .NET frameworks, including `net5.0` through `net8.0`. -Some packages list their supported frameworks directly in the nuget.org gallery, but because such data is not required, many packages do not include that list. At present there is no means to search nuget.org for packages that support a specific target framework (the feature is under consideration, see [NuGet Issue 2936](https://github.com/NuGet/NuGetGallery/issues/2936)). + ![Screenshot that shows the Framework filters on nuget.org.](media/Finding-09-FrameworkFilterPanel.png) -Fortunately, you can determine supported frameworks through two other means: +- Expanding one of these framework generations with the arrows on the right will show you individual Target Framework Monikers (TFMs) that you can filter your results by. For example, selecting `net5.0` will return packages compatible with the '.NET 5.0' framework. +- By default, packages are filtered by their expanded list of computed compatible frameworks. If you want to filter packages purely by the asset frameworks they explicitly target, deselect the **Include compatible frameworks** checkbox. +- Combining multiple framework filters will show you search results that match all of your selected filters, i.e. packages that fall in the intersection of your selections. For example, selecting `netcoreapp3.1` and `net45` together will show packages that target **both** '.NET Core 3.1' and '.NET Framework 4.5'. Selecting the `.NET Core` framework generation checkbox and the `net45` checkbox together will return packages that target '.NET Framework 4.5', and at least one of the '.NET Core' TFMs (`netcoreapp1.0` through `netcoreapp3.1`). + - Alternatively, if you want to see packages matching **any one** of your framework filters, select the **Any** radio button on the **Framework Filter Mode** option. Now, selecting `netcoreapp3.1` and `net5.0` will show packages that target **either** '.NET Core 3.1' or '.NET 5.0'. Selecting the `netcoreapp3.1` checkbox and the `.NET` framework generation checkbox together will return packages that target '.NET Core 3.1' or any one of the '.NET' TFMs (`net5.0` through `net8.0`). +- You can learn more on how to evaluate a package's supported frameworks and its compatibility with your project [here](#determine-supported-frameworks). -1. Attempt to install a package into a project using the [`Install-Package`](../reference/ps-reference/ps-ref-install-package.md) command in the NuGet Package Manager Console. If the package is incompatible, this command shows you the package's supported frameworks. +Use the **Package type** filter to show packages of a specific type: -1. Download the package from its page on nuget.org using the **Manual download** link under **Info**. Change the extension from `.nupkg` to `.zip`, and open the file to examine the content of its `lib` folder. There you see subfolders for each of the supported frameworks, where each subfolder is named with a target framework moniker (TFM; see [Target Frameworks](../reference/target-frameworks.md)). If you see no subfolders under `lib` and only a single DLL, then you must attempt to install the package in your project to discover its compatibility. +- **All types** is the default and shows all packages regardless of type. +- **Dependency** filters to regular NuGet packages that you can install into your project. +- **.NET tool** filters to [.NET tools](/dotnet/core/tools/global-tools) packages that contain console applications. +- **Template** filters to [.NET templates](/dotnet/core/install/templates) that you can use to create new projects with the [dotnet new](/dotnet/core/tools/dotnet-new) command. -## Pre-release packages +By default, NuGet lists all versions of packages, including prerelease and beta versions. In the **Options** section, deselect the **Include prerelease** checkbox to list only stable, released package versions. -Many package authors make preview and beta releases available as they continue to make improvements and seek feedback on their latest revisions. +To apply changes, select **Apply**. To get back to the defaults, select **Reset**. -By default, nuget.org shows pre-release packages in search results. To search only stable releases, clear the **Include prerelease** option on the upper right of the page +Use the **Sort by** dropdown on the top-right of the page to sort the list by several criteria: -![Include prerelease checkbox on nuget.org](media/Finding-06-include-prerelease.png) +- **Relevance** is the default, and sorts results according to an internal scoring algorithm. +- **Downloads** sorts the search results by the total number of downloads, in descending order. +- **Recently updated** sorts the search results by the latest package version creation date, in descending chronological order. -In Visual Studio, and when using the NuGet and dotnet CLI tools, NuGet does not include pre-release versions by default. To change this behavior, do the following steps: +### Search syntax -- **Package Manager UI in Visual Studio**: In the **Manage NuGet Packages** UI, set the **Include prerelease** box. Setting or clearing this box refreshes the Package Manager UI and the list of available versions you can install. +Package search queries at nuget.org, from the NuGet CLI, and from within Visual Studio all use the same syntax. Other package sources, like Azure Artifacts or GitHub Package Repository, might use different syntax or might not support advanced filtering. - ![The Include prerelease checkbox in Visual Studio](media/Prerelease_02-CheckPrerelease.png) +- You can search the package `id`, `packageid`, `version`, `title`, `tags`, `author`, `description`, `summary`, or `owner` properties by using the syntax `:`. -- **Package Manager Console**: Use the `-IncludePrerelease` switch with the `Find-Package`, `Get-Package`, `Install-Package`, `Sync-Package`, and `Update-Package` commands. Refer to the [PowerShell Reference](../reference/powershell-reference.md). +- Search applies to keywords and descriptions, and is case-insensitive. For example, the following strings all search the `id` property for the string `nuget.core`: -- **nuget.exe CLI**: Use the `-prerelease` switch with the `install`, `update`, `delete`, and `mirror` commands. Refer to the [NuGet CLI reference](../reference/nuget-exe-cli-reference.md) + `id:NuGet.Core`
`ID:nuget.core`
`Id:NUGET.CORE` -- **dotnet.exe CLI**: Specify the exact pre-release version using the `-v` argument. Refer to the [dotnet add package reference](/dotnet/core/tools/dotnet-add-package). +- Searches on the `id` property match substrings, while `packageid` and `owner` use exact, case-insensitive matches. For example: - + `PackageId:jquery` searches for the exact package ID `jquery`.
`Id:jquery` searches for all package IDs that contain the string `jquery`. + +- You can search for multiple values or properties at the same time. For example: + + `id:jquery id:ui` searches for multiple terms in the `id` property.
`id:jquery tags:validation` searches for multiple properties. + +- Search ignores unsupported properties, so `invalid:jquery ui` is the same as searching for `ui`, and `invalid:jquery` returns all packages. + +### Determine supported frameworks + +NuGet installs a package into a project only if the package's supported .NET frameworks include the project's target frameworks. If the package isn't compatible, NuGet issues an error. + +There are several ways to determine the frameworks that a package supports: + +- On the search page, a package's supported frameworks will appear as badges below the package ID. These badges show the lowest supported framework versions from the **.NET**, **.NET Core**, **.NET Standard**, and **.NET Framework** generations. The package will be compatible with any framework version that's equal to or higher than the badge version shown. + + 'Dark blue' badges represent explicitly targeted frameworks, while 'light blue' badges represent computed compatible frameworks. + + Clicking on a badge will redirect you to the package's details page on nuget.org. The **Frameworks** tab on the package's page will show the full list of supported frameworks. + + ![Screenshot of the Framework badges on nuget.org's search page.](media/Finding-10-FrameworkBadgesInSearch.png) + +- On the package's page at nuget.org, supported frameworks appear below the package ID and on the **Frameworks** tab, but not all packages show supported frameworks. + + ![Screenshot of the Frameworks UI and tab on the package page at nuget.org.](media/supported-frameworks.png) + +- Download the package manually by selecting **Download package** under **About**. Change the file extension of the downloaded package from *.nupkg* to *.zip*, open the *.zip* folder, and examine its *lib* folder. There are subfolders for each supported framework, each named with a target framework moniker (TFM). For more information, see [Target Frameworks](../reference/target-frameworks.md). If there aren't any subfolders under *lib* and there's only a single DLL, try to install the package to discover its compatibility. + +- Try to install the package into a project by using [Install-Package](../reference/ps-reference/ps-ref-install-package.md) in the Visual Studio Package Manager Console. If the package is incompatible, the console output shows the package's supported frameworks. +### Prerelease packages + +Many package authors provide preview and beta releases as they continue to improve and seek feedback on latest revisions. By default, nuget.org shows prerelease packages in its package list and search results. + +To list and search only stable releases: + + - At nuget.org, deselect the **Include prerelease** checkbox in the advanced search panel. + - In the Visual Studio NuGet Package Manager UI, deselect the **Include prerelease** checkbox next to the Search box. + +The Visual Studio Package Manager Console, NuGet CLI, and dotnet CLI tools don't include prerelease versions by default. To include prerelease versions: + +- In the Package Manager Console, use the `-IncludePrerelease` switch with the `Find-Package`, `Get-Package`, `Install-Package`, `Sync-Package`, and `Update-Package` commands. For more information, see the [PowerShell Reference](../reference/powershell-reference.md). + +- For the NuGet CLI, use the `-prerelease` switch with the `install`, `update`, `delete`, and `mirror` commands. For more information, see the [NuGet CLI reference](../reference/nuget-exe-cli-reference.md). + +- For the dotnet CLI, specify a prerelease version with the `-v` argument. For more information, see the [dotnet add package reference](/dotnet/core/tools/dotnet-add-package). + + ### Native C++ packages -NuGet supports native C++ packages can that can be used in C++ projects in Visual Studio. This enables the **Manage NuGet Packages** context-menu command for projects, introduces a `native` target framework, and provides MSBuild integration. +Visual Studio C++ projects can use native C++ NuGet packages. Installing these packages enable the **Manage NuGet Packages** context-menu command, exposes a `native` target framework, and provides MSBuild integration. + +To find native packages on nuget.org/packages, search by using `tag:native`. Such packages typically provide *.targets* and *.props* files, which NuGet imports automatically when adding the packages. + +## Evaluate packages + +The best way to evaluate a package's usefulness is to try it out. You take a dependency on a package when you use it, so you must make sure it's robust and reliable. However, installing a package and directly testing it is time-consuming. You can learn a lot about a package's quality by using the information on the package's page at nuget.org/packages. + +- The **Prefix Reserved** checkmark next to the package ID on the packages list and the package page means the package owners have applied for and been granted a [reserved package ID prefix](../nuget-org/id-prefix-reservation.md). To meet the [ID prefix reservation criteria](../nuget-org/id-prefix-reservation.md#id-prefix-reservation-criteria), package owners must clearly identify themselves and their packages. + + ![Screenshot that shows Prefix Reserved on a package's page.](media/prefix-reserved.png) + +- **Downloads** in the package page's right column shows **Total**, **Current version**, and **Per day average** downloads. Large numbers indicate that the package has proven itself among many developers. -To find native packages on [nuget.org](https://www.nuget.org/packages), search using `tag:native`. Such packages typically provide `.targets` and `.props` files, which NuGet imports automatically when the package is added to a project. + ![Screenshot that shows Download statistics on a package's page.](media/Finding-03-Downloads.png) + + Select **Full stats** next to **Downloads** to see a page that shows package downloads for the past six weeks by version number. Versions that more developers are using are typically better choices. -## Evaluating packages +- The **Used By** tab on the package page shows the top five most popular nuget.org packages and GitHub repositories that depend on this package. Packages and repos that depend on this package are called *dependents*. Dependent packages and repos can be seen as endorsing this package, because they chose to trust and depend on it. -The best way to evaluate the usefulness of a package is to download it and try it out in your code (all packages on nuget.org are routinely scanned for viruses, by the way). After all, every highly popular package got started with only a few developers using it, and you might be one of the early adopters! + ![Screenshot that shows the Used By list.](media/Used-By-section-Humanizer.png) + + The *latest stable version* of a dependent package must depend on any version of this package. This definition ensures that listed dependent packages are an up-to-date reflection of package authors' decisions to trust and depend on the package. The dependents list doesn't show prerelease dependents, because they're not considered wholehearted endorsements yet. The following examples show which packages show as dependents: -At the same time, using a NuGet package means taking a dependency on it, so you want to make sure it's robust and reliable. Because installing and directly testing a package is time-consuming, you can also learn a lot about a package's quality by using the information on a package's listing page: + | Dependent package version | Dependent package listed as a dependent? | + |-|-| + | v1.0.0
v1.1.0 (latest stable) depends on this package
v1.2.0-preview | TRUE, latest stable version depends on this package | + | v1.0.0 depends on this package
v1.1.0 (latest stable)
v1.2.0-preview | FALSE, latest stable version doesn't depend on this package | + | v1.0.0 depends on this package
v1.1.0 (latest stable)
v1.2.0-preview depends on this package | FALSE, latest stable version doesn't depend on this package | -- *Downloads statistics*: on the package page on nuget.org, the **Statistics** section shows total downloads, downloads of the most recent version, and average downloads per day. Larger numbers indicate that many other developers have taken a dependency on the package, which means that it has proven itself. + The number of stars for a GitHub repository indicates its popularity with GitHub users. For more information about the GitHub star and repository ranking system, see [About stars](https://help.github.com/github/getting-started-with-github/saving-repositories-with-stars#about-stars). - ![Download statistics on a package's listing page](media/Finding-03-Downloads.png) + > [!Note] + > The **Used By** section is automatically generated periodically, without human review, and solely for informational purposes. -- *Version history*: on the package page, look under **Info** for the date of the most recent update and examine the **Version History**. A well-maintained package has recent updates and a rich version history. Neglected packages have few updates and often haven't been updated in some time. +- The **Versions** tab on the package page shows the **Versions**, **Downloads**, **Last Updated** dates, and serious vulnerabilities of package versions. The version you install shouldn't have any high-severity vulnerabilities. A well-maintained package has recent updates and a long version history. Neglected packages have few and long-ago updates. - ![Version history on a package's listing page](media/Finding-04-VersionHistory.png) + ![Screenshot that shows the Versions list.](media/Finding-04-VersionHistory.png) -- *Recent installs*: on the package page under **Statistics**, select **View full stats**. The full stats page shows the package installs over the last six weeks by version number. A package that other developers are actively using is typically a better choice than one that's not. +The right column of the package page has other informative links: -- *Support*: on the package page under **Info**, select **Project Site** (if available) to see what support options the author provides. A project with a dedicated site is generally better supported. +:::row::: + :::column span=""::: +![Screenshot that shows the right column of the package page.](media/right-column.png) + :::column-end::: + :::column span="2"::: +- Select **Project website**, if available, to see what support options the author provides. A project with a dedicated site is generally well supported. -- *Developer history*: on the package page under **Owners**, select an owner to see what other packages they've published. Those with multiple packages are more likely to continue supporting their work in the future. +- Select **Source repository** to go to the Git source code repository for the package. Many authors maintain their packages in open-source repositories, so users can directly contribute bug fixes and feature improvements. The package's contribution history is a good indicator of how many developers are actively involved. -- *Open source contributions*: many packages are maintained in open-source repositories, making it possible for developers depending on them to directly contribute bug fixes and feature improvements. The contribution history of any given package is also a good indicator of how many developers are actively involved. +- Select **\ license** to see the package's MIT or other license. If a package doesn't specify license terms, contact the package owner. -- *Interview the owners*: new developers can certainly be equally committed to producing great packages for you to use, and it's good to give them a chance to bring something new to the NuGet ecosystem. With this in mind, reach out directly to the package developers through the **Contact Owners** option under **Info** on the listing page. Chances are, they'll be happy to work with you to serve your needs! +- Select any of the package owners under **Owners** to see other packages they've published. Owners with multiple packages are more likely to continue supporting their work. Select **Contact owners** next to **Owners** to reach out directly to the package developers. -- *Reserved Package ID Prefixes*: many package owners have applied for and have been granted a [reserved package ID prefix](../nuget-org/id-prefix-reservation.md). When you see the visual checkmark next to a package ID on [nuget.org](https://www.nuget.org/), or in Visual Studio, that means that the package owner has met our [criteria](../nuget-org/id-prefix-reservation.md#id-prefix-reservation-criteria) for ID prefix reservation. This means the package owner is being clear on identifying themselves and their package. + :::column-end::: +:::row-end::: -> [!Note] -> Always be mindful of a package's license terms, which you can see by selecting **License Info** on a package's listing page on nuget.org. If a package does not specify license terms, contact the package owner directly using the **Contact owners** link on the package page. Microsoft does not license any intellectual property to you from third party package providers and is not responsible for information provided by third parties. +## Retrieve license information -## License URL deprecation -As we transition from [licenseUrl](../reference/nuspec.md#licenseurl) to [license](../reference/nuspec.md#license), some NuGet clients and NuGet feeds may not yet have the ability to surface licensing information in some cases. To maintain backward compatibility, the license URL points to this document which talks about how to retrieve the license information in such cases. +Some NuGet clients and NuGet feeds might not be able to surface licensing information. To maintain backward compatibility in such cases, the license URL points to this document about how to retrieve the license information. -If clicking on the license URL for a package brought you to this page, it implies the package contains a license file and -* You are connected to a feed that does not yet know how to interpret and surface the new license information to the client -**OR** -* You are using a client that does not yet know how to interpret and read the new license information that is potentially provided by the feed -**OR** -* A combination of both +If selecting the license URL for a package brings you to this page, it implies the package contains a license file and: -Here is how you could read the information contained in the license file inside the package: -1. Download the NuGet package, and unzip its contents to a folder. -1. Open the `.nuspec` file which would be at the root of that folder. -1. It should have a tag like `license\license.txt`. This implies the license file is named `license.txt` and it is inside a folder called `license` which would also be at the root of that folder. -1. Navigate to the `license` folder and open the `license.txt` file. +- You're connected to a feed that doesn't know how to interpret and surface the license information to the client, or +- You're using a client that doesn't know how to interpret and read the license information the feed provides, or +- A combination of both of these scenarios. +To read the information in the license file inside the package: -## Search Syntax +1. Manually download the package, and unzip its contents to a folder. +1. Open the *.nuspec* file at the root of the folder. +1. Examine the `` tag, such as `license\license.txt`. The example tag states that the license file is named *license.txt* and is inside a subfolder called *license*. +1. Navigate to the specified location and open the specified file. -NuGet package search works the same on nuget.org, from the NuGet CLI, and within the NuGet Package Manager extension in Visual Studio. In general, search is applied to keywords as well as package descriptions. +For information about the MSBuild equivalent to setting the license in the *.nuspec*, see [Packing a license expression or a license file](../reference/msbuild-targets.md#packing-a-license-expression-or-a-license-file). -- **Keywords**: Search looks for relevant packages that contain any of the provided keywords. Example: `modern UI`. To search for packages that contain all of the provided keywords, use "+" between the terms, such as `modern+UI`. -- **Phrases**: Entering terms within quotation marks looks for exact case-insensitive matches to those terms. Example: `"modern UI" package` -- **Filtering**: You can apply a search term to a specific property by using the syntax `:` where `` (case-insensitive) can be `id`, `packageid`, `version`, `title`, `tags`, `author`, `description`, `summary`, and `owner`. Terms can be contained in quotes if needed, and you can search for multiple properties at the same time. Also, searches on the `id` property are substring matches, whereas `packageid` uses an exact match. Examples: +## Next steps - ``` - id:NuGet.Core # Match any part of the id property - Id:"Nuget.Core" - ID:jQuery - title:jquery # Searches title as shown on the package listing - PackageId:jquery # Match the package id exactly - id:jquery id:ui # Search for multiple terms in the id - id:jquery tags:validation # Search multiple properties - id:"jquery.ui" # Phrase search - invalid:jquery ui # Unsupported properties are ignored, so this - # is the same as searching on jquery ui - ``` +- [Ways to install a NuGet package](overview-and-workflow.md#ways-to-install-a-nuget-package) +- [Install and manage packages in Visual Studio using the NuGet Package Manager](install-use-packages-visual-studio.md) +- [Install and manage packages with the Package Manager Console in Visual Studio](install-use-packages-powershell.md) +- [Install and manage packages with the dotnet CLI](install-use-packages-dotnet-cli.md) diff --git a/docs/consume-packages/Overview-and-Workflow.md b/docs/consume-packages/Overview-and-Workflow.md index 32cca6406..4c47052ab 100644 --- a/docs/consume-packages/Overview-and-Workflow.md +++ b/docs/consume-packages/Overview-and-Workflow.md @@ -1,8 +1,8 @@ --- title: Overview and workflow of using NuGet packages description: An overview of the process of consuming NuGet packages in a project, with links to other specific parts of the process. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 03/22/2018 ms.topic: conceptual --- @@ -24,25 +24,25 @@ NuGet remembers the identity and version number of each installed package, recor When installing packages, NuGet typically checks if the package is already available from its cache. You can manually clear this cache from the command line, as described on [Managing the global packages and cache folders](../consume-packages/managing-the-global-packages-and-cache-folders.md). -NuGet also makes sure that the target frameworks supported by the package are compatible with your project. If the package does not contain compatible assemblies, NuGet displays an error. See [Resolving incompatible package errors](dependency-resolution.md#resolving-incompatible-package-errors). +NuGet also makes sure that the target frameworks supported by the package are compatible with your project. If the package does not contain compatible assemblies, NuGet displays an error. See [Resolving incompatible package errors](../concepts/dependency-resolution.md#resolving-incompatible-package-errors). When adding project code to a source repository, you typically don't include NuGet packages. Those who later clone the repository or otherwise acquire the project, including build agents on systems like Visual Studio Team Services, must restore the necessary packages prior to running a build: ![Flow of restoring NuGet packages by cloning a repository and using either a restore command](media/Overview-02-RestoreFlow.png) -[Package Restore](../consume-packages/package-restore.md) uses the information in the project file or `packages.config` to reinstall all dependencies. Note that there are differences in the process involved, as described in [Dependency Resolution](../consume-packages/dependency-resolution.md). Also, the diagram above does not show a restore command for the Package Manager Console because if you're with the Console you're already in the context of Visual Studio, which typically restores packages automatically and provides the solution-level command as shown. +[Package Restore](../consume-packages/package-restore.md) uses the information in the project file or `packages.config` to reinstall all dependencies. Note that there are differences in the process involved, as described in [Dependency Resolution](../concepts/dependency-resolution.md). Also, the diagram above does not show a restore command for the Package Manager Console because if you're with the Console you're already in the context of Visual Studio, which typically restores packages automatically and provides the solution-level command as shown. Occasionally it's necessary to reinstall packages that are already included in a project, which may also reinstall dependencies. This is easy to do using the `nuget reinstall` command or the NuGet Package Manager Console. For details, see [Reinstalling and Updating Packages](../consume-packages/reinstalling-and-updating-packages.md). -Finally, NuGet's behavior is driven by `Nuget.Config` files. Multiple files can be used to centralize certain settings at different levels, as explained in [Configuring NuGet Behavior](../consume-packages/configuring-nuget-behavior.md). +Finally, NuGet's behavior is driven by `NuGet.Config` files. Multiple files can be used to centralize certain settings at different levels, as explained in [Configuring NuGet Behavior](../consume-packages/configuring-nuget-behavior.md). ## Ways to install a NuGet Package NuGet packages are downloaded and installed using any of the methods in the following table. -| Tool | Description | -| --- | --- | -| [dotnet.exe CLI](install-use-packages-dotnet-cli.md) | (All platforms) CLI tool for .NET Core and .NET Standard libraries, and for SDK-style projects that target .NET Framework (see [SDK attribute](/dotnet/core/tools/csproj#additions)). Retrieves the package identified by \ and adds a reference to the project file. Also retrieves and installs dependencies. | -| Visual Studio | (Windows and Mac) Provides a UI through which you can browse, select, and install packages and their dependencies into a project from a specified package source. Adds references to installed packages to the project file.
  • [Install and manage packages using Visual Studio](install-use-packages-visual-studio.md)
  • [Including a NuGet package in your project (Mac)](/visualstudio/mac/nuget-walkthrough)
| -| [Package Manager Console (Visual Studio)](install-use-packages-powershell.md) | (Windows only) Retrieves and installs the package identified by \ from a selected source into a specified project in the solution, then adds a reference to the project file. Also retrieves and installs dependencies. | -| [nuget.exe CLI](install-use-packages-nuget-cli.md) | (All platforms) CLI tool for .NET Framework libraries and non-SDK-style projects that target .NET Standard libraries. Retrieves the package identified by \ and expands its contents into a folder in the current directory; can also retrieve all packages listed in a `packages.config` file. Also retrieves and installs dependencies, but makes no changes to project files or `packages.config`. | +| Tool | Platforms | Description | +| --- | --- | --- | +| [dotnet CLI](install-use-packages-dotnet-cli.md) | All | CLI tool for .NET Core and .NET Standard libraries, and for SDK-style projects that target .NET Framework (see [SDK attribute](/dotnet/core/tools/csproj#additions)). Retrieves the package identified by \ and adds a reference to the project file. Also retrieves and installs dependencies. | +| Visual Studio | Windows and Mac | Provides a UI through which you can browse, select, and install packages and their dependencies into a project from a specified package source. Adds references to installed packages to the project file.
  • [Install and manage packages using Visual Studio](install-use-packages-visual-studio.md)
  • [Including a NuGet package in your project (Mac)](/visualstudio/mac/nuget-walkthrough)
| +| [Package Manager Console (Visual Studio)](install-use-packages-powershell.md) | Windows only | Retrieves and installs the package identified by \ from a selected source into a specified project in the solution, then adds a reference to the project file. Also retrieves and installs dependencies. | +| [nuget.exe CLI](install-use-packages-nuget-cli.md) | All | CLI tool for .NET Framework libraries and non-SDK-style projects that target .NET Standard libraries. Retrieves the package identified by \ and expands its contents into a folder in the current directory; can also retrieve all packages listed in a `packages.config` file. Also retrieves and installs dependencies, but makes no changes to project files or `packages.config`. | diff --git a/docs/consume-packages/Package-References-in-Project-Files.md b/docs/consume-packages/Package-References-in-Project-Files.md index f00d017cb..c005f5e97 100644 --- a/docs/consume-packages/Package-References-in-Project-Files.md +++ b/docs/consume-packages/Package-References-in-Project-Files.md @@ -1,23 +1,23 @@ --- -title: NuGet PackageReference format (package references in project files) +title: NuGet PackageReference in project files description: Details on NuGet PackageReference in project files as supported by NuGet 4.0+ and VS2017 and .NET Core 2.0 -author: karann-msft -ms.author: karann -ms.date: 03/16/2018 +author: nkolev92 +ms.author: nikolev +ms.date: 4/6/2022 ms.topic: conceptual --- -# Package references (PackageReference) in project files +# `PackageReference` in project files -Package references, using the `PackageReference` node, manage NuGet dependencies directly within project files (as opposed to a separate `packages.config` file). Using PackageReference, as it's called, doesn't affect other aspects of NuGet; for example, settings in `NuGet.config` files (including package sources) are still applied as explained in [Common NuGet configurations](configuring-nuget-behavior.md). +Package references, using `` MSBuild items, specify NuGet package dependencies directly within project files, as opposed to having a separate `packages.config` file. Use of PackageReference doesn't affect other aspects of NuGet; for example, settings in `NuGet.Config` files (including package sources) are still applied as explained in [Common NuGet configurations](configuring-nuget-behavior.md). -With PackageReference, you can also use MSBuild conditions to choose package references per target framework, configuration, platform, or other groupings. It also allows for fine-grained control over dependencies and content flow. (See For more details [NuGet pack and restore as MSBuild targets](../reference/msbuild-targets.md).) +With PackageReference, you can also use MSBuild conditions to choose package references per target framework, or other groupings. It also allows for fine-grained control over dependencies and content flow. (For more information, see [NuGet pack and restore as MSBuild targets](../reference/msbuild-targets.md).) ## Project type support -By default, PackageReference is used for .NET Core projects, .NET Standard projects, and UWP projects targeting Windows 10 Build 15063 (Creators Update) and later, with the exception of C++ UWP projects. .NET Framework projects support PackageReference, but currently default to `packages.config`. To use PackageReference, [migrate](../reference/migrate-packages-config-to-package-reference.md) the dependencies from `packages.config` into your project file, then remove packages.config. +By default, PackageReference is used for .NET projects, .NET Standard projects, and UWP projects targeting Windows 10 Build 15063 (Creators Update) and later, with the exception of C++ UWP projects. .NET Framework projects support PackageReference, but currently default to `packages.config`. To use PackageReference in a .NET Framework project, [migrate](../consume-packages/migrate-packages-config-to-package-reference.md) the dependencies from `packages.config` into your project file, then remove packages.config. -ASP.NET apps targeting the full .NET Framework include only [limited support](https://github.com/NuGet/Home/issues/5877) for PackageReference. C++ and JavaScript project types are unsupported. +ASP.NET apps that target the full .NET Framework include only [limited support](https://github.com/NuGet/Home/issues/5877) for PackageReference. C++ and JavaScript project types are unsupported. ## Adding a PackageReference @@ -43,10 +43,12 @@ The convention for specifying the version of a package is the same as when using ``` -In the example above, 3.6.0 means any version that is >=3.6.0 with preference for the lowest version, as described on [Package versioning](../reference/package-versioning.md#version-ranges-and-wildcards). +In the example above, 3.6.0 means any version that is >=3.6.0 with preference for the lowest version, as described in [Package versioning](../concepts/package-versioning.md#version-ranges). + +## Using PackageReference for a project with no package dependencies -## Using PackageReference for a project with no PackageReferences Advanced: If you have no packages installed in a project (no PackageReferences in project file and no packages.config file), but want the project to be restored as PackageReference style, you can set a Project property RestoreProjectStyle to PackageReference in your project file. + ```xml @@ -54,17 +56,22 @@ Advanced: If you have no packages installed in a project (no PackageReferences i ``` -This may be useful, if you reference projects which are PackageReference styled (existing csproj or SDK-style projects). This will enable packages that those projects refer to, to be "transitively" referenced by your project. + +This might be useful if you reference projects that are PackageReference styled (existing csproj or SDK-style projects). This will enable packages that those projects refer to, to be "transitively" referenced by your project. + +## PackageReference and sources + +In PackageReference projects, the transitive dependency versions are resolved at restore time. As such, in PackageReference projects, all sources need to be available for all restores. ## Floating Versions -[Floating versions](../consume-packages/dependency-resolution.md#floating-versions) are supported with `PackageReference`: +[Floating versions](../concepts/dependency-resolution.md#floating-versions) are supported with `PackageReference`: ```xml - + ``` @@ -87,48 +94,58 @@ You might be using a dependency purely as a development harness and might not wa The following metadata tags control dependency assets: -| Tag | Description | Default Value | -| --- | --- | --- | -| IncludeAssets | These assets will be consumed | all | -| ExcludeAssets | These assets will not be consumed | none | +| Tag | Description | Default Value | +|---------------|--------------------------------------------------------------------|------------------------------| +| IncludeAssets | These assets will be consumed | all | +| ExcludeAssets | These assets will not be consumed | none | | PrivateAssets | These assets will be consumed but won't flow to the parent project | contentfiles;analyzers;build | -Allowable values for these tags are as follows, with multiple values separated by a semicolon except with `all` and `none` which must appear by themselves: +Allowable values for these tags are as follows, with multiple values separated by a semicolon except for `all` and `none`, which must appear by themselves: | Value | Description | | --- | --- | compile | Contents of the `lib` folder and controls whether your project can compile against the assemblies within the folder | | runtime | Contents of the `lib` and `runtimes` folder and controls whether these assemblies will be copied out to the build output directory | | contentFiles | Contents of the `contentfiles` folder | -| build | Props and targets in the `build` folder | +| build | `.props` and `.targets` in the `build` folder | +| buildMultitargeting | *(4.0)* `.props` and `.targets` in the `buildMultitargeting` folder, for cross-framework targeting | +| buildTransitive | *(5.0+)* `.props` and `.targets` in the `buildTransitive` folder, for assets that flow transitively to any consuming project. See the [feature](https://github.com/NuGet/Home/wiki/Allow-package--authors-to-define-build-assets-transitive-behavior) page. | | analyzers | .NET analyzers | | native | Contents of the `native` folder | | none | None of the above are used. | | all | All of the above (except `none`) | -In the following example, everything except the content files from the package would be consumed by the project and everything except content files and analyzers would flow to the parent project. - ```xml - + + - all + all contentFiles contentFiles;analyzers - + + + + + compile + contentFiles + ``` Note that because `build` is not included with `PrivateAssets`, targets and props *will* flow to the parent project. Consider, for example, that the reference above is used in a project that builds a NuGet package called AppLogger. AppLogger can consume the targets and props from `Contoso.Utility.UsefulStuff`, as can projects that consume AppLogger. +> [!NOTE] +> When `developmentDependency` is set to `true` in a `.nuspec` file, this marks a package as a development-only dependency, which prevents the package from being included as a dependency in other packages. With PackageReference *(NuGet 4.8+)*, this flag also means that it will exclude compile-time assets from compilation. For more information, see [DevelopmentDependency support for PackageReference](https://github.com/NuGet/Home/wiki/DevelopmentDependency-support-for-PackageReference). + ## Adding a PackageReference condition -You can use a condition to control whether a package is included, where conditions can use any MSBuild variable or a variable defined in the targets or props file. However, at presently, only the `TargetFramework` variable is supported. +You can use a condition to control whether a package is included. Conditions can use any MSBuild variable or a variable defined in the targets or props file. However, at present, only the `TargetFramework` variable is supported. -For example, say you're targeting `netstandard1.4` as well as `net452` but have a dependency that is applicable only for `net452`. In this case you don't want a `netstandard1.4` project that's consuming your package to add that unnecessary dependency. To prevent this, you specify a condition on the `PackageReference` as follows: +For example, say you're targeting `netstandard1.4` as well as `net452` but have a dependency that's applicable only for `net452`. In this case you don't want a `netstandard1.4` project that consumes your package to add that unnecessary dependency. To prevent this, you specify a condition on the `PackageReference` as follows: ```xml @@ -153,23 +170,156 @@ Conditions can also be applied at the `ItemGroup` level and will apply to all ch ``` +## GeneratePathProperty + +This feature is available with NuGet **5.0** or above and with Visual Studio 2019 **16.0** or above. + +Sometimes it is desirable to reference files in a package from an MSBuild target. +In `packages.config` based projects, the packages are installed in a folder relative to the project file. However in PackageReference, the packages are [consumed](../concepts/package-installation-process.md) from the *global-packages* folder, which can vary from machine to machine. + +To bridge that gap, NuGet introduced a property that points to the location from which the package will be consumed. + +Example: + +```xml + + + + + + + +```` + +Additionally NuGet automatically generates properties for packages containing a tools folder. + +```xml + + + + + + + +``` + +MSBuild properties and package identities do not have the same restrictions so the package identity needs to be changed to an MSBuild friendly name, prefixed by the word `Pkg`. +To verify the exact name of the property generated, look at the generated [nuget.g.props](../reference/msbuild-targets.md#restore-outputs) file. + +## PackageReference aliases + +In some rare instances, different packages will contain classes in the same namespace. Starting with NuGet 5.7 & Visual Studio 2019 Update 7, equivalent to ProjectReference, PackageReference supports [`Aliases`](/dotnet/api/microsoft.codeanalysis.projectreference.aliases). +By default, no aliases are provided. When an alias is specified, *all* assemblies coming from the annotated package need to be referenced with an alias. + +You can look at sample usage at [NuGet\Samples](https://github.com/NuGet/Samples/tree/main/PackageReferenceAliasesExample). + +In the project file, specify the aliases as follows: + +```xml + + + +``` + +And in the code, use it as follows: + +```cs +extern alias ExampleAlias; + +namespace PackageReferenceAliasesExample +{ +... + { + var version = ExampleAlias.NuGet.Versioning.NuGetVersion.Parse("5.0.0"); + Console.WriteLine($"Version : {version}"); + } +... +} + +``` + +## NuGet warnings and errors + +*This feature is available with NuGet **4.3** or above and with Visual Studio 2017 **15.3** or above.* + +For many pack and restore scenarios, all NuGet warnings and errors are coded, and start with `NU****`. All NuGet warnings and errors are listed in the [reference](../reference/errors-and-warnings.md) documentation. + +NuGet observes the following warning properties: + +- `TreatWarningsAsErrors`, treat all warnings as errors. +- `WarningsAsErrors`, treat specific warnings as errors. +- `NoWarn`, hide specific warnings, either project-wide or package-wide. + +Examples: + +```xml + + true + +... + + $(WarningsAsErrors);NU1603;NU1605 + +... + + $(NoWarn);NU5124 + +... + + + +``` + +### Suppressing NuGet warnings + +While it is recommended that you resolve all NuGet warnings during your pack and restore operations, in certain situations suppressing them is warranted. +To suppress a warning project wide, consider doing: + +```xml + + 5.0.0 + $(NoWarn);NU5104 + + + + +``` + +Sometimes warnings apply only to a certain package in the graph. You can choose to suppress that warning more selectively by adding a `NoWarn` on the PackageReference item. + +```xml + + 5.0.0 + + + + +``` + +#### Suppressing NuGet package warnings in Visual Studio + +When in Visual Studio, you can also [suppress warnings](/visualstudio/ide/how-to-suppress-compiler-warnings#suppress-warnings-for-nuget-packages +) through the IDE. + ## Locking dependencies + *This feature is available with NuGet **4.9** or above and with Visual Studio 2017 **15.9** or above.* -Input to NuGet restore is a set of Package References from the project file (top-level or direct dependencies) and the output is a full closure of all the package dependencies including transitive dependencies. NuGet tries to always produce the same full closure of package dependencies if the input PackageReference list has not changed. However, there are some scenarios where it is unable to do so. For example: +Input to NuGet restore is a set of `PackageReference` items from the project file (top-level or direct dependencies) and the output is a full closure of all the package dependencies including transitive dependencies. NuGet tries to always produce the same full closure of package dependencies if the input PackageReference list has not changed. However, there are some scenarios where it is unable to do so. For example: + +- When you use floating versions like ``. While the intention here is to float to the latest version on every restore of packages, there are scenarios where users require the graph to be locked to a certain latest version and float to a later version, if available, upon an explicit gesture. +- A newer version of the package matching PackageReference version requirements is published. For example: -* When you use floating versions like ``. While the intention here is to float to the latest version on every restore of packages, there are scenarios where users require the graph to be locked to a certain latest version and float to a later version, if available, upon an explicit gesture. -* A newer version of the package matching PackageReference version requirements is published. E.g. + - Day 1: if you specified `` but the versions available on the + NuGet repositories were 4.1.0, 4.2.0, and 4.3.0. In this case, NuGet would have resolved to 4.1.0 (nearest minimum version). - * Day 1: if you specified `` but the versions available on the - NuGet repositories were 4.1.0, 4.2.0 and 4.3.0. In this case, NuGet would have resolved to 4.1.0 (nearest minimum version) + - Day 2: Version 4.0.0 gets published. NuGet will now find the exact match and start resolving to 4.0.0. - * Day 2: Version 4.0.0 gets published. NuGet will now find the exact match and start resolving to 4.0.0 +- A given package version is removed from the repository. Though nuget.org does not allow package deletions, not all package repositories have this constraint. This results in NuGet finding the best match when it cannot resolve to the deleted version. -* A given package version is removed from the repository. Though nuget.org does not allow package deletions, not all package repositories have this constraints. This results in NuGet finding the best match when it cannot resolve to the deleted version. +### Enabling the lock file -### Enabling lock file -In order to persist the full closure of package dependencies you can opt-in to the lock file feature by setting the MSBuild property `RestorePackagesWithLockFile` for your project: +In order to persist the full closure of package dependencies, you can opt-in to the lock file feature by setting the MSBuild property `RestorePackagesWithLockFile` for your project: ```xml @@ -179,29 +329,33 @@ In order to persist the full closure of package dependencies you can opt-in to t ``` -If this property is set, NuGet restore will generate a lock file - `packages.lock.json` file at the project root directory that lists all the package dependencies. +If this property is set, NuGet restore will generate a lock file (`packages.lock.json`) at the project root directory that lists all the package dependencies. > [!Note] > Once a project has `packages.lock.json` file in its root directory, the lock file is always used with restore even if the property `RestorePackagesWithLockFile` is not set. So another way to opt-in to this feature is to create a dummy blank `packages.lock.json` file in the project's root directory. ### `restore` behavior with lock file -If a lock file is present for project, NuGet uses this lock file to run `restore`. NuGet does a quick check to see if there were any changes in the package dependencies as mentioned in the project file (or dependent projects' files) and if there were no changes it just restores the packages mentioned in the lock file. There is no re-evaluation of package dependencies. + +If a lock file is present for a project, NuGet uses this lock file to run `restore`. NuGet does a quick check to see if there were any changes in the package dependencies as mentioned in the project file (or dependent projects' files), and if there were no changes, it just restores the packages mentioned in the lock file. There is no re-evaluation of package dependencies. If NuGet detects a change in the defined dependencies as mentioned in the project file(s), it re-evaluates the package graph and updates the lock file to reflect the new package closure for the project. For CI/CD and other scenarios, where you would not want to change the package dependencies on the fly, you can do so by setting the `lockedmode` to `true`: For dotnet.exe, run: + ``` > dotnet.exe restore --locked-mode ``` For msbuild.exe, run: + ``` > msbuild.exe -t:restore -p:RestoreLockedMode=true ``` -You may also set this conditional MSBuild property in your project file: +You can also set this conditional MSBuild property in your project file: + ```xml @@ -212,26 +366,193 @@ You may also set this conditional MSBuild property in your project file: If locked mode is `true`, restore will either restore the exact packages as listed in the lock file or fail if you updated the defined package dependencies for the project after lock file was created. +#### Lock files and PrunePackageReference + +[PrunePackageReference](#prunepackagereference) changes the dependencies of a project, by removing unnecessary transitive packages. +While removing these packages should not have an impact at runtime, it will affect lock files. +If you enable pruning for an existing project, whenever the lock file gets regenerated, it may lead to fewer packages than before pruning. +The lock file up to date check that powers locked mode is pruning aware, which means if you enabled pruning on a project, the check will account for packages that are pruned. +However the next time the lock file is regenerated, it will exclude the pruned packages, so you may see a diff that's larger than usual. + ### Make lock file part of your source repository -If you are building an application, an executable and the project in question is at the start of the dependency chain then do check in the lock file to the source code repository so that NuGet can make use of it during restore. -However, if your project is a library project that you do not ship or a common code project on which other projects depend upon, you **should not** check in the lock file as part of your source code. There is no harm in keeping the lock file but the locked package dependencies for the common code project may not be used, as listed in the lock file, during the restore/build of a project that depends on this common-code project. +If you are building an application, an executable, and the project in question is at the start of the dependency chain, then do check in the lock file to the source code repository so that NuGet can make use of it during restore. + +However, if your project is a library project that you do not ship or a common code project on which other projects depend, you **should not** check in the lock file as part of your source code. There is no harm in keeping the lock file, but the locked package dependencies for the common code project can't be used, as listed in the lock file, during the restore/build of a project that depends on this common-code project. + +Example: -Eg. ``` ProjectA |------> PackageX 2.0.0 |------> ProjectB |------>PackageX 1.0.0 ``` + If `ProjectA` has a dependency on a `PackageX` version `2.0.0` and also references `ProjectB` that depends on `PackageX` version `1.0.0`, then the lock file for `ProjectB` will list a dependency on `PackageX` version `1.0.0`. However, when `ProjectA` is built, its lock file will contain a dependency on `PackageX` version **`2.0.0`** and **not** `1.0.0` as listed in the lock file for `ProjectB`. Thus, the lock file of a common code project has little say over the packages resolved for projects that depend on it. ### Lock file extensibility + You can control various behaviors of restore with lock file as described below: -| Option | MSBuild equivalent option | -|:--- |:--- | -| `--use-lock-file` | Bootstraps use of lock file for a project. You can alternatively set `RestorePackagesWithLockFile` property in the project file | -| `--locked-mode` | Enables locked mode for restore. This is useful in CI/CD scenarios where you would like to get the repeatable builds. This can be also by setting the `RestoreLockedMode` MSBuild property to `true` | -| `--force-evaluate` | This option is useful with packages with floating version defined in the project. By default, NuGet restore will not update the package version automatically upon each restore unless you run restore with `--force-evaluate` option. | -| `--lock-file-path` | Defines a custom lock file location for a project. This can be also achieved by setting the MSBuild property `NuGetLockFilePath`. By default, NuGet supports `packages.lock.json` at the root directory. If you have multiple projects in the same directory, NuGet supports project specific lock file `packages..lock.json` | +| NuGet.exe option | dotnet option | MSBuild equivalent option | Description | +|:--- |:--- |:--- |:--- | +| `-UseLockFile` |`--use-lock-file` | RestorePackagesWithLockFile | Opts into the usage of a lock file. | +| `-LockedMode` | `--locked-mode` | RestoreLockedMode | Enables locked mode for restore. This is useful in CI/CD scenarios where you want repeatable builds.| +| `-ForceEvaluate` | `--force-evaluate` | RestoreForceEvaluate | This option is useful with packages with floating version defined in the project. By default, NuGet restore will not update the package version automatically upon each restore unless you run restore with this option. | +| `-LockFilePath` | `--lock-file-path` | NuGetLockFilePath | Defines a custom lock file location for a project. By default, NuGet supports `packages.lock.json` at the root directory. If you have multiple projects in the same directory, NuGet supports project specific lock file `packages..lock.json` | + +## NuGet Dependency Resolver + +The NuGet dependency resolver follows the [four rules as described in the dependency resolution document](../../docs/concepts/Dependency-Resolution.md). + +In order to improve the performance and scalability of the restore operation, the restore algorithm was rewritten in the 6.12 release. +As of the 6.12 release, the new restore algorithm is enabled by default for all PackageReference projects. +While the new restore algorithm is is functionally equivalent to the previous one, as with any software, bugs are possible. +To revert to the previous implementation, set the MSBuild property `RestoreUseLegacyDependencyResolver` to `true`. + +Should you face restore failures in 6.12, .NET 9 or 17.12, that weren't reproducing in earlier versions, please [file an issue on GitHub](https://github.com/NuGet/Home/issues/). +Any differences between the old and new algorithms may have different impacts, such as during compilation or at runtime. +There's also a chance that changes don't lead to failures, but different package versions being restored. +If you think you might be impacted by any changes, here are the steps you can take to verify whether the changes in the NuGet restore algorithm are the root cause. + +Restore writes its results in the `MSBuildProjectExtensionsPath` directory, which can be compared with the new and old algorithms to find differences. +Usually this is the `obj` folder of your build. +You can use `msbuild.exe` or `dotnet.exe` for the next steps. + +1. Remove the `obj` folder for your project. +1. Run `msbuild -t:restore` +1. Save the contents of the `obj` to a location indicating that it's the `new` behavior. +1. Run `msbuild -t:restore -p:RestoreUseLegacyDependencyResolver="true"`. +1. Save the contents of the `obj` to a location indicating that it's the `legacy` behavior. +1. Compare the files in the two directories, particularly *project.assets.json*. + + Tools that can highlight differences are especially useful for this (for example, in Visual Studio Code, open both files, and use the right-click "select for compare" and "compare to selected"). + +If you follow the above method, there should be exactly 1 difference between the `project.assets.json` files: + +```diff + "projectStyle": "PackageReference", ++ "restoreUseLegacyDependencyResolver": true, + "fallbackFolders": [ +``` + +If there are any more differences, please [file an issue on GitHub](https://github.com/NuGet/Home/issues/) with all the details. + +## AssetTargetFallback + +The `AssetTargetFallback` property lets you specify additional compatible framework versions for projects that your project references and NuGet packages that your project consumes. + +If you specify a package dependency using `PackageReference` but that package doesn't contain assets that are compatible with your projects's target framework, the `AssetTargetFallback` property comes into play. The compatibility of the referenced package is rechecked using each target framework that's specified in `AssetTargetFallback`. +When a `project` or a `package` is referenced through `AssetTargetFallback`, the [NU1701](../reference/errors-and-warnings/NU1701.md) warning will be raised. + +Refer to the table below for examples of how `AssetTargetFallback` affects compatibility. + +| Project framework | AssetTargetFallback | Package frameworks | Result | +|-------------------|---------------------|--------------------|--------| +| .NET Framework 4.7.2 | | .NET Standard 2.0 | .NET Standard 2.0 | +| .NET Core App 3.1 | | .NET Standard 2.0, .NET Framework 4.7.2 | .NET Standard 2.0 | +| .NET Core App 3.1 | | .NET Framework 4.7.2 | Incompatible, fail with [`NU1202`](../reference/errors-and-warnings/NU1202.md) | +| .NET Core App 3.1 | net472;net471 | .NET Framework 4.7.2 | .NET Framework 4.7.2 with [`NU1701`](../reference/errors-and-warnings/NU1701.md) | + +Multiple frameworks can be specified using `;` as a delimiter. To add a fallback framework you can do the following: + +```xml + + $(AssetTargetFallback);net472;net471 + +``` + +You can leave off `$(AssetTargetFallback)` if you wish to overwrite, instead of add to the existing `AssetTargetFallback` values. + +> [!NOTE] +> If you are using a [.NET SDK based project](/dotnet/core/sdk), appropriate `$(AssetTargetFallback)` values are configured and you do not need to set them manually. +> +> `$(PackageTargetFallback)` was an earlier feature that attempted to address this challenge, but it is fundamentally broken and *should* not be used. To migrate from `$(PackageTargetFallback)` to `$(AssetTargetFallback)`, simply change the property name. + +## PrunePackageReference + +The .NET Runtime is constantly evolving, with performance improvements and new APIs each release. +New features added to .NET are also sometimes provided as packages, so that developers using older target frameworks can use the library, such as [System.Text.Json](https://www.nuget.org/packages/System.Text.Json). +This can often lead to a `System.Text.Json 8.0.0` in a project targeting `.NET 9` or `.NET 8`. This dependency is unnecessary and the build conflict resolution would not use the assembly coming from the package since it's already available in the .NET Runtime. +Starting in [NuGet version 6.13](..\release-notes\NuGet-6.13.md) and .NET SDK 9.0.200, `PrunePackageReference` enables the pruning of these packages at restore time for .NET SDK based projects. +The first iteration of pruning affected transitive packages only, but starting with .NET SDK 10, package pruning affects direct packages as well. + +Package pruning is available as an opt-in feature with the .NET 9 SDK, and is enabled by default for all frameworks of a project that targets `>= .NET 10.0` in the .NET 10 SDK. + +Package pruning is only available with the default dependency resolver as [released in 6.12](#nuget-dependency-resolver). + +### PrunePackageReference specification + +The list of packages to be pruned is defined with the `PrunePackageReference` item. + +| Attributes | Description | +|------------|-------------| +| Version | Specifies the maximum version to be pruned. `1.0.0` means that all packages up to and including 1.0.0 will be pruned. For `1.0.0`, `0.9.0` and `1.0.0` will be pruned, but `1.0.1` would not. | + +The following properties can be used to modify the pruning behavior. + +| PropertyName | Description | +|--------------|-------------| +| RestoreEnablePackagePruning | Enables package pruning for the packages specified with `PrunePackageReference`. This property is per target framework and the valid values are `true` and `false`. Defaults may differ based on the .NET SDK as defined above. | + +The .NET SDK predefines the list of packages to be pruned for you. + +### How PrunePackageReference works + +When a package is specified to be pruned during restore, it is removed from the dependency graph. +When a package is pruned, there is a message, visible at detailed verbosity, indicating that the package has been removed for the given target framework. + +For transitive packages, meaning dependencies of other packages or projects, the packages are not downloaded and do not appear in any of the outputs of NuGet. + +For direct packages, `PrivateAssets='all'` and `IncludeAssets='none'` are implicitly applied. + +- `IncludeAssets='none'` ensures that the assemblies from this package are not used during the build. Before pruning existed, the conflict resolution during the build ensured that platform assemblies were preferred over those coming from the packages. +- `PrivateAssets='all'` ensures that the packages aren't included in packages or through project references. + +Example: + +A project like below: + +```xml + + net9.0;netstandard2.0 + + + + + +``` + +will have a nuspec with the following dependencies: + +```xml + + + + + + + +``` + +When a direct PackageReference can be completely removed from your project, and one of the project frameworks are .NET 10 or newer, [NU1510](../reference/errors-and-warnings/NU1510.md) will be raised asking you to remove the package. +Following this suggestion will reduce the complexity of your project graph. + +The following table summarizes all the package pruning behaviors. + +| Dependency disposition | Behavior | +|-----------------|----------| +| Matches the ID of a transitive package coming through another package | Prune | +| Matches the ID of a transitive package coming through another project | Prune | +| Matches the ID of a direct `PackageReference` | Apply `PrivateAssets='all'` and `IncludeAssets='none'` and raise the [NU1510](../reference/errors-and-warnings/NU1510.md) warning when the package can be removed from all frameworks and the project targets .NET 10. | +| Matches the ID of a `ProjectReference` | Do not prune and raise the [NU1511](../reference/errors-and-warnings/NU1511.md) warning when the project targets .NET 10 | + +### PrunePackageReference applications + +The benefits of package pruning are two-fold: + +- Performance benefits, by virtue of reducing the number of packages within a dependency graph +- Reduction of false positives by component scanners such as `NuGetAudit` + +Pruning is particularly valuable when [auditing](./../concepts/Auditing-Packages.md) packages with `NuGetAuditMode` set to `all`. If you are using .NET 9, we recommend you try out pruning by setting `RestoreEnablePackagePruning` to `true`. diff --git a/docs/consume-packages/Package-Restore.md b/docs/consume-packages/Package-Restore.md index 4911f2ee1..531bb806f 100644 --- a/docs/consume-packages/Package-Restore.md +++ b/docs/consume-packages/Package-Restore.md @@ -1,144 +1,226 @@ --- title: NuGet Package Restore -description: An overview of how NuGet restores packages a project depends on, including how to disable restore and constrain versions. -author: karann-msft -ms.author: karann -ms.date: 06/24/2019 +description: See an overview of how NuGet restores packages a project depends on, including how to disable restore and constrain versions. +author: JonDouglas +ms.author: jodou +ms.date: 10/20/2023 ms.topic: conceptual --- -# Package Restore options +# Restore packages with NuGet Package Restore -To promote a cleaner development environment and to reduce repository size, NuGet **Package Restore** installs all of a project's dependencies listed in either the project file or `packages.config`. The .NET Core 2.0+ `dotnet build` and `dotnet run` commands do an automatic package restore. Visual Studio can restore packages automatically when it builds a project, and you can restore packages at any time through Visual Studio, `nuget restore`, `dotnet restore`, and xbuild on Mono. +NuGet Package Restore restores all of a project's dependencies that are listed in either a project file or a *packages.config* file. You can restore packages manually with `nuget restore`, `dotnet restore`, `msbuild -t:restore`, or through Visual Studio. The `dotnet build` and `dotnet run` commands automatically restore packages, and you can configure Visual Studio to restore packages automatically when it builds a project. -Package Restore makes sure that all a project's dependencies are available, without having to store them in source control. To configure your source control repository to exclude the package binaries, see [Packages and source control](../consume-packages/packages-and-source-control.md). +To promote a cleaner development environment and to reduce repository size, Package Restore makes all of a project's dependencies available without having to store them in source control. To configure your source control repository to exclude package binaries, see [Packages and source control](../consume-packages/packages-and-source-control.md). -## Package Restore overview +## Package Restore behavior -Package Restore first installs the direct dependencies of a project as needed, then installs any dependencies of those packages throughout the entire dependency graph. +Package Restore tries to install all package dependencies to the state that matches the ``s in a project file, such as *.csproj*, or ``s in a *packages.config* file. Package Restore first installs the direct dependencies of a project as needed, then installs any dependencies of those packages throughout the entire dependency graph. -If a package isn't already installed, NuGet first attempts to retrieve it from the [cache](../consume-packages/managing-the-global-packages-and-cache-folders.md). If the package isn't in the cache, NuGet tries to download the package from all enabled sources in the list at **Tools** > **Options** > **NuGet Package Manager** > **Package Sources** in Visual Studio. During restore, NuGet ignores the order of package sources, and uses the package from whichever source is first to respond to requests. For more information about how NuGet behaves, see [Common NuGet configurations](Configuring-NuGet-Behavior.md). +If a needed package isn't already installed, NuGet first attempts to retrieve it from the local [global packages or HTTP cache folders](../consume-packages/managing-the-global-packages-and-cache-folders.md). If the package isn't in the local folders, NuGet tries to download it from all sources configured in Visual Studio at **Tools** > **Options** > **NuGet Package Manager** > **Package Sources**. -> [!Note] -> NuGet doesn't indicate a failure to restore a package until all the sources have been checked. At that time, NuGet reports a failure for only the last source in the list. The error implies that the package wasn't present on *any* of the other sources, even though errors aren't shown for each of those sources individually. +During restore, NuGet ignores the order of package sources, and uses the package from the first source that responds to requests. If restore fails, NuGet doesn't indicate the failure until after it checks all sources. NuGet then reports a failure for only the last source in the list. The error implies that the package wasn't present on any of the sources, even though it doesn't list the other failures individually. + +For more information about NuGet behavior, see [Common NuGet configurations](Configuring-NuGet-Behavior.md). ## Restore packages -You can trigger Package Restore in any of the following ways: +If the package references in your project file or *packages.config* file are correct, use your preferred tool to restore packages: -- **Visual Studio**: In Visual Studio on Windows, use one of the following methods. +- [Visual Studio](#restore-using-visual-studio) +- [dotnet CLI](#restore-using-the-dotnet-cli) +- [nuget.exe CLI](#restore-using-the-nugetexe-cli) +- [MSBuild](#restore-using-msbuild) +- [Azure Pipelines or Azure DevOps Server](#restore-using-azure-pipelines) - - Restore packages automatically. Package Restore happens automatically when you create a project from a template or build a project, subject to the options in [Enable and disable package restore](#enable-and-disable-package-restore-visual-studio). In NuGet 4.0+, restore also happens automatically when you make changes to a SDK-style project (typically a .NET Core or .NET Standard project). +After a successful restore: - - Restore packages manually. To restore manually, right-click the solution in **Solution Explorer** and select **Restore NuGet Packages**. If one or more individual packages still aren't installed properly, **Solution Explorer** shows an error icon. Right-click and select **Manage NuGet Packages**, and use **Package Manager** to uninstall and reinstall the affected packages. For more information, see [Reinstall and update packages](../consume-packages/reinstalling-and-updating-packages.md) +- For projects that use ``, the package is present in the local *global-packages* folder, and the project *obj/project.assets.json* file is recreated. +- For projects that use *packages.config*, the package appears in the project's *packages* folder. +- The project should now build successfully. - If you see the error "This project references NuGet package(s) that are missing on this computer," or "One or more NuGet packages need to be restored but couldn't be because consent has not been granted," [enable automatic restore](#enable-and-disable-package-restore-visual-studio). Also, see [Migrate to automatic package restore](#migrate-to-automatic-package-restore-visual-studio) and [Package Restore troubleshooting](Package-restore-troubleshooting.md). +If the package references in your project file or your *packages.config* file are incorrect and don't match your desired state, install or update the correct packages instead of using Package Restore. -- **dotnet CLI**: In the command line, switch to the folder that contains your project, and then use the [dotnet restore](/dotnet/core/tools/dotnet-restore?tabs=netcore2x) command to restore packages listed in the project file with [PackageReference](../consume-packages/package-references-in-project-files.md). With .NET Core 2.0 and later, restore happens automatically with the `dotnet build` and `dotnet run` commands. +If you have missing packages or package-related errors after you run Package Restore, such as error icons in Solution Explorer, follow the instructions in [Troubleshooting Package Restore errors](package-restore-troubleshooting.md), or [reinstall or update](../consume-packages/reinstalling-and-updating-packages.md) the packages. In Visual Studio, the Package Manager Console provides several options for reinstalling packages. For more information, see [Use Package-Update](reinstalling-and-updating-packages.md#update-package-command). -- **nuget.exe CLI**: In the command line, switch to the folder that contains your project, and then use the [nuget restore](../reference/cli-reference/cli-ref-restore.md) command to restore packages listed in a project or solution file, or in `packages.config`. + -- **MSBuild**: Use the [msbuild -t:restore](../reference/msbuild-targets.md#restore-target) command to restore packages listed in the project file with PackageReference. This command is available only in NuGet 4.x+ and MSBuild 15.1+, which are included with Visual Studio 2017 and higher versions. Both `nuget restore` and `dotnet restore` use this command for applicable projects. +## Restore packages in Visual Studio -- **Azure Pipelines**: When you create a build definition in Azure Pipelines, include the NuGet [restore](/azure/devops/pipelines/tasks/package/nuget#restore-nuget-packages) or .NET Core [restore](/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops) task in the definition before any build tasks. Some build templates include the restore task by default. +In Visual Studio on Windows, you can restore packages automatically or manually. First, configure Package Restore through **Tools** > **Options** > **NuGet Package Manager**. -- **Azure DevOps Server**: Azure DevOps Server and TFS 2013 and later automatically restore packages during build, if you're using a TFS 2013 or later Team Build template. For earlier TFS versions, you can include a build step to run a command-line restore option, or optionally migrate the build template to a later version. For more information, see [Set up package restore with Team Foundation Build](../consume-packages/team-foundation-build.md). +### Configure Visual Studio Package Restore options -## Enable and disable package restore (Visual Studio) +Configure the following Package Restore options at **Tools** > **Options** > **NuGet Package Manager** > **General**. -In Visual Studio, you control Package Restore primarily through **Tools** > **Options** > **NuGet Package Manager**: +![Screenshot that shows the NuGet Package Manager options.](media/vsoptions/general.png) -![Control Package Restore through NuGet Package Manager options](media/Restore-01-AutoRestoreOptions.png) + -- **Allow NuGet to download missing packages** controls all forms of package restore by changing the `packageRestore/enabled` setting in the [packageRestore section](../reference/nuget-config-file.md#packagerestore-section) of the `NuGet.Config` file, at `%AppData%\NuGet\` on Windows, or `~/.nuget/NuGet/` on Mac/Linux. This setting also enables the **Restore NuGet Packages** command on the solution's context menu in Visual Studio, . +#### Allow NuGet to download missing packages - ```xml - - - - - - - ``` - - > [!Note] - > To globally override the `packageRestore/enabled` setting, set the environment variable **EnableNuGetPackageRestore** with a value of True or False before launching Visual Studio or starting a build. +Select **Allow NuGet to download missing packages** to enable package restore and the **Restore NuGet Packages** command. This selection sets the `packageRestore/enabled` setting to `True` in the [packageRestore section](../reference/nuget-config-file.md#packagerestore-section) of the global *NuGet.Config* file, at *%AppData%\\Roaming\\NuGet* on Windows or *~/.nuget/NuGet/* on Mac or Linux. -- **Automatically check for missing packages during build in Visual Studio** controls automatic restore by changing the `packageRestore/automatic` setting in the [packageRestore section](../reference/nuget-config-file.md#packagerestore-section) of the `NuGet.Config` file. When this option is set to True, running a build from Visual Studio automatically restores any missing packages. This setting doesn't affect builds run from the MSBuild command line. +```xml + + + + + +``` - ```xml - ... - - - - - - - ``` +> [!Note] +> To globally override the `packageRestore/enabled` setting, you can set the environment variable **EnableNuGetPackageRestore** to True or False before you open Visual Studio or start a build. -To enable or disable Package Restore for all users on a computer, a developer or company can add the configuration settings to the global `nuget.config` file. The global `nuget.config` is in Windows at `%ProgramData%\NuGet\Config`, sometimes under a specific `\{IDE}\{Version}\{SKU}\` Visual Studio folder, or in Mac/Linux at `~/.local/share`. Individual users can then selectively enable restore as needed on a project level. For more details on how NuGet prioritizes multiple config files, see [Common NuGet configurations](../consume-packages/configuring-nuget-behavior.md#how-settings-are-applied). +To enable or disable Package Restore for all users on a computer, you can add the configuration settings to the global *NuGet.Config* file in Windows at *%ProgramData%\NuGet\Config*, sometimes under a specific *\\\\\\\* Visual Studio folder, or in Mac/Linux at *~/.local/share*. Individual users can then selectively enable restore as needed on a project level. For more details on how NuGet prioritizes multiple config files, see [Common NuGet configurations](../consume-packages/configuring-nuget-behavior.md#how-settings-are-applied). > [!Important] -> If you edit the `packageRestore` settings directly in `nuget.config`, restart Visual Studio, so that the **Options** dialog box shows the current values. +> If you edit the `packageRestore` settings in *NuGet.Config* directly, restart Visual Studio so that the **Options** show the current values. + +#### Automatically check for missing packages during build + +Select **Automatically check for missing packages during build in Visual Studio** to automatically restore any missing packages when you run a build from Visual Studio. This setting doesn't affect builds run from the MSBuild command line. This selection sets the `packageRestore/automatic` setting to `True` in the `packageRestore` section of the *NuGet.Config* file. + +```xml + + + + + +``` + +You must select **Allow NuGet to download missing packages** as well as **Automatically check for missing packages during build in Visual Studio** in **Options** to enable package restore during build. + + + +#### Choose the default package management format + +NuGet has two package management formats, [PackageReference](Package-References-in-Project-Files.md) and [packages.config](../reference/packages-config.md). Select the format you want to use from the dropdown list under **Package Management**. You can also select whether to allow format selection on first package install. + +> [!Note] +> +> - If a project doesn't support both package management formats, NuGet uses the package management format that's compatible with the project, which might not be the default you set in the options. NuGet then won't prompt for selection on first install, even if you selected that option. +> +> - If you use Package Manager Console to install the first package in a project, NuGet doesn't prompt for format selection, even if that option is selected in **Options**. + + + + +### Restore packages manually or automatically + +After you enable package restore in **Options**, you can right-click the solution in **Solution Explorer** and select **Restore NuGet Packages** to restore packages anytime. + +If you enabled automatic restore in **Options**, Package Restore happens automatically when you create a project from a template or build a project. For NuGet 4.0+, restore also happens automatically when you make changes to a SDK-style project. + +For projects that use ``, you can see the package references in Visual Studio **Solution Explorer** under **Dependencies** > **Packages**. Packages that don't install properly when you manually restore or run a build display error icons in **Solution Explorer**. Right-click the project, select **Manage NuGet Packages**, and use the **NuGet Package Manager** to uninstall and reinstall the affected packages. For more information, see [Reinstall and update packages](../consume-packages/reinstalling-and-updating-packages.md). -## Constrain package versions with restore +If you see the error **This project references NuGet package(s) that are missing on this computer**, or **One or more NuGet packages need to be restored but couldn't be because consent has not been granted**, make sure you enabled automatic restore. For older projects, see [Migrate to automatic package restore](#migrate-to-automatic-package-restore-visual-studio). Also see [Troubleshooting package restore errors](Package-restore-troubleshooting.md). -When NuGet restores packages through any method, it honors any constraints you specified in `packages.config` or the project file: + -- In `packages.config`, you can specify a version range in the `allowedVersion` property of the dependency. See [Constrain upgrade versions](../consume-packages/reinstalling-and-updating-packages.md#constraining-upgrade-versions) for more information. For example: +## Restore by using the dotnet CLI - ```xml - - ``` +[!INCLUDE [restore-dotnet-cli](includes/restore-dotnet-cli.md)] -- In a project file, you can use PackageReference to specify a dependency's range directly. For example: +> [!IMPORTANT] +> To add a missing package reference to the project file, use [dotnet add package](/dotnet/core/tools/dotnet-add-package), which also runs `restore`. - ```xml - - ``` + -In all cases, use the notation described in [Package versioning](../reference/package-versioning.md). +## Restore by using the NuGet CLI -## Force restore from package sources +[!INCLUDE [restore-nuget-exe-cli](includes/restore-nuget-exe-cli.md)] -By default, NuGet restore operations use packages from the *global-packages* and *http-cache* folders, which are described in [Manage the global packages and cache folders](managing-the-global-packages-and-cache-folders.md). + -To avoid using the *global-packages* folder, do one of the following: +## Restore by using MSBuild -- Clear the folder using `nuget locals global-packages -clear` or `dotnet nuget locals global-packages --clear`. -- Temporarily change the location of the *global-packages* folder before the restore operation, using one of the following methods: - - Set the NUGET_PACKAGES environment variable to a different folder. - - Create a `NuGet.Config` file that sets `globalPackagesFolder` (if using PackageReference) or `repositoryPath` (if using `packages.config`) to a different folder. For more information, see [configuration settings](../reference/nuget-config-file.md#config-section). - - MSBuild only: Specify a different folder with the `RestorePackagesPath` property. +You can use [msbuild -t:restore](../reference/msbuild-targets.md#restore-target) to restore packages in NuGet 4.x+ and MSBuild 15.1+, which are included with Visual Studio 2017 and higher. -To avoid using the cache for HTTP sources, do one of the following: +This command restores packages in projects that use [PackageReference](package-references-in-project-files.md) for package references. Starting with MSBuild 16.5+, the command also supports [packages.config](/nuget/reference/packages-config) package references, when used with `-p:RestorePackagesConfig=true`. -- Use the `-NoCache` option with `nuget restore`, or the `--no-cache` option with `dotnet restore`. These options don't affect restore operations through the Visual Studio Package Manager or console. -- Clear the cache using `nuget locals http-cache -clear` or `dotnet nuget locals http-cache --clear`. -- Temporarily set the NUGET_HTTP_CACHE_PATH environment variable to a different folder. +To use MSBuild restore: + +1. Open a Developer Command Prompt by searching for *developer command prompt* and starting the prompt from the Windows **Start** menu, which configures all the necessary paths for MSBuild. + +1. Switch to the project folder, and enter `msbuild -t:restore`. + +1. After the restore completes, enter `msbuild` to rebuild the project. Make sure the MSBuild output indicates that the build completed successfully. + +> [!Note] +> You can use `msbuild -restore` to run `restore`, reload the project, and build, since build is the default target. For more information, see [Restore and build with one MSBuild command](../reference/msbuild-targets.md#restoring-and-building-with-one-msbuild-command). -## Migrate to automatic package restore (Visual Studio) + + -For NuGet 2.6 and earlier, an MSBuild-integrated package restore was previously supported but that is no longer true. (It was typically enabled by right-clicking a solution in Visual Studio and selecting **Enable NuGet Package Restore**). If your project uses the deprecated MSBuild-integrated package restore, please migrate to automatic package restore. +## Restore with Azure Pipelines or Azure DevOps Server -Projects that use MSBuild-Integrated package restore typically contain a *.nuget* folder with three files: *NuGet.config*, *nuget.exe*, and *NuGet.targets*. The presence of a *NuGet.targets* file determines whether NuGet will continue to use the MSBuild-untegrated approach, so this file must be removed during the migration. +When you create a build definition in Azure Pipelines, you can include the [NuGet CLI restore](/azure/devops/pipelines/tasks/package/nuget#restore-nuget-packages) or [dotnet CLI restore](/azure/devops/pipelines/tasks/build/dotnet-core-cli) task in the definition before any build tasks. Some build templates include the restore task by default. + +Azure DevOps Server and TFS 2013 and later automatically restore packages during build, if you use a TFS 2013 or later Team Build template. You can also include a build step to run a command-line restore option, or optionally migrate the build template to a later version. For more information, see [Set up package restore with Team Foundation Build](../consume-packages/team-foundation-build.md). + +## Constrain package versions + +NuGet restore through any method honors any version constraints you specify in *packages.config* or the project file. + +- In *packages.config*, you can specify an `allowedVersions` range in the dependency. For more information, see [Constraints on upgrade versions](../consume-packages/reinstalling-and-updating-packages.md#constraints-on-upgrade-versions). For example: + + ```xml + + ``` + +- In a project file, you can specify the version range in the `Version` property of the dependency. For example: + + ```xml + + ``` + +In both cases, use the notation described in [Package versioning](../concepts/package-versioning.md). + +## Force restore from remote package sources + +By default, NuGet restore operations use packages from the local *global-packages* and *http-cache* folders, as described in [Manage the global packages and cache folders](managing-the-global-packages-and-cache-folders.md). To avoid using these local packages, use the following options. + +To clear all local caches: + +- In Visual Studio, select the **Clear All NuGet Cache(s)** button at **Tools** > **Options** > **NuGet Package Manager** > **General**. +- In the dotnet CLI, use `dotnet nuget locals all --clear`. +- In the NuGet CLI, use `nuget locals all -clear`. + +To avoid using the packages in the *global-packages* folder: + +- Clear the folder by using `nuget locals global-packages -clear` or `dotnet nuget locals global-packages --clear`. +- Temporarily set the **NUGET_PACKAGES** environment variable to a different folder. +- Create a *NuGet.Config* file that sets `globalPackagesFolder` for `PackageReference`, or `repositoryPath` for *packages.config*, to a different folder. For more information, see [configuration settings](../reference/nuget-config-file.md#config-section). +- For MSBuild only, specify a different folder with the `RestorePackagesPath` property. + +To avoid using packages in the HTTP cache: + +- Clear the cache by using `nuget locals http-cache -clear` or `dotnet nuget locals http-cache --clear`. +- Temporarily set the **NUGET_HTTP_CACHE_PATH** environment variable to a different folder. +- For `nuget restore`, use the `-NoHttpCache` option, or for `dotnet restore`, use the `--no-http-cache` option. These options don't affect restore operations through the Visual Studio Package Manager or Console. + + + +## Migrate to automatic package restore + +Earlier versions of NuGet supported an MSBuild-integrated package restore. Projects that use the deprecated MSBuild-integrated package restore should migrate to automatic package restore. + +These projects typically contain a *.nuget* folder with three files: *NuGet.config*, *nuget.exe*, and *NuGet.targets*. The *NuGet.targets* file causes NuGet to use the MSBuild-integrated approach, so it must be removed. To migrate to automatic package restore: +1. Enable automatic package restore. 1. Close Visual Studio. -2. Delete *.nuget/nuget.exe* and *.nuget/NuGet.targets*. -3. For each project file, remove the `` element and remove any reference to *NuGet.targets*. +1. Delete *.nuget/nuget.exe* and *.nuget/NuGet.targets*. +1. For each project file, remove the `` element, and remove any references to *NuGet.targets*. -To test the automatic package restore: +To test automatic package restore: 1. Remove the *packages* folder from the solution. -2. Open the solution in Visual Studio and start a build. - - Automatic package restore should download and install each dependency package, without adding them to source control. +1. Open the solution in Visual Studio and start a build. Automatic package restore should download and install each dependency package, without adding it to source control. -## Troubleshooting +## Next steps -See [Troubleshoot package restore](package-restore-troubleshooting.md). +- [Troubleshoot package restore](Package-restore-troubleshooting.md) +- [Manage the global packages, cache, and temp folders](managing-the-global-packages-and-cache-folders.md) diff --git a/docs/consume-packages/Package-Source-Mapping.md b/docs/consume-packages/Package-Source-Mapping.md new file mode 100644 index 000000000..c9b4cba54 --- /dev/null +++ b/docs/consume-packages/Package-Source-Mapping.md @@ -0,0 +1,177 @@ +--- +title: Package Source Mapping +description: Describes package source mapping functionality and how to onboard +author: nkolev92 +ms.author: nikolev +ms.date: 10/18/2023 +ms.topic: conceptual +--- + +# Package Source Mapping + +Package Source Mapping is a tool that can be used to improve your supply chain security, especially if you use a mix of public and private package sources. + +By default, NuGet will search all configured package sources when it needs to download a package. +When a package exists on multiple sources, it may not be deterministic which source the package will be downloaded from. +With Package Source Mapping, you can filter, per package, which source(s) NuGet will search. + +We also have suggestions for other [best practices](..\concepts\Security-Best-Practices.md) to help you fortify your supply chain against attacks. + +Package Source Mapping was added in [NuGet 6.0](..\release-notes\NuGet-6.0.md). +Starting with Visual Studio 17.5, you can add and remove Package Source Mappings with the Visual Studio Options Dialog. +For detailed information on all Visual Studio NuGet options, see [NuGet Options in Visual Studio](nuget-visual-studio-options.md). + +### Visual Studio support + +| Visual Studio | Package Source Mapping | Support in Tools -> Options | Support in Package Manager UI | +|-----|---------------------|---------------------|---------------------| +| 17.0 - 17.4 | ✅ Available | ❌ Not available | ❌ Not available | +| 17.5 | ✅ Available | ✅ Available | ❌ Not available | +| 17.7 Preview 3| ✅ Available | ✅ Available | ✅ Status displayed | + +The feature is available across all NuGet integrated tooling. + +* [Visual Studio 2022 and later](https://visualstudio.microsoft.com/downloads/) +* [.NET SDK 6.0.100 and later](https://dotnet.microsoft.com/download/dotnet/6.0) +* [nuget.exe 6.0.0 and later](https://www.nuget.org/downloads) + +Older tooling will ignore the Package Source Mapping configuration. To use this feature, ensure all your build environments use compatible tooling versions. + +Package Source Mappings will apply to all project types – including .NET Framework – as long as compatible tooling is used. + +## Video walkthrough + +For a video-based overview of the Package Source Mapping feature, consider watching the [Secure your NuGet packages with Package Source Mapping](https://www.youtube.com/watch?v=G6P38Dn69Ro) video on YouTube. + +## Enabling Package Source Mapping + +To opt into this feature, you must have a `nuget.config` file. Having a single `nuget.config` at the root of your repository is considered a best practice. See [nuget.config documentation](../reference/nuget-config-file.md) to learn more. + +### Enable by using Visual Studio Options Dialog + +1. Open your solution in Visual Studio. +2. Navigate to the `Package Source Mappings` Options Dialog. + +_From the Package Manager UI_ + +* Select a package from the list to show it in the Details Pane. +* Press the `Configure` button to open the Package Source Mappings options page. + +![The NuGet Package Manager window in Visual Studio showing a selected package, and a highlight around the "Package source mapping is off" status with a `Configure` button.](media/packageSourceMapping_PMUI_Status_Off_Annotated.png) + +_From the Visual Studio Options Dialog_ + +* Go to the `Tools` menu in the main Visual Studio toolbar, and choose `NuGet Package Manager` -> `Package Manager Settings`. +* Navigate to the `Package Source Mappings` page. + +For details about managing NuGet package source mappings, see [NuGet Options in Visual Studio](nuget-visual-studio-options.md#package-source-mapping). + +The NuGet Package Manager window will refresh and reflect the new status of the selected package's source mappings. +![The NuGet Package Manager window in Visual Studio showing a selected package with the "Package source mapping found" status with a `Configure` button.](media/packageSourceMapping_PMUI_Status_Mapped.png) + +### Enable by manually editing `nuget.config` + +* Declare your desired package sources in your `nuget.config` file. +* Following your source declarations, add a `` element that specifies the desired mappings for each source. +* Declare exactly one `packageSource` element for each source in use. + * Add as many patterns as you find necessary. + +```xml + + + + + + + + + + + + + + + + + + + + + + + + +``` + +Package Source Mapping settings are applied following [nuget.config precedence rules](configuring-nuget-behavior.md#how-settings-are-applied) when multiple `nuget.config` files at various levels (machine-level, user-level, repo-level) are present. + +## Package Source Mapping rules + +For maximum flexibility and control, NuGet requires that all packages match a package pattern through a well defined precedence. + +### Package Pattern requirements + +All requested packages must map to one or more sources by matching a defined package pattern. In other words, once you have defined a `packageSourceMapping` element you must explicitly define which sources _every_ package - _including transitive packages_ - will be restored from. + +* Both top-level _and transitive_ packages must match defined patterns. There is no requirement that a top level package and its dependencies come from the same source. +* The same ID pattern can be defined on multiple sources, allowing matching package IDs to be restored from any of the feeds that define the pattern. However, this isn't recommended due to the impact on restore predictability (a given package could come from multiple sources). This may be a valid configuration if you trust all respective sources. + +### Package Pattern Syntax + +| Pattern | Example syntax | Description | +|---------|---------|-------------| +| Package prefix pattern | `*`, `NuGet.*` | Must end with a `*`, where `*` matches 0 or more characters. `*` is the shortest allowed prefix pattern and matches all packages ids. | +| Package ID pattern | `NuGet.Common`, `Contoso.Contracts` | Exact package ID. | + +### Package Pattern precedence + +When multiple unique patterns match a package ID, the most specific one will be preferred. Package ID patterns always have the highest precedence while the generic `*` always has the lowest precedence. For package prefix patterns, the longest has precedence. + +![Package Pattern Precedence Examples](media/Package-Pattern-Examples.png) + +### Setting default sources + +The `*` pattern can be used to make a declare a de-facto default source - meaning any package that doesn't match other specified patterns will be restored from that source without throwing an error. +This configuration is advantageous if you primarily use packages from say, `nuget.org`, and only have a few internal packages, or use standard prefixes for all internal packages like `Contoso.*`. + +If your team doesn't use standard prefixes for internal package IDs or vets `nuget.org` packages prior to installation, then making a private source the default will suit your needs better. + +> [!Note] +> When the requested package already exists in the global packages folder, no source look-up will happen and the mappings will be ignored. Consider declaring a [global packages folder for your repo](../reference/nuget-config-file.md#config-section) to gain the full security benefits of this feature. Work to improve the experience with the default global packages folder is planned for a next iteration. +To learn more about how package installation works, see [the conceptual document.](../concepts/package-installation-process.md) + +### Get started + +There are 2 ways you can fully onboard your repository, [manually](#manual-onboarding) or using the [NuGet.PackageSourceMapper tool](#automated-onboarding-using-tool). + +#### Manual onboarding + +For manual onboarding you may take the following steps: + +1. Declare a new [global packages folder for your repo](../reference/nuget-config-file.md#config-section). +1. Run [dotnet restore](/dotnet/core/tools/dotnet-restore) to restore dependencies. +1. Run [`dotnet list package --include-transitive`](/dotnet/core/tools/dotnet-list-package#synopsis) to view all top-level and transitive packages in your solution. + * For .NET framework projects using [`packages.config`](../reference/packages-config.md), the `packages.config` file will have a flat list of all direct and transitive packages. +1. Define mappings such that every package ID in your solution - _including transitive packages_ - matches a pattern for the target source. +1. Run [dotnet nuget locals global-packages -c](/dotnet/core/tools/dotnet-nuget-locals) to clear global-packages directory. +1. Run restore to validate that you have configured your mappings correctly. If your mappings don't fully cover every package ID in your solution, the error messages will help you identify the issue. +1. When restore succeeds, you are done! Optionally consider: + * Simplifying the configuration to fewer declarations by using broader package ID prefixes or [setting a default source](#setting-default-sources) where possible. + * Verifying the source each package was restored from by checking the [metadata files in the global packages folder or reviewing the restore logs](https://devblogs.microsoft.com/nuget/performance-and-polish-with-nuget-5-9/). + +#### Automated onboarding using tool + +Many repositories have a large number of packages and doing the work manually can be time consuming. The [NuGet.PackageSourceMapper tool](https://www.nuget.org/packages/NuGet.PackageSourceMapper) can automatically generate a NuGet.config for you, based on your project's known packages and sources. + +The package source mapper tool requires you to have completed a successful package restore in which it will read each respective `.nupkg.metadata` file generated as part of your build to best understand how you map your respective packages and sources. Tool not only covers top dependencies it also considers all the transitive dependencies when generating mapping. + +Tool has several option how to generate mapping pattern depending on your need, please check [blog post](https://devblogs.microsoft.com/nuget/quickly-map-your-nuget-packages-to-sources) and tool's [readme instruction](https://www.nuget.org/packages/NuGet.PackageSourceMapper#readme-body-tab) for more details. + +For an idea of how your source mappings may look like, refer to our [samples repo](https://github.com/NuGet/Samples/tree/main/PackageSourceMappingExample). + +> [!Note] +> +> * There are no nuget.exe or dotnet.exe commands for managing the package source mapping configuration, see [NuGet/Home#10735](https://github.com/NuGet/Home/issues/10735). +> * There are no means of mapping packages at package installation time, see [NuGet/Home#10730](https://github.com/NuGet/Home/issues/10730). +> * There is a limitation when using the `DotNetCoreCLI@2` Azure Pipelines task which can be worked around by using `feed-` prefixes in your source mapping configuration. It is recommended however to use `NuGetAuthenticate` for your authentication needs and call the dotnet cli directly from a script task. See [microsoft/azure-pipelines-tasks#15542](https://github.com/microsoft/azure-pipelines-tasks/issues/15542). diff --git a/docs/consume-packages/Package-restore-troubleshooting.md b/docs/consume-packages/Package-restore-troubleshooting.md index 1f3095255..00c9957c0 100644 --- a/docs/consume-packages/Package-restore-troubleshooting.md +++ b/docs/consume-packages/Package-restore-troubleshooting.md @@ -1,15 +1,17 @@ --- title: Troubleshooting NuGet Package Restore in Visual Studio description: A description of common NuGet restore errors in Visual Studio and how to troubleshoot them. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 05/25/2018 ms.topic: conceptual --- # Troubleshooting package restore errors -This article focuses on common errors when restoring packages and steps to resolve them. For complete details on restoring packages, see [Package restore](../consume-packages/package-restore.md#enable-and-disable-package-restore-visual-studio). +This article focuses on common errors when restoring packages and steps to resolve them. + +Package Restore tries to install all package dependencies to the correct state matching the package references in your project file (*.csproj*) or your *packages.config* file. (In Visual Studio, the references appear in Solution Explorer under the **Dependencies \ NuGet** or the **References** node.) To follow the required steps to restore packages, see [Restore packages](../consume-packages/package-restore.md#restore-packages). If the package references in your project file (*.csproj*) or your *packages.config* file are incorrect (they do not match your desired state following Package Restore), then you need to either install or update packages instead of using Package Restore. If the instructions here do not work for you, [please file an issue on GitHub](https://github.com/NuGet/docs.microsoft.com-nuget/issues) so that we can examine your scenario more carefully. Do not use the "Is this page helpful?" control that may appear on this page because it doesn't give us the ability to contact you for more information. @@ -22,9 +24,9 @@ If you're using Visual Studio, first enable package restore as follows. Otherwis 1. Select **OK**. 1. Build your project again. -![Enable NuGet package restore in Tool/Options](../consume-packages/media/restore-01-autorestoreoptions.png) +![Enable NuGet package restore in Tool/Options](../consume-packages/media/vsoptions/general.png) -These settings can also be changed in your `NuGet.config` file; see the [consent](#consent) section. If your project is an older project that uses the MSBuild-integrated package restore, you may need to [migrate](package-restore.md#migrate-to-automatic-package-restore-visual-studio) to automatic package restore. +These settings can also be changed in your `NuGet.Config` file; see the [consent](#consent) section. If your project is an older project that uses the MSBuild-integrated package restore, you may need to [migrate](package-restore.md#migrate-to-automatic-package-restore-visual-studio) to automatic package restore. @@ -39,8 +41,8 @@ Use NuGet Package Restore to download them. The missing file is {name}. This error occurs when you attempt to build a project that contains references to one or more NuGet packages, but those packages are not presently installed on the computer or in the project. -- When using the PackageReference management format, the error means that the package is not installed in the *global-packages* folder as described on [Managing the global packages and cache folders](managing-the-global-packages-and-cache-folders.md). -- When using `packages.config`, the error means that the package is not installed in the `packages` folder at the solution root. +- When using the [PackageReference](package-references-in-project-files.md) management format, this error might be a leftover from a packages.config to PackageReference migration and needs to be [manually removed](/nuget/resources/nuget-faq#working-with-packages) from the project file. +- When using [packages.config](../reference/packages-config.md), the error means that the package is not installed in the `packages` folder at the solution root. This situation commonly occurs when you obtain the project's source code from source control or another download. Packages are typically omitted from source control or downloads because they can be restored from package feeds like nuget.org (see [Packages and source control](Packages-and-Source-Control.md)). Including them would otherwise bloat the repository or create unnecessarily large .zip files. @@ -49,10 +51,12 @@ The error can also happen if your project file contains absolute paths to packag Use one of the following methods to restore the packages: - If you've moved the project file, edit the file directly to update the package references. -- (Visual Studio) Enable package restore by selecting the **Tools > NuGet Package Manager > Package Manager Settings** menu command, setting both options under **Package Restore**, and selecting **OK**. Then build the solution again. -- (dotnet CLI) In the command line, switch to the folder that contains your project, and then run `dotnet restore` or `dotnet build` (which automatically runs restore). -- (nuget.exe CLI) In the command line, switch to the folder that contains your project, and then run `nuget restore` (except for projects created with `dotnet` CLI, in which case use `dotnet restore`). -- (Projects migrated to PackageReference) On the command line, run `msbuild -t:restore`. +- [Visual Studio](package-restore.md#restore-using-visual-studio) ([automatic restore](package-restore.md#restore-packages-automatically-using-visual-studio) or [manual restore](package-restore.md#restore-packages-manually-using-visual-studio)) +- [dotnet CLI](package-restore.md#restore-using-the-dotnet-cli) +- [nuget.exe CLI](package-restore.md#restore-using-the-nugetexe-cli) +- [MSBuild](package-restore.md#restore-using-msbuild) +- [Azure Pipelines](package-restore.md#restore-using-azure-pipelines) +- [Azure DevOps Server](package-restore.md#restore-using-azure-devops-server) After a successful restore, the package should be present in the *global-packages* folder. For projects using PackageReference, a restore should recreate the `obj/project.assets.json` file; for projects using `packages.config`, the package should appear in the project's `packages` folder. The project should now build successfully. If not, [file an issue on GitHub](https://github.com/NuGet/docs.microsoft.com-nuget/issues) so we can follow up with you. @@ -105,7 +109,7 @@ You can also edit these settings directly in the applicable `nuget.config` file ## Other potential conditions -- You may encounter build errors due to missing files, with a message saying to use NuGet restore to download them. However, running a restore might say, "All packages are already installed and there is nothing to restore." In this case, delete the `packages` folder (when using `packages.config`) or the `obj/project.assets.json` file (when using PackageReference) and run restore again. If the error still persists, use `nuget locals all -clear` or `dotnet locals all --clear` from the command line to clear the *global-packages* and cache folders as described on [Managing the global packages and cache folders](managing-the-global-packages-and-cache-folders.md). +- You may encounter build errors due to missing files, with a message saying to use NuGet restore to download them. However, running a restore might say, "All packages are already installed and there is nothing to restore." In this case, delete the `packages` folder (when using `packages.config`) or the `obj/project.assets.json` file (when using PackageReference) and run restore again. If the error still persists, use `nuget locals all -clear` or `dotnet nuget locals all --clear` from the command line to clear the *global-packages* and cache folders as described on [Managing the global packages and cache folders](managing-the-global-packages-and-cache-folders.md). - When obtaining a project from source control, your project folders may be set to read-only. Change the folder permissions and try restoring packages again. diff --git a/docs/consume-packages/PackageDownload-Functionality.md b/docs/consume-packages/PackageDownload-Functionality.md new file mode 100644 index 000000000..2d926ad2e --- /dev/null +++ b/docs/consume-packages/PackageDownload-Functionality.md @@ -0,0 +1,77 @@ +--- +title: Download packages with PackageDownload +description: Describes the PackageDownload feature, which is a complement to PackageReference. +author: nkolev92 +ms.author: nikolev +ms.date: 12/22/2021 +ms.topic: conceptual +--- + +# PackageDownload + +Starting with Visual Studio 2017 and .NET SDK 1.0.0, NuGet [PackageReference](Package-References-in-Project-Files.md) functionality was added. + +`PackageReference` allows you to manage your package dependencies directly in your project file. +When you run restore, the transitive dependencies are resolved automatically and the applicable references are chosen for each package in the project graph. + +In [NuGet version 5.3](..\release-notes\NuGet-5.3.md) a companion feature was introduced for [.NET SDK-style projects](..\resources\check-project-format.md) called `PackageDownload`, which allows you to download the package without including its files in the project. + +## PackageDownload specification + +PackageDownload is a utility feature for all .NET SDK-style projects, and it works along side `PackageReference`. + +`PackageDownload` items support different attributes compared to `PackageReference`. Only attributes listed in the below table are supported. + +| Attributes | Description | Example | +|------------|-------------|---------| +| Version | Only exact versions, surrounded with `[]` are supported. Multiple versions can be specified separated by `;` | `[1.0.0]`, `[1.0.0];[2.0.0]` | + +Packages acquired through PackageDownload will undergo the same [installation process](..\concepts\package-installation-process.md) as packages acquired through PackageReference. +This means [package signatures](installing-signed-packages.md) are validated, [package source mapping](Package-Source-Mapping.md) is considered. +All newly acquired PackageDownload packages will be installed in the global packages folder. + +| Feature | PackageReference | PackageDownload | +|-|------------------|-----------------| +| Package assets selection | Assemblies from packages are automatically added to the project and can be used for compile and runtime | No assets from the package are included in the project. | +| Dependencies | Automatically resolved, and flattened to a single version | Not considered at all | +| pack | Included in the package specification | Not included in the package specification. | +| Transitivity | PackageReference items are automatically propagated to dependant projects | PackageDownload items are ignored by dependant projects | +| Version | Version ranges such as `1.0.0` or `[1.0.0, )` are supported. Exactly 1 version is allowed. | Only exact versions are supported. More than 1 version can be downloaded. | +| dotnet list package | All dependencies are included | PackageDownload packages are not shown by `dotnet list package`. | + +Due to the fact that PackageDownload are not tied to the project in any way beyond acquisition, multiple versions of the same package can be downloaded. + +### PackageDownload limitations + +Given that this is an advanced feature with limited applicability, it doesn't have a tooling support equivalent to PackageReference. + +- There is no VisualStudio or dotnet.exe functionality to modify PackageDownload items. You can only change them manually in your project files. +- dotnet add, remove, and list commands do not account for PackageDownload items. +- PackageDownload items are *not* part of the [packages lock file](package-references-in-project-files.md#locking-dependencies). + +### PackageDownload applications + +The primary application of PackageDownload is downloading packages that do not follow the traditional NuGet package structure and primarily carry build time dependencies. + +Ideally, all your dependencies are expressed through PackageReference, but in scenarios where that's not possible, or often times not practical yet, you can use this feature to simply `download` packages to a certain location, in a similar way that you could achieve that with a `packages.config` file not tied to a project. + +Example: + +```xml + + + + + packages/ + $(RestorePackagesPath)obj/ + net5.0 + true + false + + + + + + + +``` diff --git a/docs/consume-packages/Packages-and-Source-Control.md b/docs/consume-packages/Packages-and-Source-Control.md index 8fe1b090a..dd01f03a7 100644 --- a/docs/consume-packages/Packages-and-Source-Control.md +++ b/docs/consume-packages/Packages-and-Source-Control.md @@ -1,8 +1,8 @@ --- title: NuGet Packages and Source Control description: Considerations for how to treat NuGet packages within version control and source control systems, and how to omit packages with git and TFVC. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 03/16/2018 ms.topic: conceptual --- @@ -75,7 +75,7 @@ To disable source control integration with TFVC for selected files: 1. If you are using TFS 2010 or earlier, cloak the `packages` folder in your workspace mappings. -1. On TFS 2012 or later, or with Visual Studio Team Services, create a `.tfignore` file as described on [Add Files to the Server](/vsts/tfvc/add-files-server?view=vsts#tfignore). In that file, include the content below to explicitly ignore modifications to the `\packages` folder on the repository level and a few other intermediate files. (You can create the file in Windows Explorer using the name a `.tfignore.` with the trailing dot, but you might need to disable the "Hide known file extensions" option first.): +1. On TFS 2012 or later, or with Visual Studio Team Services, create a `.tfignore` file as described on [Add Files to the Server](/vsts/tfvc/add-files-server?view=vsts#tfignore&preserve-view=true). In that file, include the content below to explicitly ignore modifications to the `\packages` folder on the repository level and a few other intermediate files. (You can create the file in Windows Explorer using the name a `.tfignore.` with the trailing dot, but you might need to disable the "Hide known file extensions" option first.): ```cli # Ignore NuGet Packages @@ -85,9 +85,6 @@ To disable source control integration with TFVC for selected files: # with additional folder names if it's not in the same folder as .tfignore. packages - # Exclude package target files which may be required for MSBuild, again prefixing the folder name as needed. - !packages/*.targets - # Omit temporary files project.lock.json project.assets.json diff --git a/docs/consume-packages/Reinstalling-and-Updating-Packages.md b/docs/consume-packages/Reinstalling-and-Updating-Packages.md index 857da6213..574b5257c 100644 --- a/docs/consume-packages/Reinstalling-and-Updating-Packages.md +++ b/docs/consume-packages/Reinstalling-and-Updating-Packages.md @@ -1,47 +1,75 @@ --- -title: Reinstalling and Updating NuGet Packages -description: Details on when it's necessary to reinstall and update packages, as with broken package references in Visual Studio. -author: karann-msft -ms.author: karann -ms.date: 12/07/2017 +title: Reinstall and update NuGet packages in Visual Studio +description: Learn how to reinstall and update NuGet packages to address broken package references and broken projects in Visual Studio. +author: JonDouglas +ms.author: jodou +ms.date: 11/03/2023 ms.topic: conceptual --- -# How to reinstall and update packages +# Reinstall and update NuGet packages in Visual Studio -There are a number of situations, described below under [When to Reinstall a Package](#when-to-reinstall-a-package), where references to a package might get broken within a Visual Studio project. In these cases, uninstalling and then reinstalling the same version of the package will restore those references to working order. Updating a package simply means installing an updated version, which often restores a package to working order. +Sometimes package references can break within a Visual Studio project. Uninstalling and reinstalling the same version of the package often restores the references to working order. Updating a package, which installs an updated version, can also resolve the issue. This article describes how to reinstall and update NuGet packages to address broken package references and broken projects. -Updating and reinstalling packages is accomplished as follows: +> [!NOTE] +> The guidance in this article applies only to projects that use the [packages.config](../reference/packages-config.md) management format. For [PackageReference](../consume-packages/Package-References-in-Project-Files.md) projects, a restore operation automatically fixes broken references. -| Method | Update | Reinstall | -| --- | --- | --- | -| Package Manager console (described in [Using Update-Package](#using-update-package)) | `Update-Package` command | `Update-Package -reinstall` command | -| Package Manager UI | On the **Updates** tab, select one or more packages and select **Update** | On the **Installed** tab, select a package, record its name, then select **Uninstall**. Switch to the **Browse** tab, search for the package name, select it, then select **Install**). | -| nuget.exe CLI | `nuget update` command | For all packages, delete the package folder, then run `nuget install`. For a single package, delete the package folder and use `nuget install ` to reinstall the same one. | +## Common scenarios -> [!NOTE] -> For the dotnet CLI, the equivalent procedure is not required. In a similar scenario, you can [restore packages with the dotnet CLI](../consume-packages/install-use-packages-dotnet-cli.md#restore-packages). +Here are some common scenarios where you might encounter broken package references in your Visual Studio project. + +| Scenario | Description | Resolution | +|---|---|---| +| **Broken references after package restore** | You open your Visual Studio project and restore NuGet packages, but broken package references remain. | To fix the references, try reinstalling each package separately. | +| **Broken project due to deleted files** | Deleted (missing) package files cause your project to break. NuGet doesn't prevent deleting items that you add from packages. It can be easy to inadvertently modify contents installed from a package and break your project. | To restore your project, try reinstalling the affected packages. | +| **Broken project after package update** | A package update breaks your project. Companion updates to a dependency package generally cause this type of failure. | To restore the state of the dependency to its previous working order, try reinstalling the specific dependent package. | +| **Broken references after project retarget or upgrade** | A project retarget or upgrade process causes broken package references. After you retarget your project, NuGet shows a build error. Build warnings list packages that might need to be reinstalled. Or, after you upgrade your project, NuGet shows an error in the project upgrade log. The log file lists packages that might need to be reinstalled. | To resolve issues due to a change in target framework, try reinstalling one or more packages. | +| **Package changes under development** | Package authors often need to reinstall the same version of a package they're currently developing to test their changes. | The NuGet Package Manager Console in Visual Studio provides flexible options for updating and reinstalling packages. To reinstall a package under development, you can use the `Update-Package -reinstall` command. | + +## Implementation options + +You have several choices for how to update and reinstall NuGet packages. Common methods include NuGet Package Manager UI options, the NuGet Package Manager Console, and the NuGet (Command Line Interface) CLI. + +### Package Manager UI + +In addition to the Console interface, the Package Manager UI also provides menu options to install, update, and uninstall packages. + +- To update a package, open the **Updates** tab, choose one or more packages, then select **Update**. + +- To reinstall a package, first uninstall the package and then install it again. Open the **Installed** tab, choose a package and record its name, then select **Uninstall**. Switch to the **Browse** tab and search for the package name, choose the package, then select **Install**. + +### Package Manager Console -In this article: +You can access the Package Manager Console under **Tools** > **NuGet Package Manager** > **Package Manager Console**. -- [When to Reinstall a Package](#when-to-reinstall-a-package) -- [Constraining upgrade versions](#constraining-upgrade-versions) +- To update a package, the Package Manager Console provides the `Update-Package` command. -## When to Reinstall a Package +- To reinstall a package, you can use the same command with the `-reinstall` parameter. This approach is the easiest option, if it's compatible with your configuration. -1. **Broken references after package restore**: If you've opened a project and restored NuGet packages, but still see broken references, try reinstalling each of those packages. -1. **Project is broken due to deleted files**: NuGet does not prevent you from removing items added from packages, so it's easy to inadvertently modify contents installed from a package and break your project. To restore the project, reinstall the affected packages. -1. **Package update broke the project**: If an update to a package breaks a project, the failure is generally caused by a dependency package which may have also been updated. To restore the state of the dependency, reinstall that specific package. -1. **Project retargeting or upgrade**: This can be useful when a project has been retargeted or upgraded and if the package requires reinstallation due to the change in target framework. NuGet shows a build error in such cases immediately after project retargeting, and subsequent build warnings let you know that the package may need to be reinstalled. For project upgrade, NuGet shows an error in the Project Upgrade Log. -1. **Reinstalling a package during its development**: Package authors often need to reinstall the same version of package they're developing to test the behavior. The `Install-Package` command does not provide an option to force a reinstall, so use `Update-Package -reinstall` instead. +For more information, see the [Update-Package command](#update-package-command) and [Package reinstall considerations](#package-reinstall-considerations) sections. -## Constraining upgrade versions +### NuGet CLI -By default, reinstalling or updating a package *always* installs the latest version available from the package source. +The NuGet CLI, `nuget.exe`, is the command-line utility for Windows that provides all NuGet capabilities. -In projects using the `packages.config` management format, however, you can specifically constrain the version range. For example, if you know that your application works only with version 1.x of a package but not 2.0 and above, perhaps due to a major change in the package API, then you'd want to constrain upgrades to 1.x versions. This prevents accidental updates that would break the application. +- To update an installed package, run the `nuget update` command. -To set a constraint, open `packages.config` in a text editor, locate the dependency in question, and add the `allowedVersions` attribute with a version range. For example, to constrain updates to version 1.x, set `allowedVersions` to `[1,2)`: +- To reinstall all NuGet packages, delete the package folder and then run the `nuget install` command. + +- To reinstall a single package, delete the package folder and then run the `nuget install ` command, where the `` argument is the ID of the specific package. + +> [!NOTE] +> For the **dotnet CLI**, the equivalent procedure isn't required. When you run the `dotnet restore` command, the dotnet CLI uses NuGet to determine dependencies and download any necessary NuGet packages. For more information, see [Restore NuGet packages with the dotnet CLI](package-restore.md#restore-using-the-dotnet-cli). + +## Constraints on upgrade versions + +By default, reinstalling or updating a package _always_ installs the latest version available from the package source. However, projects that use the `packages.config` management format can specifically limit the allowed NuGet package version range. + +Suppose your application works only with version 1.x of a package, but not with version 2.0 or later, due to a major change in the package API. To ensure your application works as expected, you want to constrain NuGet package upgrades to versions 1.x only. The limitation helps to prevent accidental updates that might break your application. + +To set a constraint, open the `packages.config` file in a text editor. Locate the dependency that you want to limit, and add the `allowedVersions` attribute with your desired version range. + +The following example shows how to constrain updates to version 1.x by setting the `allowedVersions` attribute to `[1,2)`: ```xml @@ -52,65 +80,106 @@ To set a constraint, open `packages.config` in a text editor, locate the depende ``` -In all cases, use the notation described in [Package versioning](../reference/package-versioning.md#version-ranges-and-wildcards). +In all cases, use the notation described in [Package versioning](../concepts/package-versioning.md#version-ranges). + +## Update-Package command -## Using Update-Package +The [Update-Package command](../reference/ps-reference/ps-ref-update-package.md) in the Package Manager Console is the easiest way to reinstall a package and address broken references. However, this approach isn't usable in all scenarios. You can use the command to update an installed package, but not to do an initial install. If you try to update or reinstall a package that isn't already installed in the configuration, the command returns an error. Be sure to review the [Package reinstall considerations](#package-reinstall-considerations) section before working with the command. -Being mindful of the [Considerations](#considerations) described below, you can easily reinstall any package using the [Update-Package command](../reference/ps-reference/ps-ref-update-package.md) in the Visual Studio Package Manager Console (**Tools** > **NuGet Package Manager** > **Package Manager Console**): +Updating packages in a project or solution by using [PackageReference](../Consume-Packages/Package-References-in-Project-Files.md) always updates to the latest version of the package (excluding prerelease packages). Projects that use the `packages.config` management format can limit upgrade versions as described in [Constraints on upgrade versions](#constraints-on-upgrade-versions). -```ps +The following sections provide examples for working with the command. + +### Reinstall package options + +Here's a basic usage of the command to do a reinstall. To identify a specific NuGet package, you can use the optional `-Id` parameter. + +```powershell +# Reinstall the package named Update-Package -Id –reinstall ``` -Using this command is much easier than removing a package and then trying to locate the same package in the NuGet gallery with the same version. Note that the `-Id` switch is optional. +Using the `Update-Package` command is easier than removing a package and then trying to locate the same package in the NuGet gallery with the same version. -The same command without `-reinstall` updates a package to a newer version, if applicable. The command gives an error if the package in question is not already installed in a project; that is, `Update-Package` does not install packages directly. +### Update package options -```ps +The same command without the `-reinstall` parameter updates a package to a newer version, if applicable. The command returns an error if the specified package isn't already installed in a project. + +```powershell +# Update the package named Update-Package ``` -By default, `Update-Package` affects all projects in a solution. To limit the action to a specific project, use the `-ProjectName` switch, using the name of the project as it appears in Solution Explorer: +### Project and solution options + +By default, the `Update-Package` command affects all projects in a solution. To limit the action to a specific project, use the `-ProjectName` parameter. Provide the name of the project as it appears in Visual Studio Solution Explorer. -```ps -# Reinstall the package in just MyProject +The following command reinstalls a NuGet package for a specific project in your solution. The name of the specific NuGet package to reinstall is provided in the `` parameter. + +```powershell +# Reinstall the package named in MyProject only Update-Package -ProjectName MyProject -reinstall ``` -To *update* all packages in a project (or reinstall using `-reinstall`), use `-ProjectName` without specifying any particular package: +If you want to reinstall all packages in your project, use the `-ProjectName` parameter by don't specify any particular package. You can follow this same approach to update the packages in your project, as shown in this example: -```ps +```powershell +# Update all packages in MyProject only Update-Package -ProjectName MyProject ``` -To update all packages in a solution, just use `Update-Package` by itself with no other arguments or switches. Use this form carefully, because it can take considerable time to perform all the updates: +To update all packages in a solution, just use the `Update-Package` command by itself with no other arguments or parameters. + +> [!IMPORTANT] +> Be sure to use the following form of the command carefully. The command process can take considerable time to perform all of the updates. -```ps -# Updates all packages in all projects in the solution +```powershell +# Update all packages in all projects in the solution Update-Package ``` -Updating packages in a project or solution using [PackageReference](../Consume-Packages/Package-References-in-Project-Files.md) always updates to the latest version of the package (excluding pre-release packages). Projects that use `packages.config` can, if desired, limit update versions as described below in [Constraining upgrade versions](#constraining-upgrade-versions). +## Package reinstall considerations + +If you intend to use the `Update-Package` command to reinstall packages, review the following considerations to ensure compatibility with your configuration scenario. + +- Packages and their dependencies might not support a retargeted project target framework. +- When the `requireReinstallation` attribute is set to `true`, Visual Studio issues build warnings for affected packages. +- Reinstall of a package and version constraints can introduce dependency version compatibility issues. +- Reinstall of a specific package can cause dependent packages to break. + +### Package doesn't support project target framework + +If you retarget your project target framework, one or more packages might not support the new target configuration. + +Usually, reinstalling a package with the `Update-Package –reinstall ` command works. A package installed against an old target framework is uninstalled and the same package is installed against the new target framework of the project. + +In some cases, a package might not support the new target framework. Here are some of the issues you might encounter: + +- If a package supports portable class libraries (PCLs), and you retarget the project to a combination of platforms no longer supported by the package, references to the package can be missing after reinstalling. + +- This issue can surface for packages you use directly or for packages installed as dependencies. Any package that you use directly might support the new target framework while their dependencies don't. + +- If reinstalling packages after retargeting your application results in build or runtime errors, you might need to revert your target framework or search for alternative packages that properly support your new target framework. + +### requireReinstallation attribute set to true + +After you retarget your project target framework or upgrade NuGet packages, NuGet might add the `requireReinstallation` attribute to the `packages.config` file for your project. If NuGet detects affected packages during the retargeting or upgrading process, it adds a `requireReinstallation="true"` attribute to the `packages.config` file for all affected package references. As a result, each subsequent build of your project in Visual Studio raises build warnings for those packages. The warnings are presented as a reminder to reinstall the affected package. + +### Package dependency version incompatibility -For full details on the command, see the [Update-Package](../reference/ps-reference/ps-ref-update-package.md) reference. +The `Update-Package –reinstall` command reinstalls the **same** version of an installed package and the **latest** version of any dependencies. To address version incompatibility issues, you can set version range constraints to control the configuration. NuGet adheres to the constraints and updates the package dependencies to newer versions only as required to fix an issue. -### Considerations +- If your constraint settings cause a dependency to revert to an earlier version during package reinstall, you can address the issue with the `Update-Package ` command. This command reinstalls the specified dependency without affecting the dependent package. -The following may be affected when reinstalling a package: +- You can also use the `Update-Package –reinstall -ignoreDependencies` command. This option reinstalls the same version of the original package, but it doesn't reinstall dependencies. Use this approach when updating package dependencies might result in a broken configuration state. -1. **Reinstalling packages according to project target framework retargeting** - - In a simple case, just reinstalling a package using `Update-Package –reinstall ` works. A package that is installed against an old target framework gets uninstalled and the same package gets installed against the current target framework of the project. - - In some cases, there may be a package that does not support the new target framework. - - If a package supports portable class libraries (PCLs) and the project is retargeted to a combination of platforms no longer supported by the package, references to the package will be missing after reinstalling. - - This can surface for packages you're using directly or for packages installed as dependencies. It's possible for the package you're using directly to support the new target framework while its dependency does not. - - If reinstalling packages after retargeting your application results in build or runtime errors, you may need to revert your target framework or search for alternative packages that properly support your new target framework. +### Broken dependent package -1. **requireReinstallation attribute added in packages.config after project retargeting or upgrade** - - If NuGet detects that packages were affected by retargeting or upgrading a project, it adds a `requireReinstallation="true"` attribute in `packages.config` to all affected package references. Because of this, each subsequent build in Visual Studio raises build warnings for those packages so you can remember to reinstall them. +When you reinstall a specific package, any installed packages that depend on the reinstalled package aren't updated. The versions of these other installed packages remain the same. As a result, reinstalling a dependency can break a dependent package. -1. **Reinstalling packages with dependencies** - - `Update-Package –reinstall` reinstalls the same version of the original package, but installs the latest version of dependencies unless specific version constraints are provided. This allows you to update only the dependencies as required to fix an issue. However, if this rolls a dependency back to an earlier version, you can use `Update-Package ` to reinstall that one dependency without affecting the dependent package. - - `Update-Package –reinstall -ignoreDependencies` reinstalls the same version of the original package but does not reinstall dependencies. Use this when updating package dependencies might result in a broken state +## Related articles -1. **Reinstalling packages when dependent versions are involved** - - As explained above, reinstalling a package does not change versions of any other installed packages that depend on it. It's possible, then, that reinstalling a dependency could break the dependent package. +- Review the [packages.config](../reference/packages-config.md) management format. +- Implement [PackageReference](../consume-packages/Package-References-in-Project-Files.md) in project files. +- Use the [Update-Package command](../reference/ps-reference/ps-ref-update-package.md) in the NuGet Package Manager Console in Visual Studio. +- Explore [package versioning](../concepts/package-versioning.md#version-ranges) notation formats. diff --git a/docs/consume-packages/Team-Foundation-Build.md b/docs/consume-packages/Team-Foundation-Build.md index 174450244..8d8fb405a 100644 --- a/docs/consume-packages/Team-Foundation-Build.md +++ b/docs/consume-packages/Team-Foundation-Build.md @@ -1,8 +1,8 @@ --- title: Walkthrough of NuGet Package Restore with Team Foundation Build description: A walkthrough of how NuGet package restore with with Team Foundation Build (both TFS and Visual Studio Team Services). -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 01/09/2017 ms.topic: conceptual --- @@ -26,7 +26,7 @@ If you're using Visual Studio Team Services or Team Foundation Server 2013 with An advantage of using NuGet is that you can use it to avoid checking in binaries to your version control system. -This is especially interesting if you are using a [distributed version control](http://en.wikipedia.org/wiki/Distributed_revision_control) system like git because developers need to clone the entire repository, including the full history, before they can start working locally. Checking in binaries can cause significant repository bloat as binary files are typically stored without delta compression. +This is especially interesting if you are using a [distributed version control](https://en.wikipedia.org/wiki/Distributed_revision_control) system like git because developers need to clone the entire repository, including the full history, before they can start working locally. Checking in binaries can cause significant repository bloat as binary files are typically stored without delta compression. NuGet has supported [restoring packages](../consume-packages/package-restore.md) as part of the build for a long time now. The previous implementation had a chicken-and-egg problem for packages that want to extend the build process because NuGet restored packages while building the project. However, MSBuild doesn't allow extending the build during the build; one could argue that this an issue in MSBuild but I would argue that this is an inherent problem. Depending on which aspect you need to extend it might be too late to register by the time your package is restored. @@ -45,30 +45,32 @@ The following demo project shows how to set up the build in such a way that the ## Repository structure -Our demo project is a simple command line tool that uses the command line argument to query Bing. It targets the .NET Framework 4 and uses many of the [BCL packages](http://www.nuget.org/profiles/dotnetframework/) ([Microsoft.Net.Http](http://www.nuget.org/packages/Microsoft.Net.Http), [Microsoft.Bcl](http://www.nuget.org/packages/Microsoft.Bcl), [Microsoft.Bcl.Async](http://www.nuget.org/packages/Microsoft.Bcl.Async), and [Microsoft.Bcl.Build](http://www.nuget.org/packages/Microsoft.Bcl.Build)). +Our demo project is a simple command line tool that uses the command line argument to query Bing. It targets the .NET Framework 4 and uses many of the [BCL packages](https://www.nuget.org/profiles/dotnetframework/) ([Microsoft.Net.Http](https://www.nuget.org/packages/Microsoft.Net.Http), [Microsoft.Bcl](https://www.nuget.org/packages/Microsoft.Bcl), [Microsoft.Bcl.Async](https://www.nuget.org/packages/Microsoft.Bcl.Async), and [Microsoft.Bcl.Build](https://www.nuget.org/packages/Microsoft.Bcl.Build)). The structure of the repository looks as follows: - - │ .gitignore - │ .tfignore - │ build.proj - │ - ├───src - │ │ BingSearcher.sln - │ │ - │ └───BingSearcher - │ │ App.config - │ │ BingSearcher.csproj - │ │ packages.config - │ │ Program.cs - │ │ - │ └───Properties - │ AssemblyInfo.cs - │ - └───tools - └───NuGet - nuget.exe +``` + + │ .gitignore + │ .tfignore + │ build.proj + │ + ├───src + │ │ BingSearcher.sln + │ │ + │ └───BingSearcher + │ │ App.config + │ │ BingSearcher.csproj + │ │ packages.config + │ │ Program.cs + │ │ + │ └───Properties + │ AssemblyInfo.cs + │ + └───tools + └───NuGet + nuget.exe +``` You can see that we haven't checked-in the `packages` folder nor any `.targets` files. @@ -79,7 +81,7 @@ The source code is under the `src` folder. Although our demo only uses a single ### Ignore files > [!Note] -> There is currently a [known bug in the NuGet client](https://nuget.codeplex.com/workitem/4072) that causes the client to still add the `packages` folder to version control. A workaround is to disable the source control integration. In order to do that, you need a `Nuget.Config ` file in the `.nuget` folder that is parallel to your solution. If this folder doesn't exist yet, you need to create it. In [`Nuget.Config`](../consume-packages/configuring-nuget-behavior.md), add the following content: +> There is currently a `[known bug in the NuGet client](https://nuget.codeplex.com/workitem/4072)` that causes the client to still add the `packages` folder to version control. A workaround is to disable the source control integration. In order to do that, you need a `Nuget.Config ` file in the `.nuget` folder that is parallel to your solution. If this folder doesn't exist yet, you need to create it. In [`Nuget.Config`](../consume-packages/configuring-nuget-behavior.md), add the following content: ```xml @@ -93,33 +95,39 @@ To communicate to version control that we don’t intent to check-in the **packa The `.gitignore` file looks as follows: - syntax: glob - *.user - *.suo - bin - obj - packages - *.nupkg - project.lock.json - project.assets.json +``` +syntax: glob +*.user +*.suo +bin +obj +packages +*.nupkg +project.lock.json +project.assets.json +``` The `.gitignore` file is [quite powerful](https://www.kernel.org/pub/software/scm/git/docs/gitignore.html). For example, if you want to generally not check-in the contents of the `packages` folder but want to go with previous guidance of checking in the `.targets` files you could have the following rule instead: - packages - !packages/**/*.targets +``` +packages +!packages/**/*.targets +``` This will exclude all `packages` folders but will re-include all contained `.targets` files. By the way, you can find a template for `.gitignore` files that is specifically tailored for the needs of Visual Studio developers [here](https://github.com/github/gitignore/blob/master/VisualStudio.gitignore). TF version control supports a very similar mechanism via the [.tfignore](/vsts/tfvc/add-files-server#customize-which-files-are-ignored-by-version-control) file. The syntax is virtually the same: - *.user - *.suo - bin - obj - packages - *.nupkg - project.lock.json - project.assets.json +``` +*.user +*.suo +bin +obj +packages +*.nupkg +project.lock.json +project.assets.json +``` ## build.proj diff --git a/docs/consume-packages/configuring-nuget-behavior.md b/docs/consume-packages/configuring-nuget-behavior.md index df2e5b9cb..ac178fc79 100644 --- a/docs/consume-packages/configuring-nuget-behavior.md +++ b/docs/consume-packages/configuring-nuget-behavior.md @@ -1,34 +1,51 @@ --- title: Common NuGet configurations -description: NuGet.Config files control NuGet's behavior both globally and on a per-project basis, and are modified with nuget config command. -author: karann-msft -ms.author: karann -ms.date: 10/25/2017 +description: NuGet.Config files control NuGet's behavior, and can be modified with nuget config command. +author: JonDouglas +ms.author: jodou +ms.date: 01/10/2022 ms.topic: conceptual --- # Common NuGet configurations -NuGet's behavior is driven by the accumulated settings in one or more `NuGet.Config` (XML) files that can exist at project-, user-, and computer-wide levels. A global `NuGetDefaults.Config` file also specifically configures package sources. Settings apply to all commands issued in the CLI, the Package Manager Console, and the Package Manager UI. +NuGet's behavior is driven by the accumulated settings in one or more config (XML) files that can exist at solution- (project if no solution is used), user-, and computer-wide levels. ## Config file locations and uses -| Scope | NuGet.Config file location | Description | +| Scope | `NuGet.Config` file location | Description | | --- | --- | --- | -| Solution | Current folder (aka Solution folder) or any folder up to the drive root.| In a solution folder, settings apply to all projects in subfolders. Note that if a config file is placed in a project folder, it has no effect on that project. | -| User | Windows: `%appdata%\NuGet\NuGet.Config`
Mac/Linux: `~/.config/NuGet/NuGet.Config` or `~/.nuget/NuGet/NuGet.Config` (varies by OS distribution) | Settings apply to all operations, but are overridden by any project-level settings. | -| Computer | Windows: `%ProgramFiles(x86)%\NuGet\Config`
Mac/Linux: `$XDG_DATA_HOME`. If `$XDG_DATA_HOME` is null or empty, `~/.local/share` or `/usr/local/share` will be used (varies by OS distribution) | Settings apply to all operations on the computer, but are overridden by any user- or project-level settings. | +| Solution | Current folder (aka Solution folder) or any folder up to the drive root.| In a solution folder, settings apply to all projects in subfolders. Note that if a config file is placed in a project folder, it has no effect on that project. When restoring a project on the command line, the project's directory is treated as the solution directory, which can lead to differences in behaviour when restoring the project vs solution. | +| User | **Windows:** `%appdata%\NuGet\NuGet.Config`
**Mac/Linux:** `~/.config/NuGet/NuGet.Config` or `~/.nuget/NuGet/NuGet.Config` (varies by tooling)
Additional configs are supported on all platforms. These configs cannot be edited by the tooling.
**Windows:** `%appdata%\NuGet\config\*.Config`
**Mac/Linux:** `~/.config/NuGet/config/*.config` or `~/.nuget/config/*.config` | Settings apply to all operations, but are overridden by any solution-level settings. | +| Computer | **Windows:** `%ProgramFiles(x86)%\NuGet\Config`
**Mac/Linux:** `/etc/opt/NuGet/Config` (Linux) or `/Library/Application Support` (Mac) by default. If `$NUGET_COMMON_APPLICATION_DATA` is neither null nor empty, then `$NUGET_COMMON_APPLICATION_DATA/NuGet/Config` instead | Settings apply to all operations on the computer, but are overridden by any user- or solution-level settings. | + +> [!Note] +> On Mac/Linux, the user config file location varies by tooling. .NET CLI uses `~/.nuget/NuGet` folder, while Mono uses `~/.config/NuGet` folder. + +### On Mac/Linux, the user-level config file location varies by tooling +On Mac/Linux, the user config file location varies by tooling. +Majority of users use tools that look for the user config file under the `~/.nuget/NuGet` folder. +These other tools look for the user config file under the `~/.config/NuGet` folder: +* Mono +* NuGet.exe +* Visual Studio 2019 for Mac (and earlier versions) +* Visual Studio 2022 for Mac (and later versions), only when working on classic Mono projects. + +If the tooling you use involves both locations, consider consolidating them by following these steps to allow you to work with only one user-level config file: +1. Check the contents of the two user-level config files and keep the one you want under `~/.nuget/NuGet` folder. +2. Set symbolic link from `~/.nuget/NuGet` to `~/.config/NuGet`. E.g. Run bash command: `ln -s ~/.nuget/NuGet ~/.config/NuGet`. + Notes for earlier versions of NuGet: -- NuGet 3.3 and earlier used a `.nuget` folder for solution-wide settings. This file is not used in NuGet 3.4+. -- For NuGet 2.6 to 3.x, the computer-level config file on Windows was located in %ProgramData%\NuGet\Config[\\{IDE}[\\{Version}[\\{SKU}]]]\NuGet.Config, where *{IDE}* can be *VisualStudio*, *{Version}* was the Visual Studio version such as *14.0*, and *{SKU}* is either *Community*, *Pro*, or *Enterprise*. To migrate settings to NuGet 4.0+, simply copy the config file to %ProgramFiles(x86)%\NuGet\Config. On Linux, this previous location was /etc/opt, and on Mac, /Library/Application Support. +- NuGet 3.3 and earlier used a `.nuget` folder for solution-wide settings. This folder is not used in NuGet 3.4+. +- For NuGet 2.6 to 3.x, the computer-level config file on Windows was located in `%ProgramData%\NuGet\Config[\{IDE}[\{Version}[\{SKU}]]]\NuGet.Config`, where `{IDE}` can be `VisualStudio`, `{Version}` was the Visual Studio version such as `14.0`, and `{SKU}` is either `Community`, `Pro`, or `Enterprise`. To migrate settings to NuGet 4.0+, simply copy the config file to `%ProgramFiles(x86)%\NuGet\Config`. On Linux, this previous location was `/etc/opt`, and on Mac, `/Library/Application Support`. ## Changing config settings A `NuGet.Config` file is a simple XML text file containing key/value pairs as described in the [NuGet Configuration Settings](../reference/nuget-config-file.md) topic. Settings are managed using the NuGet CLI [config command](../reference/cli-reference/cli-ref-config.md): -- By default, changes are made to the user-level config file. +- By default, changes are made to the user-level config file. (On Mac/Linux, the location of user-level config file varies by tooling) - To change settings in a different file, use the `-configFile` switch. In this case files can use any filename. - Keys are always case sensitive. - Elevation is required to change settings in the computer-level settings file. @@ -41,29 +58,35 @@ Settings are managed using the NuGet CLI [config command](../reference/cli-refer Windows: ```cli -# Set repositoryPath in the user-level config file -nuget config -set repositoryPath=c:\packages +# Set globalPackagesFolder in the user-level config file +dotnet nuget config set globalPackagesFolder "C:\packages" -# Set repositoryPath in project-level files -nuget config -set repositoryPath=c:\packages -configfile c:\my.Config -nuget config -set repositoryPath=c:\packages -configfile .\myApp\NuGet.Config +# Set repositoryPath (available for packages.config only) in the user-level config file +dotnet nuget config set repositoryPath "C:\packages" + +# Set repositoryPath in solution-level files +dotnet nuget config set repositoryPath "C:\packages" --configfile "C:\my.config" +dotnet nuget config set repositoryPath "c:\packages" --configfile "..\..\my.config" # Set repositoryPath in the computer-level file (requires elevation) -nuget config -set repositoryPath=c:\packages -configfile %ProgramFiles(x86)%\NuGet\Config\NuGet.Config +dotnet nuget config set repositoryPath "c:\packages" --configfile "%appdata%\NuGet\NuGet.Config" ``` Mac/Linux: ```cli -# Set repositoryPath in the user-level config file -nuget config -set repositoryPath=/home/packages +# Set globalPackagesFolder in the user-level config file +dotnet nuget config set globalPackagesFolder /home/packages + +# Set repositoryPath (available for packages.config only) in the user-level config file +dotnet nuget config set repositoryPath /home/packages -# Set repositoryPath in project-level files -nuget config -set repositoryPath=/home/projects/packages -configfile /home/my.Config -nuget config -set repositoryPath=/home/packages -configfile home/myApp/NuGet.Config +# Set repositoryPath in solution-level files +dotnet nuget config set repositoryPath /home/projects/packages --configfile /home/my.Config +dotnet nuget config set repositoryPath /home/packages --configfile home/myApp/NuGet.Config # Set repositoryPath in the computer-level file (requires elevation) -nuget config -set repositoryPath=/home/packages -configfile $XDG_DATA_HOME/NuGet.Config +dotnet nuget config set repositoryPath /home/packages --configfile $XDG_DATA_HOME/NuGet.Config ``` > [!Note] @@ -83,7 +106,10 @@ nuget config -set repositoryPath= -configfile /home/my.Config ### Creating a new config file -Copy the template below into the new file and then use `nuget config -configFile ` to set values: +Using the .NET CLI, create a default nuget.config by running `dotnet new nugetconfig`. +For more information, see [dotnet CLI commands](../reference/dotnet-commands.md#package-consumption). + +Alternatively, manually copy the template below into the new file and then use `nuget config -configFile ` to set values: ```xml @@ -93,36 +119,42 @@ Copy the template below into the new file and then use `nuget config -configFile ## How settings are applied -Multiple `NuGet.Config` files allow you to store settings in different locations so that they apply to a single project, a group of projects, or all projects. These settings collectively apply to any NuGet operation invoked from the command line or from Visual Studio, with settings that exist "closest" to a project or the current folder taking precedence. +Multiple `NuGet.Config` files allow you to store settings in different locations so that they apply to a single solution, or a group of solutions. +These settings collectively apply to any NuGet operation invoked from the command line or from Visual Studio, with settings that exist "closest" to a solution or the current folder taking precedence. +If a command line tool is used on a project file, rather than a solution file, then the project directory is used as the "solution directory", which can lead to inconsistent behaviour when there is a `NuGet.Config` file in a subdirectory of the solution file. -Specifically, NuGet loads settings from the different config files in the following order: +Specifically, when a config file is not specified explicitly on the command line, NuGet loads settings from the different config files in the following order: -1. The [NuGetDefaults.Config file](#nuget-defaults-file), which contains settings related only to package sources. +1. (*Uncommon*) The [`NuGetDefaults.Config` file](#nuget-defaults-file), which contains settings related only to package sources. 1. The computer-level file. 1. The user-level file. -1. The file specified with `-configFile`. -1. Files found in every folder in the path from the drive root to the current folder (where nuget.exe is invoked or the folder containing the Visual Studio project). For example, if a command is invoked in c:\A\B\C, NuGet looks for and loads config files in c:\, then c:\A, then c:\A\B, and finally c:\A\B\C. +1. Files found in every folder in the path from the drive root to the current folder (where `nuget.exe` is invoked or the folder containing the Visual Studio solution). For example, if a command is invoked in `c:\A\B\C`, NuGet looks for and loads config files in `c:\`, then `c:\A`, then `c:\A\B`, and finally `c:\A\B\C`. -As NuGet finds settings in these files, they are applied as follows: +When a config file is explicitly specified on the command line, for example `nuget -configFile my.config` or `dotnet restore --configfile my.config`, only the settings from the specified file will be used. -1. For single-item elements, NuGet replaced any previously-found value for the same key. This means that settings that are "closest" to the current folder or project override any others found earlier. For example, the `defaultPushSource` setting in `NuGetDefaults.Config` is overridden if it exists in any other config file. +As NuGet finds settings in these files, they are applied as follows: +1. For single-item elements, NuGet replaced any previously-found value for the same key. This means that settings that are "closest" to the current folder or solution override any others found earlier. For example, the `defaultPushSource` setting in `NuGetDefaults.Config` is overridden if it exists in any other config file. 1. For collection elements (such as ``), NuGet combines the values from all configuration files into a single collection. - 1. When `` is present for a given node, NuGet ignores previously defined configuration values for that node. +> [!Tip] +> Add a `nuget.config` file in the root of your solution repository. This is considered a best practice as it promotes repeatability and ensures that different users have the same NuGet configuration. + ### Settings walkthrough Let's say you have the following folder structure on two separate drives: - disk_drive_1 - User - disk_drive_2 - Project1 - Source - Project2 - Source - tmp +``` +disk_drive_1 + User +disk_drive_2 + Project1 + Source + Project2 + Source + tmp +``` You then have four `NuGet.Config` files in the following locations with the given content. (The computer-level file is not included in this example, but would behave similarly to the user-level file.) @@ -131,13 +163,13 @@ File A. User-level file, (`%appdata%\NuGet\NuGet.Config` on Windows, `~/.config/ ```xml - - - + + + ``` -File B. disk_drive_2/NuGet.Config: +File B. `disk_drive_2/NuGet.Config`: ```xml @@ -151,7 +183,7 @@ File B. disk_drive_2/NuGet.Config: ``` -File C. disk_drive_2/Project1/NuGet.Config: +File C. `disk_drive_2/Project1/NuGet.Config`: ```xml @@ -167,7 +199,7 @@ File C. disk_drive_2/Project1/NuGet.Config: ``` -File D. disk_drive_2/Project2/NuGet.Config: +File D. `disk_drive_2/Project2/NuGet.Config`: ```xml @@ -181,39 +213,53 @@ File D. disk_drive_2/Project2/NuGet.Config: NuGet then loads and applies settings as follows, depending on where it's invoked: -- **Invoked from disk_drive_1/users**: Only the default repository listed in the user-level configuration file (A) is used, because that's the only file found on disk_drive_1. +- **Invoked from `disk_drive_1/users`**: Only the default repository listed in the user-level configuration file (A) is used, because that's the only file found on `disk_drive_1`. + +- **Invoked from `disk_drive_2/` or `disk_drive_/tmp`**: The user-level file (A) is loaded first, then NuGet goes to the root of `disk_drive_2` and finds file (B). NuGet also looks for a configuration file in `/tmp` but does not find one. As a result, the default repository on `nuget.org` is used, package restore is enabled, and packages get expanded in `disk_drive_2/tmp`. -- **Invoked from disk_drive_2/ or disk_drive_/tmp**: The user-level file (A) is loaded first, then NuGet goes to the root of disk_drive_2 and finds file (B). NuGet also looks for a configuration file in /tmp but does not find one. As a result, the default repository on nuget.org is used, package restore is enabled, and packages get expanded in disk_drive_2/tmp. +- **Invoked from `disk_drive_2/Project1` or `disk_drive_2/Project1/Source`**: The user-level file (A) is loaded first, then NuGet loads file (B) from the root of `disk_drive_2`, followed by file (C). Settings in (C) override those in (B) and (A), so the `repositoryPath` where packages get installed is `disk_drive_2/Project1/External/Packages` instead of `disk_drive_2/tmp`. Also, because (C) clears ``, nuget.org is no longer available as a source leaving only `https://MyPrivateRepo/ES/nuget`. -- **Invoked from disk_drive_2/Project1 or disk_drive_2/Project1/Source**: The user-level file (A) is loaded first, then NuGet loads file (B) from the root of disk_drive_2, followed by file (C). Settings in (C) override those in (B) and (A), so the `repositoryPath` where packages get installed is disk_drive_2/Project1/External/Packages instead of *disk_drive_2/tmp*. Also, because (C) clears ``, nuget.org is no longer available as a source leaving only `https://MyPrivateRepo/ES/nuget`. +- **Invoked from `disk_drive_2/Project2` or `disk_drive_2/Project2/Source`**: The user-level file (A) is loaded first followed by file (B) and file (D). Because `packageSources` is not cleared, both `nuget.org` and `https://MyPrivateRepo/DQ/nuget` are available as sources. Packages get expanded in `disk_drive_2/tmp` as specified in (B). -- **Invoked from disk_drive_2/Project2 or disk_drive_2/Project2/Source**: The user-level file (A) is loaded first followed by file (B) and file (D). Because `packageSources` is not cleared, both `nuget.org` and `https://MyPrivateRepo/DQ/nuget` are available as sources. Packages get expanded in disk_drive_2/tmp as specified in (B). +## Additional user wide configuration + +Starting with 5.7, NuGet has added support for additional user wide configuration files. This allows third-party vendors to add additional user configuration files without elevation. +These configuration files are found in the standard user wide configuration folder within a `config` subfolder. +All files ending with `.config` or `.Config` will be considered. +These files cannot be edited by the standard tooling. + +| OS Platform | Additional Configurations | +| --- | --- | +| Windows | `%appdata%\NuGet\config\*.Config` | +| Mac/Linux | `~/.config/NuGet/config/*.config` or `~/.nuget/config/*.config` | ## NuGet defaults file -The `NuGetDefaults.Config` file exists to specify package sources from which packages are installed and updated, and to control the default target for publishing packages with `nuget push`. Because administrators can conveniently (using Group Policy, for example) deploy consistent `NuGetDefaults.Config` files to developer and build machines, they can ensure that everyone in the organization is using the correct package sources rather than nuget.org. +The `NuGetDefaults.Config` is uncommon and can only specify package sources from which packages are installed and updated, or control the default target for publishing packages with `nuget push`. + +Because administrators can conveniently (using Group Policy, for example) deploy consistent `NuGetDefaults.Config` files to developer and build machines, they can ensure that everyone in the organization is using consistent package sources, whether or not that includes nuget.org. > [!Important] > The `NuGetDefaults.Config` file never causes a package source to be removed from a developer's NuGet configuration. That means if the developer has already used NuGet and therefore has the nuget.org package source registered, it won't be removed after the creation of a `NuGetDefaults.Config` file. > > Furthermore, neither `NuGetDefaults.Config` nor any other mechanism in NuGet can prevent access to package sources like nuget.org. If an organization wishes to block such access, it must use other means such as firewalls to do so. -### NuGetDefaults.Config location +### `NuGetDefaults.Config` location The following table describes where the `NuGetDefaults.Config` file should be stored, depending on the target OS: -| OS Platform | NuGetDefaults.Config Location | +| OS Platform | `NuGetDefaults.Config` Location | | --- | --- | -| Windows | **Visual Studio 2017 or NuGet 4.x+:** `%ProgramFiles(x86)%\NuGet\Config`
**Visual Studio 2015 and earlier or NuGet 3.x and earlier:** `%PROGRAMDATA%\NuGet` | +| Windows | **Visual Studio 2017 or NuGet 4.x+:** `%ProgramFiles(x86)%\NuGet`
**Visual Studio 2015 and earlier or NuGet 3.x and earlier:** `%PROGRAMDATA%\NuGet` | | Mac/Linux | `$XDG_DATA_HOME` (typically `~/.local/share` or `/usr/local/share`, depending on OS distribution)| ### NuGetDefaults.Config settings - `packageSources`: this collection has the same meaning as `packageSources` in regular config files and specifies the default sources. NuGet uses the sources in order when installing or updating packages in projects using the `packages.config` management format. For projects using the PackageReference format, NuGet uses local sources first, then sources on network shares, then HTTP sources, regardless of the order in the configuration files. NuGet always ignores the order of sources with restore operations. -- `disabledPackageSources`: this collection also has the same meaning as in `NuGet.Config` files, where each affected source is listed by its name and a true/false value indicating whether it's disabled. This allows the source name and URL to remain in `packageSources` without having it turned on by default. Individual developers can then re-enable the source by setting the source's value to false in other `NuGet.Config` files without having to find the correct URL again. This is also useful to supply developers with a full list of internal source URLs for an organization while enabling only an individual team's source by default. +- `disabledPackageSources`: this collection also has the same meaning as in `NuGet.Config` files, where each affected source is listed by its name and a `true`/`false` value indicating whether it's disabled. This allows the source name and URL to remain in `packageSources` without having it turned on by default. Individual developers can then re-enable the source by setting the source's value to `false` in other `NuGet.Config` files without having to find the correct URL again. This is also useful to supply developers with a full list of internal source URLs for an organization while enabling only an individual team's source by default. -- `defaultPushSource`: specifies the default target for `nuget push` operations, overriding the built-in default of nuget.org. Administrators can deploy this setting to avoid publishing internal packages to the public nuget.org by accident, as developers specifically need to use `nuget push -Source` to publish to nuget.org. +- `defaultPushSource`: specifies the default target for `nuget push` operations, overriding the built-in default of `nuget.org`. Administrators can deploy this setting to avoid publishing internal packages to the public `nuget.org` by accident, as developers specifically need to use `nuget push -Source` to publish to `nuget.org`. ### Example NuGetDefaults.Config and application diff --git a/docs/consume-packages/consuming-packages-authenticated-feeds.md b/docs/consume-packages/consuming-packages-authenticated-feeds.md new file mode 100644 index 000000000..cf030bb2d --- /dev/null +++ b/docs/consume-packages/consuming-packages-authenticated-feeds.md @@ -0,0 +1,149 @@ +--- +title: Consuming packages from authenticated feeds +description: Consuming packages from authenticated feeds in all NuGet client scenarios +author: nkolev92 +ms.author: nikolev +ms.date: 12/22/2023 +ms.topic: conceptual +ms.custom: sfi-ropc-nochange +--- + +# Consuming packages from authenticated feeds + +Many NuGet operations, such as restore and install, require communication with one or more package sources, which [can be configured in *nuget.config* files](../reference/nuget-config-file.md#packagesources). + +> [!NOTE] +> Use package sources that you trust. + +For HTTP feeds, NuGet will make an unauthenticated request, and if the server responds with an HTTP 401 response, NuGet will search for credentials in the following order: + +1. [An environment variable `NuGetPackageSourceCredentials_{name}`](#credentials-in-environment-variables). +1. [Credentials in *nuget.config* files](#credentials-in-nugetconfig-files). +1. [Use a NuGet credential provider, if your package source provides one](#credential-providers). + +The credentials you need to use are determined by the package source. +Therefore, unless you're using a credential provider, you should check with your package source for what credentials to use. +It is very common for package sources to forbid you from using your password (that you log into the website with) with NuGet. +Typically you need to create a Personal Access Token to use as NuGet's password, but you should check the documentation for the NuGet server you're using. +Some package sources, such as Azure DevOps and GitHub, have scoped access tokens, so you may need to ensure that any tokens you create include the required scope. + +## Security best practices for managing credentials + +Although NuGet searches for credentials in the order mentioned above, we recommend the following sequence for securely managing credentials when authenticating with private feeds: + +1. **Credential Provider**: It is highly recommended to use a credential provider whenever possible. +This approach avoids storing secrets in plain text and minimizes the risk of accidentally exposing secrets through source control. +Moreover, it generally reduces the number of places you need to update when a credential expires or changes. +If the credential provider supports single sign-on, it may decrease the frequency of logins or the number of places where credentials need to be saved. +Refer to the [credential providers](#credential-providers) section for more information. + +1. **Encrypted Credentials in nuget.config**: If a credential provider is not available, you should consider using encrypted credentials. +This approach provides an extra layer of security by storing the credentials in an encrypted format. +For more information, refer to the section on [credentials in *nuget.config* files](#credentials-in-nugetconfig-files). + + > [!NOTE] + > Be aware that encrypted passwords are only supported on Windows. + > Moreover, they can only be decrypted on the same machine and by the same user who originally encrypted them. + +1. **Using Environment Variable Macros in nuget.config**: If using encrypted credentials is not possible, consider storing the credentials in the *nuget.config* file with environment variable macros. +This approach allows you to reference environment variables that contain the actual credentials. +It enhances transparency and helps end users understand how their credentials are configured. +For more information, refer to the section on [credentials in *nuget.config* files](#credentials-in-nugetconfig-files). + +1. **Using Environment Variables Directly**: As a fallback option, you can store the credentials directly in environment variables. +However, be aware that this approach may offer less visibility and control compared to using environment variable macros in the *nuget.config* file. +For more information, refer to the section on [credentials in environment variables](#credentials-in-environment-variables). + +1. **Clear Text Credentials in NuGet.Config**: It is highly recommended to use one of the previously mentioned options. +If these options are not feasible, you can store the credentials in the *nuget.config* file. +However, this option should only be used in environments where no other secure option is available. +For more information, refer to the section on [credentials in *nuget.config* files](#credentials-in-nugetconfig-files). + + > [!WARNING] + > Storing credentials in clear text in the *nuget.config* file, especially when saving the file in source control, is risky as it increases the chances of accidental credential leaks. + > If you must store credentials in the *nuget.config* file, consider using one of the more secure options mentioned above. + +By adhering to these best practices, you can securely authenticate private feeds while minimizing the risk of sensitive information exposure. + +## Credentials in environment variables + +NuGet will search for an environment variable named `NuGetPackageSourceCredentials_{name}`, where `{name}` is the value of `key="name"` in your *nuget.config* file's package source. +The value of the environment variable must be `Username={username};Password={password}`, and may optionally include `;ValidAuthenticationTypes={types}`. +If the environment variable doesn't match NuGet's convention, or the value doesn't meet NuGet's expected pattern, NuGet will silently ignore the environment variable, and continue searching for credentials for the package source elsewhere. +There are no logs to signal that NuGet uses the credential from the environment variable, which can cause difficulties in debugging authentication problems if the environment variable contains an expired secret, and the new secret is added to a *nuget.config* file, since the config file has lower precedence. + +> [!TIP] +> Using environment variables in CI/CD pipelines is an excellent choice to minimize the risk of secrets being captured in logs. + +For example, consider the following *nuget.config* file: + +```xml + + + + + + +``` + +In this case, the source name is `Contoso` and NuGet will look for the environment variable name `NuGetPackageSourceCredentials_Contoso`. +Some platforms are case-sensitive, so take care about using the correct upper and lower case characters for the environment name and the source name, as defined in your *nuget.config* file. + +If the username is `nugetUser` and the password is `secret123`, the environment variable's value should be set to `Username=nugetUser;Password=secret123`. +If NuGet should only use this credential for HTTP Basic authentication, but not other authentication schemes, you can set the environment variable's value to `Username=nugetUser;Password=secret123;ValidAuthenticationTypes=Basic`. +For more information about valid authentication types, see [the docs on package credentials in *nuget.config* files](../reference/nuget-config-file.md#packagesourcecredentials). + +> [!NOTE] +> Environment variables have restrictions on allowed characters, and different operating systems may have different restrictions. +> For example, spaces are not allowed. +> Therefore, you use this environment variable feature to specify NuGet credentials for package sources that use any characters that are invalid for your platform's environment variables. +> In such cases, you should rename the package source in your *nuget.config* file. + +## Credentials in *nuget.config* files + +*nuget.config* files can contain package source credentials. +See [the *nuget.config* file reference doc section on package source credentials](../reference/nuget-config-file.md#packagesourcecredentials) for more information, including syntax. +However, it's easier to use [`dotnet nuget update source`](/dotnet/core/tools/dotnet-nuget-update-source) on the command line to set the credentials. + +> [!WARNING] +> Take care when setting credentials in *nuget.config* files, especially when saving the credential as plain text. +> If the credential is written to a *nuget.config* file that is in source control, there is an increased risk of accidentally leaking the secret. +> +> As [NuGet accumulates settings from multiple files](../consume-packages/configuring-nuget-behavior.md), it is recommended to save credentials to your user *nuget.config* file. +> We also recommend to save package sources in the solution (source code repository) *nuget.config* file, including a `` element, for build reliability. + +The username and plain text password in a *nuget.config* file can use an environment variable by adding `%` to the beginning and end of the environment variable name you would like to use. +For more information, see [the *nuget.config* reference docs on using environment variables](../reference/nuget-config-file.md#using-environment-variables). + +## Credential providers + +NuGet has an extensibility model, allowing [plugins to provide NuGet credentials](../reference/extensibility/NuGet-Cross-Platform-Authentication-Plugin.md). +The [path that credential providers must be installed](../reference/extensibility/NuGet-Cross-Platform-Plugins.md#plugin-installation-and-discovery), for NuGet to discover, is different for .NET Framework (NuGet.exe, MSBuild, and Visual Studio), and the .NET SDK (running on the .NET 5+ runtime). + +NuGet has a concept of being run in interactive mode or non-interactive mode. +When in non-interactive mode, credential providers are asked not to block NuGet. +While in interactive mode, the credential provider may prompt you to log in. +Different tools have different defaults, so interactive mode may need to be opt-in or opt-out, depending on your scenario. + +|Tool|Default|Toggle| +|--|--|--| +|`dotnet` CLI|non-interactive|`--interactive` argument. For example, `dotnet restore --interactive`.| +|MSBuild|non-interactive|`NuGetInteractive` MSBuild property. For example, `msbuild -t:restore -p:NuGetInteractive=true`.| +|NuGet.exe|interactive|`-NonInteractive` argument. For example, `nuget.exe restore -NonInteractive`.| +|Visual Studio|interactive|not possible to run in non-interactive mode.| + +[NuGet.exe supports both V1 and V2 credential providers](../reference/extensibility/nuget-exe-Credential-Providers.md), while MSBuild and the .NET SDK only support the cross platform (V2) plugins. + +In Visual Studio, NuGet has a [Visual Studio Credential Provider interface](../reference/extensibility/NuGet-Credential-Providers-for-Visual-Studio.md), which credential providers can use to provide a graphical login experience, or call Visual Studio APIs if necessary. +NuGet in Visual Studio will fall back to the command line credential providers if it can't find a Visual Studio credential provider that handles the source. + +Visual Studio 2017 version 15.9, and above, includes a credential provider for [Azure Artifacts](/azure/devops/artifacts/), that works within Visual Studio, MSBuild, and NuGet.exe. +However, the credential provider for the .NET SDK is not included by Visual Studio, so [must be installed separately](https://github.com/microsoft/artifacts-credprovider?tab=readme-ov-file#setup) to work with the `dotnet` CLI. + +### List of credential providers + +Here is a list of credential providers we are aware of: + +* [AWS CodeArtifact NuGet Credential Provider](https://docs.aws.amazon.com/codeartifact/latest/ug/nuget-cli.html#nuget-configure-cli) +* [Azure Artifacts Credential Provider](https://github.com/microsoft/artifacts-credprovider). This link is just for the command line credential provider. +* [MyGet Credential Provider for Visual Studio](http://docs.myget.org/docs/reference/credential-provider-for-visual-studio). diff --git a/docs/consume-packages/includes/restore-dotnet-cli.md b/docs/consume-packages/includes/restore-dotnet-cli.md new file mode 100644 index 000000000..6d3b8bd98 --- /dev/null +++ b/docs/consume-packages/includes/restore-dotnet-cli.md @@ -0,0 +1,9 @@ +The [dotnet restore](/dotnet/core/tools/dotnet-restore) command restores packages that the project file lists with ``. For more information, see [PackageReference in project files](../../consume-packages/package-references-in-project-files.md). + +.NET Core 2.0 and later `dotnet build` and `dotnet run` commands restore packages automatically. As of NuGet 4.0, `dotnet restore` runs the same code as `nuget restore`. + +To restore a package with `dotnet restore`: + +1. Open a command line and switch to the directory that contains your project file. +1. Run `dotnet restore`. + diff --git a/docs/consume-packages/includes/restore-nuget-exe-cli.md b/docs/consume-packages/includes/restore-nuget-exe-cli.md new file mode 100644 index 000000000..e3fd938b2 --- /dev/null +++ b/docs/consume-packages/includes/restore-nuget-exe-cli.md @@ -0,0 +1,21 @@ +The NuGet CLI [restore](../../reference/cli-reference/cli-ref-restore.md) command downloads and installs any missing packages. The command works on projects that use either [PackageReference](/nuget/consume-packages/package-references-in-project-files) or [packages.config](/nuget/reference/packages-config) for package references. + +Like `install`, the `restore` command only adds packages to disk, but doesn't modify the project file or *packages.config*. To add project dependencies, use the Visual Studio Package Manager UI or Console. + +To restore packages, run the following command: + +```cli +nuget restore +``` + +The `restore` command uses a solution file or a *package.config* file in the specified project path. + +For example, to restore all packages for *MySolution.sln* in the current directory, run: + +```cli +nuget restore MySolution.sln +``` + +> [!NOTE] +> For non-SDK-style projects that use `PackageReference`, use [msbuild -t:restore](../package-restore.md#restore-using-msbuild) to restore packages instead. + diff --git a/docs/consume-packages/install-use-packages-dotnet-cli.md b/docs/consume-packages/install-use-packages-dotnet-cli.md index 8e05c3a2b..39144ba75 100644 --- a/docs/consume-packages/install-use-packages-dotnet-cli.md +++ b/docs/consume-packages/install-use-packages-dotnet-cli.md @@ -1,100 +1,96 @@ --- -title: Install and manage NuGet packages using the dotnet CLI -description: Instructions for using the dotnet CLI to work with NuGet packages. +title: Install and manage NuGet packages with the dotnet CLI +description: See how to use the dotnet CLI to install, list, remove, and update NuGet packages. author: mikejo5000 ms.author: mikejo -ms.date: 06/03/2019 +ms.date: 03/03/2025 ms.topic: conceptual --- -# Install and manage packages using the dotnet CLI +# Install and manage NuGet packages with the dotnet CLI -The CLI tool allows you to easily install, uninstall, and update NuGet packages in projects and solutions. It runs on Windows, Mac OS X, and Linux. +You can use the dotnet CLI tool on Windows, macOS, or Linux to easily install, uninstall, and update NuGet packages in .NET projects and solutions. This article describes the most common dotnet CLI commands for managing NuGet packages. -The dotnet CLI is for use in your .NET Core and .NET Standard project (SDK-style project types), and for any other SDK-style projects (for example, an SDK-style project that targets .NET Framework). For more information, see [SDK attribute](/dotnet/core/tools/csproj#additions). +The dotnet CLI runs on .NET, .NET Core, .NET Standard SDK-style projects, and any other SDK-style projects, for example those that target .NET Framework. For more information, see [.NET project SDKs](/dotnet/core/project-sdk/overview). -This article shows you basic usage for a few of the most common dotnet CLI commands. For most of these commands, the CLI tool looks for a project file in the current directory, unless a project file is specified in the command (the project file is an optional switch). For a complete list of commands and the arguments you may use, see the [.NET Core command-line interface (CLI) tools](../reference/dotnet-commands.md). +For most commands, the CLI tool looks for a project file in the current directory, unless a different project file is specified as an optional switch in the command. For a complete list of commands and their arguments, see [dotnet CLI commands](../reference/dotnet-commands.md). ## Prerequisites -- The [.NET Core SDK](https://www.microsoft.com/net/download/), which provides the `dotnet` command-line tool. Starting in Visual Studio 2017, the dotnet CLI is automatically installed with any .NET Core related workloads. +- The [.NET Core SDK](https://www.microsoft.com/net/download/), which provides the `dotnet` command-line tool. Starting in Visual Studio 2017, the dotnet CLI automatically installs with all .NET and .NET Core related workloads. -## Install a package +## Install or update a package -[dotnet add package](/dotnet/core/tools/dotnet-add-package?tabs=netcore2x) adds a package reference to the project file, then runs `dotnet restore` to install the package. +The [dotnet add package](/dotnet/core/tools/dotnet-add-package) command adds a package reference to the project file, and then runs `dotnet restore` to install the package. 1. Open a command line and switch to the directory that contains your project file. -2. Use the following command to install a Nuget package: +1. Use the following command to install a NuGet package: - ```cli + ```dotnetcli dotnet add package ``` For example, to install the `Newtonsoft.Json` package, use the following command - ```cli + ```dotnetcli dotnet add package Newtonsoft.Json ``` -3. After the command completes, look at the project file to make sure the package was installed. +1. After the command completes, you can open the project file to see the package reference. - You can open the `.csproj` file to see the added reference: + For example, open the *.csproj* file to see the added `Newtonsoft.Json` package reference: ```xml - - - + + + ``` ## Install a specific version of a package -If the version is not specified, NuGet installs the latest version of the package. You can also use the [dotnet add package](/dotnet/core/tools/dotnet-add-package?tabs=netcore2x) command to install a specific version of a Nuget package: +The `dotnet add package` command installs the latest version of the package unless you specify a different version. -```cli +To install a specific version of a NuGet package, use the optional `-v` or `--version` switch: + +```dotnetcli dotnet add package -v ``` For example, to add version 12.0.1 of the `Newtonsoft.Json` package, use this command: -```cli -dotnet add package Newtonsoft.Json -v 12.0.1 +```dotnetcli +dotnet add package Newtonsoft.Json --version 12.0.1 ``` ## List package references -You can list the package references for your project using the [dotnet list package](/dotnet/core/tools/dotnet-list-package?tabs=netcore2x) command. +List the package references and versions for your project by using the [dotnet list package](/dotnet/core/tools/dotnet-list-package) command: -```cli +```dotnetcli dotnet list package ``` ## Remove a package -Use the [dotnet remove package](/dotnet/core/tools/dotnet-remove-package?tabs=netcore2x) command to remove a package reference from the project file. +Use the [dotnet remove package](/dotnet/core/tools/dotnet-remove-package) command to remove a package reference from the project file. -```cli +```dotnetcli dotnet remove package ``` -For example, to remove the `Newtonsoft.Json` package, use the following command +For example, to remove the `Newtonsoft.Json` package, use the following command: -```cli +```dotnetcli dotnet remove package Newtonsoft.Json ``` -## Update a package - -NuGet installs the latest version of the package when you use the `dotnet add package` command unless you specify the package version (`-v` switch). - ## Restore packages -Use the [dotnet restore](/dotnet/core/tools/dotnet-restore?tabs=netcore2x) command, which restores packages listed in the project file (see [PackageReference](../consume-packages/package-references-in-project-files.md)). With .NET Core 2.0 and later, restore is done automatically with `dotnet build` and `dotnet run`. As of NuGet 4.0, this runs the same code as `nuget restore`. +[!INCLUDE [restore-dotnet-cli](includes/restore-dotnet-cli.md)] -As with the other `dotnet` CLI commands, first open a command line and switch to the directory that contains your project file. +## Next steps -To restore a package using `dotnet restore`: - -```cli -dotnet restore -``` +- [.NET CLI overview](/dotnet/core/tools) +- [Install and manage packages in Visual Studio using the NuGet Package Manager](install-use-packages-visual-studio.md) +- [Install and manage packages with the Package Manager Console](install-use-packages-powershell.md) diff --git a/docs/consume-packages/install-use-packages-nuget-cli.md b/docs/consume-packages/install-use-packages-nuget-cli.md index 2a18b1f77..fe0a5e8f4 100644 --- a/docs/consume-packages/install-use-packages-nuget-cli.md +++ b/docs/consume-packages/install-use-packages-nuget-cli.md @@ -1,118 +1,123 @@ --- -title: Manage NuGet packages using the nuget.exe CLI -description: Instructions for using the nuget.exe CLI to work with NuGet packages. +title: Manage NuGet packages with the NuGet CLI +description: Instructions for using the NuGet CLI, nuget.exe, to manage NuGet packages. author: mikejo5000 ms.author: mikejo -ms.date: 06/03/2019 +ms.date: 03/03/2025 ms.topic: conceptual --- -# Manage packages using the nuget.exe CLI +# Manage NuGet packages with the NuGet CLI -The CLI tool allows you to easily update and restore NuGet packages in projects and solutions. This tool provides all NuGet capabilities on Windows, and also provides most features on Mac and Linux when running under Mono. +You can use the `nuget.exe` CLI tool to manage NuGet packages in Visual Studio projects and solutions. This article describes the most common NuGet CLI commands for managing NuGet packages. All these commands work on Windows, and most work on Mac and on Linux with Mono. -The `nuget.exe` CLI is for your .NET Framework project and non-SDK-style projects (for example, a non-SDK style project that targets .NET Standard libraries). If you are using a non-SDK-style project that has been migrated to `PackageReference`, use the `dotnet` CLI instead. The `nuget.exe` CLI requires a [packages.config](../reference/packages-config.md) file for package references. +The NuGet CLI runs on .NET Framework and non-SDK-style projects, for example non-SDK style projects that target .NET Standard libraries. The NuGet CLI commands can use a project [packages.config](../reference/packages-config.md) file that lists package references. For non-SDK-style projects that use `PackageReference` instead of *packages.config* for package references, use the [dotnet CLI](install-use-packages-dotnet-cli.md) instead. > [!NOTE] -> In most scenarios, we recommend [migrating non-SDK-style projects](../reference/migrate-packages-config-to-package-reference.md) that use `packages.config` to PackageReference, and then you can use the `dotnet` CLI instead of the `nuget.exe` CLI. Migration is not currently available for C++ and ASP.NET projects. +> For most non-SDK-style projects that use *packages.config*, it's best to [migrate packages.config to PackageReference](migrate-packages-config-to-package-reference.md), and then use the dotnet CLI instead of the NuGet CLI to manage packages. However, you can't migrate C++ or ASP.NET projects. -This article shows you basic usage for a few of the most common `nuget.exe` CLI commands. For most of these commands, the CLI tool looks for a project file in the current directory, unless a project file is specified in the command. For a complete list of commands and the arguments you may use, see the [nuget.exe CLI reference](../reference/nuget-exe-cli-reference.md). +For most commands, the NuGet CLI tool uses the current directory, unless you specify a different location in the command. To run NuGet CLI commands, open a command line and switch to the directory that contains your project file. + +For a complete list of commands and their arguments, see the [NuGet CLI reference](../reference/nuget-exe-cli-reference.md). ## Prerequisites -- Install the `nuget.exe` CLI by downloading it from [nuget.org](https://dist.nuget.org/win-x86-commandline/latest/nuget.exe), saving that `.exe` file to a suitable folder, and adding that folder to your PATH environment variable. +Download the NuGet CLI from [nuget.org](https://dist.nuget.org/win-x86-commandline/latest/nuget.exe). Save the *nuget.exe* file to a suitable directory, and make sure the directory is in your PATH environment variable. + +> [!NOTE] +> You can also use the [winget](/windows/package-manager/winget) tool for Windows or [Homebrew](https://brew.sh/) for macOS. + +To find out your NuGet CLI version, open a command line and run `nuget help`, or to avoid having to scroll up, use `nuget help | more`. The first line in the help output shows the version. ## Install a package -The [install](../reference/cli-reference/cli-ref-install.md) command downloads and installs a package into a project, defaulting to the current folder, using specified package sources. Install new packages into the *packages* folder in your project root directory. +The NuGet CLI [install](../reference/cli-reference/cli-ref-install.md) command downloads and installs specified NuGet packages. > [!IMPORTANT] -> The `install`command does not modify a project file or *packages.config*; in this way it's similar to `restore` in that it only adds packages to disk but does not change a project's dependencies. To add a dependency, either add a package through the Package Manager UI or Console in Visual Studio, or modify *packages.config* and then run either `install` or `restore`. +> The `install` command doesn't modify the project file or *packages.config* file. The `install` and `restore` commands only add packages to disk, but don't add dependencies to projects. To add project dependencies, add packages through the [Visual Studio Package Manager UI](install-use-packages-visual-studio.md) or [Package Manager Console](install-use-packages-powershell.md), then run `install` or `restore`. -1. Open a command line and switch to the directory that contains your project file. +Use the `-OutputDirectory` option to install packages to a specific directory. If you don't specify an output directory, `install` uses the current directory. -2. Use the following command to install a NuGet package to the *packages* folder. +```cli +nuget install -OutputDirectory +``` - ```cli - nuget install -OutputDirectory packages - ``` +For example, to install the `Newtonsoft.json` package to the *packages* subdirectory, use the following command: - To install the `Newtonsoft.json` package to the *packages* folder, use the following command: +```cli +nuget install Newtonsoft.Json -OutputDirectory packages +``` + +Instead of specifying a package to install, you can specify an existing *packages.config* file in the current or another directory. The `install` command installs all the packages listed in the *packages.config* file. - ```cli - nuget install Newtonsoft.Json -OutputDirectory packages - ``` +```cli +nuget install packages.config +``` -Alternatively, you can use the following command to install a NuGet package using an existing `packages.config` file to the *packages* folder. This does not add the package to your project dependencies, but installs it locally. +For example, the following command installs all the packages listed in *packages.config* in the *config* subdirectory to the *packages* subdirectory: ```cli -nuget install packages.config -OutputDirectory packages +nuget install config\packages.config -OutputDirectory packages + ``` ## Install a specific version of a package -If the version is not specified when you use the [install](../reference/cli-reference/cli-ref-install.md) command, NuGet installs the latest version of the package. You can also install a specific version of a Nuget package: +The `install` command installs the latest version of a package unless you specify a different version. To install a specific version of a package, use the `-Version` option: ```cli nuget install -Version ``` -For example, to add version 12.0.1 of the `Newtonsoft.json` package, use this command: +For example, to install version 12.0.1 of the `Newtonsoft.json` package, use: ```cli nuget install Newtonsoft.Json -Version 12.0.1 ``` -For more information on the limitations and behavior of `install`, see [Install a package](#install-a-package). - -## Remove a package - -To delete one or more packages, delete the packages you want to remove from the *packages* folder. - -If you want to reinstall packages, use the `restore` or `install` command. - ## List packages -You can display a list of packages from a given source using the [list](../reference/cli-reference/cli-ref-list.md) command. Use the `-Source` option to restrict the search. +Use the [list](../reference/cli-reference/cli-ref-list.md) command to display a list of packages installed in the packages folders. Use the `-Source` option to restrict the list. ```cli nuget list -Source ``` -For example, list packages in the *packages* folder. +For example, to list packages in the *packages* subdirectory of *MyProject*, use: ```cli -nuget list -Source C:\Users\username\source\repos\MyProject\packages +nuget list -Source C:\Users\%USERNAME%\source\repos\MyProject\packages ``` -If you use a search term, the search includes names of packages, tags, and package descriptions. +You can also use a search term to search for package names, tags, or descriptions: ```cli -nuget list +nuget list <"search term"> -Source ``` -## Update an individual package - -NuGet installs the latest version of the package when you use the `install` command unless you specify the package version. - ## Update all packages -Use the [update](../reference/cli-reference/cli-ref-update.md) command to update all packages. Updates all packages in a project (using `packages.config`) to their latest available versions. It is recommended to run `restore` before running `update`. +Use the [update](../reference/cli-reference/cli-ref-update.md) command to update all packages in a project *packages.config* file to their latest available versions. It's best to run `restore` before you run `update`. ```cli nuget update ``` -## Restore packages +## Remove a package + +To remove a package, delete that package from the project folder. To reinstall packages, use the `restore` or `install` commands. -Use the [restore](../reference/cli-reference/cli-ref-restore.md) command, which downloads and installs any packages missing from the *packages* folder. +Deleting packages from disk doesn't update the project, *packages.config*, or *NuGet.Config* files. The best way to remove packages is through the Visual Studio [Package Manager UI](install-use-packages-visual-studio.md) or [Package Manager Console](install-use-packages-powershell.md). -`restore` only adds packages to disk but does not change a project's dependencies. To restore project dependencies, modify `packages.config`, then use the `restore` command. +## Restore packages -As with the other `nuget.exe` CLI commands, first open a command line and switch to the directory that contains your project file. +[!INCLUDE [restore-nuget-exe-cli](includes/restore-nuget-exe-cli.md)] -To restore a package using `restore`: +For more information, see [Restore packages](package-restore.md). -```cli -nuget restore MySolution.sln -``` \ No newline at end of file +## Next steps + +- [NuGet CLI reference](../reference/nuget-exe-cli-reference.md) +- [Install and manage packages in Visual Studio using the NuGet Package Manager](install-use-packages-visual-studio.md) +- [Migrate from packages.config to PackageReference](migrate-packages-config-to-package-reference.md) +- [Manage packages with the dotnet CLI](install-use-packages-dotnet-cli.md) diff --git a/docs/consume-packages/install-use-packages-powershell.md b/docs/consume-packages/install-use-packages-powershell.md index 8637f7e9d..d2a177423 100644 --- a/docs/consume-packages/install-use-packages-powershell.md +++ b/docs/consume-packages/install-use-packages-powershell.md @@ -1,175 +1,205 @@ --- -title: Install and manage NuGet packages using the console in Visual Studio -description: Instructions for using the NuGet Package Manager Console in Visual Studio for working with packages. -author: karann-msft -ms.author: karann -ms.date: 07/08/2019 +title: Manage NuGet packages with the Visual Studio Package Manager Console +description: See how to work with NuGet packages by using PowerShell commands in the Visual Studio Package Manager Console. +author: JonDouglas +ms.author: jodou +ms.date: 03/03/2025 ms.topic: conceptual f1_keywords: - "vs.nuget.packagemanager.console" --- -# Install and manage packages with the Package Manager Console in Visual Studio (PowerShell) +# Manage packages with the Visual Studio Package Manager Console (PowerShell) -The NuGet Package Manager Console lets you use [NuGet PowerShell commands](../reference/powershell-reference.md) to find, install, uninstall, and update NuGet packages. Using the console is necessary in cases where the Package Manager UI does not provide a way to perform an operation. To use `nuget.exe` CLI commands in the console, see [Using the nuget.exe CLI in the console](#use-the-nugetexe-cli-in-the-console). +The Package Manager Console in Visual Studio uses PowerShell commands to interact with NuGet packages. You can use the console when there's no way to do an operation through the [Package Manager UI](install-use-packages-visual-studio.md). You can also use [dotnet CLI](../reference/dotnet-commands.md) or [NuGet CLI](#use-the-nugetexe-cli-in-the-console) commands in the console. -The console is built into Visual Studio on Windows. It is not included with Visual Studio for Mac or Visual Studio Code. +This article describes how to find, install, update, and uninstall NuGet packages with PowerShell commands in the Package Manager Console. For the complete Package Manager Console PowerShell command reference, see [PowerShell reference](../reference/powershell-reference.md). -## Find and install a package +> [!IMPORTANT] +> The PowerShell commands and arguments in this article are specific to the Visual Studio Package Manager Console. These commands differ from the [PackageManagement module commands](/powershell/module/packagemanagement) you can use in a general PowerShell environment. Each environment has commands that aren't available in the other, and commands with the same name might differ in their specific arguments. -For example, finding and installing a package is done with three easy steps: +## Console availability -1. Open the project/solution in Visual Studio, and open the console using the **Tools > NuGet Package Manager > Package Manager Console** command. +Starting in Visual Studio 2017, NuGet and the NuGet Package Manager install automatically when you create any .NET-related workloads in Visual Studio. You can also install the Package Manager by selecting **Individual components** > **Code tools** > **NuGet package manager** in the Visual Studio Installer. -1. Find the package you want to install. If you already know this, skip to step 3. +You can also search for the NuGet Package Manager extension under the **Tools** > **Extensions and Updates** or **Extensions** menus. If you're unable to use the extensions installer in Visual Studio, you can download the extension directly from [https://dist.nuget.org/index.html](https://dist.nuget.org/index.html). - ```ps - # Find packages containing the keyword "elmah" +The Package Manager Console is built into the Package Manager for Visual Studio on Windows. Visual Studio Code and Visual Studio for Mac don't include the console. Visual Studio for Mac has a UI for managing NuGet packages, and the equivalent console commands are available through the [NuGet CLI](../reference/nuget-exe-CLI-reference.md). For more information, see [Install and manage NuGet packages in Visual Studio for Mac](/visualstudio/mac/nuget-walkthrough). + +## Quickly find and install a package + +To use the Package Manager Console to quickly find and install a package: + +1. Open your project or solution in Visual Studio, and select **Tools** > **NuGet Package Manager** > **Package Manager Console** to open the Package Manager Console window. + +1. In the console, enter `Find-Package` with a keyword to find the package you want to install. For example, to find packages that contain the keyword `elmah`, run the following command. If you already know the package name you want, skip this step. + + ```powershell Find-Package elmah ``` -1. Run the install command: +1. Once you find the name, use the `Install-Package` command to install the package. For example, to install the `Elmah.MVC` package, enter: - ```ps - # Install the Elmah package to the project named MyProject. - Install-Package Elmah -ProjectName MyProject + ```powershell + Install-Package Elmah.MVC ``` -> [!Important] -> All operations that are available in the console can also be done with the [NuGet CLI](../reference/nuget-exe-cli-reference.md). However, console commands operate within the context of Visual Studio and a saved project/solution and often accomplish more than their equivalent CLI commands. For example, installing a package through the console adds a reference to the project whereas the CLI command does not. For this reason, developers working in Visual Studio typically prefer using the console to the CLI. +For more details about these commands, see the [Find a package](#find-a-package) and [Install a package](#install-a-package) sections. > [!Tip] -> Many console operations depend on having a solution opened in Visual Studio with a known path name. If you have an unsaved solution, or no solution, you can see the error, "Solution is not opened or not saved. Please ensure you have an open and saved solution." This indicates that the console cannot determine the solution folder. Saving an unsaved solution, or creating and saving a solution if you don't have one open, should correct the error. +> Many console operations depend on having a solution with a known path name open in Visual Studio. If you have an unsaved solution, or no solution, you see the error **Solution is not opened or not saved. Please ensure you have an open and saved solution.** To correct the error, create and save a solution, or save an unsaved solution. -## Opening the console and console controls +## Console controls -1. Open the console in Visual Studio using the **Tools > NuGet Package Manager > Package Manager Console** command. The console is a Visual Studio window that can be arranged and positioned however you like (see [Customize window layouts in Visual Studio](/visualstudio/ide/customizing-window-layouts-in-visual-studio)). +To open the Package Manager Console in Visual Studio, select **Tools** > **NuGet Package Manager** > **Package Manager Console** from the top menu. The console is a Visual Studio window that you can arrange and position as you like. For more information, see [Customize window layouts in Visual Studio](/visualstudio/ide/customizing-window-layouts-in-visual-studio). -1. By default, console commands operate against a specific package source and project as set in the control at the top of the window: +By default, console commands operate against the specific package source and project shown in the controls at the top of the window: - ![Package Manager Console controls for package source and project](media/PackageManagerConsoleControls1.png) +:::image type="content" source="media/PackageManagerConsoleControls1.png" alt-text="Screenshot that shows the Package Manager Console controls for package source and project."::: -1. Selecting a different package source and/or project changes those defaults for subsequent commands. To overrride these settings without changing the defaults, most commands support `-Source` and `-ProjectName` options. +Selecting a different package source or project changes the defaults for subsequent commands. To override these settings for single commands without changing the defaults, most console commands support `-Source` and `-ProjectName` options. -1. To manage package sources, select the gear icon. This is a shortcut to the **Tools > Options > NuGet Package Manager > Package Sources** dialog box as described on the [Package Manager UI](install-use-packages-visual-studio.md#package-sources) page. Also, the control to the right of the project selector clears the console's contents: +To manage package sources, select the gear icon, which opens the **Tools** > **Options** > **NuGet Package Manager** > **Package Sources** dialog box. The control next to the project selector clears the console's contents. - ![Package Manager Console settings and clear controls](media/PackageManagerConsoleControls2.png) +:::image type="content" source="media/PackageManagerConsoleControls2.png" alt-text="Screenshot that shows the Package Manager Console settings and clear controls."::: -1. The rightmost button interrupts a long-running command. For example, running `Get-Package -ListAvailable -PageSize 500` lists the top 500 packages on the default source (such as nuget.org), which could take several minutes to run. +The button on the far right interrupts a long-running command. For example, running `Get-Package -ListAvailable -PageSize 500` lists the top 500 available packages on the default source, such as nuget.org, which could take several minutes. - ![Package Manager Console stop control](media/PackageManagerConsoleControls3.png) +:::image type="content" source="media/PackageManagerConsoleControls3.png" alt-text="Screenshot that shows the Package Manager Console stop control."::: -## Install a package +## Find a package -```ps -# Add the Elmah package to the default project as specified in the console's project selector -Install-Package Elmah +To find a package in the default source, use [Find-Package](../reference/ps-reference/ps-ref-find-package.md). -# Add the Elmah package to a project named UtilitiesLib that is not the default -Install-Package Elmah -ProjectName UtilitiesLib -``` +- To find and list packages that contain certain keywords: -See [Install-Package](../reference/ps-reference/ps-ref-install-package.md). + ```powershell + Find-Package + Find-Package + ``` -Installing a package in the console performs the same steps as described on [What happens when a package is installed](../concepts/package-installation-process.md), with the following additions: +- To find and list packages whose name begins with a string: -- The Console displays applicable license terms in its window with implied agreement. If you do not agree to the terms, you should uninstall the package immediately. -- Also a reference to the package is added to the project file and appears in **Solution Explorer** under the **References** node, you need to save the project to see the changes in the project file directly. + ```powershell + Find-Package -StartWith + ``` -## Uninstall a package +- By default, `Find-Package` returns a list of 20 packages. Use `-First` to show more packages. For example, to show the first 100 packages, use: -```ps -# Uninstalls the Elmah package from the default project -Uninstall-Package Elmah + ```powershell + Find-Package -First 100 + ``` -# Uninstalls the Elmah package and all its unused dependencies -Uninstall-Package Elmah -RemoveDependencies +- To list all versions of a certain package: -# Uninstalls the Elmah package even if another package depends on it -Uninstall-Package Elmah -Force + ```powershell + Find-Package -AllVersions -ExactMatch + ``` + +## Install a package + +To install a package into the default project, use `Install-Package `. The [Install-Package](../reference/ps-reference/ps-ref-install-package.md) console command takes the following actions: + +- Does the steps in [What happens when a NuGet package is installed](../concepts/package-installation-process.md). +- Displays applicable license terms in the console window with implied agreement. If you don't agree to the terms, you should uninstall the package. +- Adds a reference to the package in the project file and in **Solution Explorer** under the **References** node. You must save the project before you can see the changes in the project file. + +By default, `Install-Package` adds the package to the default project the console window specifies. To add the package to a project that isn't the default, use the `-ProjectName` option. For example, to add the `Elmah.MVC` package to the non-default `UtilitiesLib` project, run the following command: + +```powershell +Install-Package Elmah.MVC -ProjectName UtilitiesLib ``` -See [Uninstall-Package](../reference/ps-reference/ps-ref-uninstall-package.md). Use [Get-Package](../reference/ps-reference/ps-ref-get-package.md) to see all packages currently installed in the default project if you need to find an identifier. +## Uninstall a package + +To uninstall a package from the default project, use `Uninstall-Package `. If you need to find the package name, use [Get-Package](../reference/ps-reference/ps-ref-get-package.md) to see all packages installed in the default project. -Uninstalling a package performs the following actions: +[Uninstall-Package](../reference/ps-reference/ps-ref-uninstall-package.md) takes the following actions: -- Removes references to the package from the project (and whatever management format is in use). References no longer appear in **Solution Explorer**. (You might need to rebuild the project to see it removed from the **Bin** folder.) -- Reverses any changes made to `app.config` or `web.config` when the package was installed. +- Removes references to the package from the project and any management formats. References no longer appear in **Solution Explorer**. You might need to rebuild the project to remove the reference in the *bin* folder. +- Reverses any changes that installing the package made to *app.config* or *web.config*. - Removes previously-installed dependencies if no remaining packages use those dependencies. +To uninstall a package and all its unused dependencies, run: + +```powershell +Uninstall-Package -RemoveDependencies +``` + +To uninstall a package even if other packages depend on it, run: + +```powershell +Uninstall-Package -Force +``` + ## Update a package -```ps -# Checks if there are newer versions available for any installed packages -Get-Package -updates +To update a package, use [Get-Package](../reference/ps-reference/ps-ref-get-package.md) and [Update-Package](../reference/ps-reference/ps-ref-update-package.md). You can run the following commands: -# Updates a specific package using its identifier, in this case jQuery -Update-Package jQuery +- To check if there are newer versions available for any installed packages: -# Update all packages in the project named MyProject (as it appears in Solution Explorer) -Update-Package -ProjectName MyProject + ```powershell + Get-Package -updates + ``` -# Update all packages in the solution -Update-Package -``` +- To update a specific package: -See [Get-Package](../reference/ps-reference/ps-ref-get-package.md) and [Update-Package](../reference/ps-reference/ps-ref-update-package.md) + ```powershell + Update-Package + ``` -## Find a package +- To update all packages in a project: -```ps -# Find packages containing keywords -Find-Package elmah -Find-Package logging + ```powershell + Update-Package -ProjectName + ``` -# List packages whose ID begins with Elmah -Find-Package Elmah -StartWith +- To update all packages in the solution: -# By default, Get-Package returns a list of 20 packages; use -First to show more -Find-Package logging -First 100 + ```powershell + Update-Package + ``` -# List all versions of the package with the ID of "jquery" -Find-Package jquery -AllVersions -ExactMatch -``` + +## Use the NuGet CLI in the console -See [Find-Package](../reference/ps-reference/ps-ref-find-package.md). In Visual Studio 2013 and earlier, use [Get-Package](../reference/ps-reference/ps-ref-get-package.md) instead. +You can also do most console operations with the [NuGet CLI](../reference/nuget-exe-cli-reference.md). However, the PowerShell console commands operate within the context of Visual Studio saved project and solution, and often do more than their equivalent NuGet CLI commands. For example, installing a package through `Install-Package` adds a reference to the project file, but the NuGet CLI command doesn't. For this reason, developers working in Visual Studio typically prefer to use the console commands rather than the NuGet CLI. -## Availability of the console +To use NuGet CLI commands in the Package Manager Console, install the [NuGet.CommandLine](https://www.nuget.org/packages/NuGet.CommandLine) package. -Starting in Visual Studio 2017, NuGet and the NuGet Package Manager are automatically installed when you select any .NET-related workloads; you can also install it individually by checking the **Individual components > Code tools > NuGet package manager** option in the Visual Studio installer. +```powershell +Install-Package NuGet.CommandLine +``` -Also, if you're missing the NuGet Package Manager in Visual Studio 2015 and earlier, check **Tools > Extensions and Updates...** and search for the NuGet Package Manager extension. If you're unable to use the extensions installer in Visual Studio, you can download the extension directly from [https://dist.nuget.org/index.html](https://dist.nuget.org/index.html). +The preceding command installs the latest version of the NuGet CLI. To install a specific version, use the `-Version` option. For example, to install Version 4.4.1, enter: -The Package Manager Console is not presently available with Visual Studio for Mac. The equivalent commands, however, are available through the [NuGet CLI](../reference/nuget-exe-CLI-reference.md). Visual Studio for Mac does have a UI for managing NuGet packages. See [Including a NuGet package in your project](/visualstudio/mac/nuget-walkthrough). +```powershell +Install-Package NuGet.CommandLine -Version 4.4.1 +``` -The Package Manager Console is not included with Visual Studio Code. +After you install the `NuGet.CommandLine` package, you can run all NuGet CLI commands through the Package Manager Console. ## Extend the Package Manager Console -Some packages install new commands for the console. For example, `MvcScaffolding` creates commands like `Scaffold` shown below, which generates ASP.NET MVC controllers and views: +Some packages install new commands for the console. For example, `MvcScaffolding` creates commands like `Scaffold`, which generates ASP.NET MVC controllers and views: -![Installing and using MvcScaffold](media/PackageManagerConsoleInstall.png) +:::image type="content" source="media/PackageManagerConsoleInstall.png" alt-text="Screenshot that shows NuGet CLI commands available after installing the NuGet.CommandLine package."::: ## Set up a NuGet PowerShell profile -A PowerShell profile lets you make commonly-used commands available wherever you use PowerShell. NuGet supports a NuGet-specific profile typically found at the following location: +You can create a PowerShell profile to make your commonly-used commands available in all PowerShell contexts, so you don't lose your PowerShell settings between sessions. NuGet supports a NuGet-specific profile, usually at *%UserProfile%\Documents\WindowsPowerShell\NuGet_profile.ps1*. - %UserProfile%\Documents\WindowsPowerShell\NuGet_profile.ps1 +To find your user profile location, enter `$profile` in the console: -To find the profile, type `$profile` in the console: - -```ps +```powershell $profile C:\Users\\Documents\WindowsPowerShell\NuGet_profile.ps1 ``` -For more details, refer to [Windows PowerShell Profiles](https://technet.microsoft.com/library/bb613488.aspx). - -## Use the nuget.exe CLI in the console +To determine whether a profile exists at that location, enter `test-path $profile`. If the command returns `False`, you need to create the profile with the specified name at that location. For more information, see [Windows PowerShell Profiles](/previous-versions//bb613488(v=vs.85)). -To make the [`nuget.exe` CLI](../reference/nuget-exe-cli-reference.md) available in the Package Manager Console, install the [NuGet.CommandLine](http://www.nuget.org/packages/NuGet.CommandLine/) package from the console: +## Next steps -```ps -# Other versions are available, see http://www.nuget.org/packages/NuGet.CommandLine/ -Install-Package NuGet.CommandLine -Version 4.4.1 -``` +- [Install and manage NuGet packages with the dotnet CLI](install-use-packages-dotnet-cli.md) +- [Manage packages using the nuget.exe CLI](install-use-packages-nuget-cli.md) +- [Install and manage packages in Visual Studio using the NuGet Package Manager](install-use-packages-visual-studio.md) diff --git a/docs/consume-packages/install-use-packages-visual-studio.md b/docs/consume-packages/install-use-packages-visual-studio.md index cb158e099..66f6cbfbb 100644 --- a/docs/consume-packages/install-use-packages-visual-studio.md +++ b/docs/consume-packages/install-use-packages-visual-studio.md @@ -1,165 +1,191 @@ --- -title: Install and manage NuGet packages in Visual Studio -description: Instructions for using the NuGet Package Manager UI in Visual Studio for working with NuGet packages. -author: karann-msft -ms.author: karann -ms.date: 07/08/2019 +title: Install and manage packages in Visual Studio using the NuGet Package Manager +description: Learn how to use the NuGet Package Manager UI in Visual Studio for working with NuGet packages. +author: JonDouglas +ms.author: jodou +ms.date: 03/03/2025 ms.topic: conceptual f1_keywords: - - "vs.toolsoptionspages.nuget_package_manager" - - "vs.toolsoptionspages.nuget_package_manager.general" - - "vs.toolsoptionspages.nuget_package_manager.package_sources" - "vs.nuget.packagemanager.ui" --- -# Install and manage packages in Visual Studio +# Install and manage packages in Visual Studio using the NuGet Package Manager -The NuGet Package Manager UI in Visual Studio on Windows allows you to easily install, uninstall, and update NuGet packages in projects and solutions. For the experience in Visual Studio for Mac, see [Including a NuGet package in your project](/visualstudio/mac/nuget-walkthrough?toc=/nuget/toc.json). The Package Manager UI is not included with Visual Studio Code. +The NuGet Package Manager UI in Microsoft Visual Studio for Windows allows you to easily install, uninstall, and update NuGet packages in projects and solutions. -> [!NOTE] -> If you're missing the NuGet Package Manager in Visual Studio 2015, check **Tools > Extensions and Updates...** and search for the *NuGet Package Manager* extension. If you're unable to use the extensions installer in Visual Studio, download the extension directly from [https://dist.nuget.org/index.html](https://dist.nuget.org/index.html). -> -> Starting in Visual Studio 2017, NuGet and the NuGet Package Manager are automatically installed with any .NET-related workloads. Install it individually by selecting the **Individual components > Code tools > NuGet package manager** option in the Visual Studio installer. +The article is for Windows users only. If you're using Visual Studio for Mac, see [Including a NuGet package in your project](/visualstudio/mac/nuget-walkthrough?toc=/nuget/toc.json). + +## Prerequisites + +- Install Visual Studio 2022 for Windows with any .NET-related workload. + + You can install the 2022 Community edition for free from [visualstudio.microsoft.com](https://visualstudio.microsoft.com/), or use the Professional or Enterprise edition. + + Visual Studio 2017 and higher automatically includes NuGet Package Manager when a .NET-related workload is installed. To install it individually in Visual Studio Installer, select the **Individual components** tab, and then select **NuGet package manager** under **Code tools** . + + For Visual Studio 2015, if you're missing the NuGet Package Manager, check **Tools** > **Extensions and Updates** and search for the *NuGet Package Manager* extension. If you're unable to use the extensions installer in Visual Studio, download the extension directly from [https://dist.nuget.org/index.html](https://dist.nuget.org/index.html). + +- [Register for a free account on nuget.org](../nuget-org/individual-accounts.md#add-a-new-individual-account) if you don't have one already. You must register and confirm the account before you can upload a NuGet package. ## Find and install a package -1. In **Solution Explorer**, right-click either **References** or a project and select **Manage NuGet Packages...**. +To find and install a NuGet package with Visual Studio, follow these steps: - ![Manage NuGet Packages menu option](media/ManagePackagesUICommand.png) +1. Load a project in **Solution Explorer**, and then select **Project** > **Manage NuGet Packages**. -1. The **Browse** tab displays packages by popularity from the currently selected source (see [package sources](#package-sources)). Search for a specific package using the search box on the upper left. Select a package from the list to display its information, which also enables the **Install** button along with a version-selection drop-down. + The **NuGet Package Manager** window opens. - ![Manage NuGet Packages Dialog Browse tab](media/Search.png) +1. Select the **Browse** tab to display packages by popularity from the currently selected source (see [Package sources](#package-sources)). -1. Select the desired version from the drop-down and select **Install**. Visual Studio installs the package and its dependencies into the project. You may be asked to accept license terms. When installation is complete, the added packages appear on the **Installed** tab. Packages are also listed in the **References** node of Solution Explorer, indicating that you can refer to them in the project with `using` statements. + - To search for a specific package, use the search box on the upper left. + - Abbreviated information may be shown beside each package ID to help identify the correct package, and varies based on the selected package source(s). + Examples include package download count, author, or owner profile hyperlinks. - ![References in Solution Explorer](media/References.png) + > [!Note] + > In Visual Studio 17.11 and higher, package owners are shown as profile hyperlinks when supported by the selected package source. + > Package ownership is defined by the package source. For example, see [Manage package owners on nuget.org](../nuget-org/publish-a-package.md#manage-package-owners-on-nugetorg). + > + > In Visual Studio 17.10 and earlier, the package *author* metadata is shown, which appears as plain-text. + > For more information, see [Authors package metadata](../create-packages/package-authoring-best-practices.md#authors). -> [!Tip] -> To include prerelease versions in the search, and to make prerelease versions available in the version drop-down, select the **Include prerelease** option. + - Select a package to see detailed package information. + The details pane on the right appears and enables you to select a version to install. + ![Screenshot showing the NuGet Package Manager window with the Browse tab, details pane, and "Package Details" tab selected.](media/package-manager-package-details.png) + You can see package metadata, information about the owner(s), author(s), license, etc., in the Package Details tab and the package README file (if it is provided by the package author) in the README tab. + ![Screenshot showing the NuGet Package Manager window with the README tab selected.](media/package-manager-package-readme.png) + +1. In the right pane, select a **Version** from the dropdown list. If you want to include prerelease versions in the **Version** list, select **Include prerelease**. + +1. To install the NuGet package, select **Install**. You might be asked to accept license terms or prompted to verify the installation. + + Visual Studio installs the package and its dependencies in the project. When installation is complete, the added packages appear on the **Installed** tab. You can also find packages in the **Dependencies** > **Packages** node of your project in **Solution Explorer**. After you install a package, you can refer to it in the project with a `using` statement. + +1. (Optional) NuGet has two formats in which a project can use packages: [PackageReference](package-references-in-project-files.md) and [packages.config](../reference/packages-config.md). To set the default format, select **Tools** > **Options**, expand **NuGet Package Manager**, select **General**, and then choose the **Default package management format**. For more information, see [Choose default package management format](package-restore.md#choose-default-package-management-format). ## Uninstall a package -1. In **Solution Explorer**, right-click either **References** or the desired project, and select **Manage NuGet Packages...**. -1. Select the **Installed** tab. -1. Select the package to uninstall (using search to filter the list if necessary) and select **Uninstall**. +To uninstall a NuGet package, follow these steps: + +1. Load a project in **Solution Explorer**, select **Project** > **Manage NuGet Packages**, and then select the **Installed** tab. - ![Uninstalling a package](media/UninstallPackage.png) +1. Select the package to uninstall in the left pane (use the **Search** box to find it, if necessary), and then select **Uninstall** from the right pane. -1. Note that the **Include prerelease** and **Package source** controls have no effect when uninstalling packages. + ![Screenshot showing the NuGet Package Manager with a package selected and its Uninstall button highlighted.](media/uninstall-package.png) ## Update a package -1. In **Solution Explorer**, right-click either **References** or the desired project, and select **Manage NuGet Packages...**. (In web site projects, right-click the **Bin** folder.) -1. Select the **Updates** tab to see packages that have available updates from the selected package sources. Select **Include prerelease** to include prerelease packages in the update list. -1. Select the package to update, select the desired version from the drop-down on the right, and select **Update**. +To update a NuGet package, follow these steps: - ![Updating a package](media/UpdatePackages.png) +1. Load a project in **Solution Explorer**, and then select **Project** > **Manage NuGet Packages**. For website projects, select the **Bin** folder first. -1. For some packages, the **Update** button is disabled and a message appears saying that it's "Implicitly referenced by an SDK" (or "AutoReferenced"). This message indicates that the package is part of a larger framework or SDK and should not be updated independently. (Such packages are internally marked with `True`.) For example, `Microsoft.NETCore.App` is part of the .NET Core SDK, and the package version is not the same as the version of the runtime framework used by the application. You need to [update your .NET Core installation](https://aka.ms/dotnet-download) to get new versions of the ASP.NET Core and .NET Core runtime. [See this document for more details on .NET Core metapackages and versioning](/dotnet/core/packages). This applies to the following commonly used packages: - * Microsoft.AspNetCore.All - * Microsoft.AspNetCore.App - * Microsoft.NETCore.App - * NETStandard.Library +1. Select the **Updates** tab to see packages that have available updates from the selected **Package source**. Select **Include prerelease** to include prerelease packages in the update list. - ![Example package marked as Implicitly references or AutoReferenced](media/PackageManagerUIAutoReferenced.png) +1. Select the package to update. On the right pane, select the desired **Version** from the dropdown list, and then select **Update**. -1. To update multiple packages to their newest versions, select them in the list and select the **Update** button above the list. -1. You can also update an individual package from the **Installed** tab. In this case, the details for the package include a version selector (subject to the **Include prerelease** option) and an **Update** button. + ![Screenshot showing the NuGet Package Manager with a package selected and its Update button highlighted.](media/update-package.png) -## Manage packages for the solution +1. For some packages, the **Update** button is disabled and the following message appears: *Implicitly referenced by an SDK. To update the package, update the SDK to which it belongs.* This message indicates that the package is part of a larger framework or SDK and can't be updated independently. Such packages are internally marked with `True`. For example, `Microsoft.NETCore.App` is part of the .NET Core SDK, and the package version is different than the version of the runtime framework used by the application. To download a new version of the .NET Core, [update your .NET Core installation](https://aka.ms/dotnet-download). For more information, see [.NET Core metapackages and versioning](/dotnet/core/packages). This scenario applies to the following commonly used packages: + - Microsoft.AspNetCore.All + - Microsoft.AspNetCore.App + - Microsoft.NETCore.App + - NETStandard.Library -Managing packages for a solution is a convenient means to work with multiple projects simultaneously. + ![Screenshot showing a NuGet package with the Update button disabled.](media/package-update-disabled.png) -1. Select the **Tools > NuGet Package Manager > Manage NuGet Packages for Solution...** menu command, or right-click the solution and select **Manage NuGet Packages...**: +1. To update multiple packages to their latest versions, choose them in the NuGet package list, and then select **Update**. - ![Manage NuGet packages for the solution](media/ManagePackagesSolutionUICommand.png) +1. You can also update an individual package from the **Installed** tab. For this case, you can also select a **Version** and the **Include prerelease** option. -1. When managing packages for the solution, the UI lets you select the projects that are affected by the operations: - - ![Project selector when managing packages for the solution](media/SolutionPackagesUI.png) +## Manage packages for the solution -### Consolidate tab +Managing packages for a solution is a convenient means to work with multiple projects simultaneously: -Developers typically consider it bad practice to use different versions of the same NuGet package across different projects in the same solution. When you choose to manage packages for a solution, the Package Manager UI provides a **Consolidate** tab on which you can easily see where packages with distinct version numbers are used by different projects in the solution: +1. Select a solution in **Solution Manager**, and then select **Tools** > **NuGet Package Manager** > **Manage NuGet Packages for Solution**. -![Package Manager UI Consolidate tab](media/ConsolidateTab.png) +1. In the **Manage NuGet Packages for Solution** window, select the projects that are affected by the operations. -In this example, the ClassLibrary1 project is using EntityFramework 6.2.0, whereas ConsoleApp1 is using EntityFramework 6.1.0. To consolidate package versions, do the following: + ![Screenshot showing the Manage Packages for Solution window with multiple projects selected.](media/manage-packages-for-solution.png) -- Select the projects to update in the project list. -- Select the version to use in all those projects in the **Version** control, such as EntityFramework 6.2.0. -- Select the **Install** button. +### Consolidate tab -The Package Manager installs the selected package version into all selected projects, after which the package no longer appears on the **Consolidate** tab. +Developers typically consider it bad practice to use different versions of the same NuGet package across different projects in the same solution. Visual Studio allows you to use a common version for your NuGet packages. To do so, use the **Consolidate** tab of the **NuGet Package Manager** window to discover where packages with distinct version numbers are used by different projects in the solution. -## Package sources +![Screenshot showing the Manage Packages for Solution window with the Consolidate tab selected.](media/consolidate-tab.png) -To change the source from which Visual Studio obtains packages, select one from the source selector: +In this example, the ClassLibrary1 project is using EntityFramework 6.2.0, whereas ConsoleApp1 is using EntityFramework 6.1.0. To consolidate package versions, follow these steps: -![Package source selector in the package manager UI](media/PackageSourceDropDown.png) +1. From the **Consolidate** tab, select the projects to update in the project list. -To manage package sources: +1. Select the version to use for all these projects in the **Version** list. -1. Select the **Settings** icon in the Package Manager UI outlined below or use the **Tools > Options** command and scroll to **NuGet Package Manager**: +1. Select **Install**. - ![Package manager UI settings icon](media/PackageSourceSettings.png) + The NuGet Package Manager installs the selected package version into all the selected projects, after which the package no longer appears on the **Consolidate** tab. -1. Select the **Package Sources** node: +## Package sources - ![Package Sources options](media/options.png) +Visual Studio ignores the order of package sources, and uses the package from whichever source is the first to respond to a request. For more information, see [Restore packages](package-restore.md). For information about how to load a package from a specific source, see [Package source mapping](package-source-mapping.md). -1. To add a source, select **+**, edit the name, enter the URL or path in the **Source** control, and select **Update**. The source now appears in the selector drop-down. -1. To change a package source, select it, make edits in the **Name** and **Source** boxes, and select **Update**. -1. To disable a package source, clear the box to the left of the name in the list. -1. To remove a package source, select it and then select the **X** button. -1. Using the up and down arrow buttons does not change the priority order of the package sources. Visual Studio ignores the order of package sources, using the package from whichever source is first to respond to requests. For more information, see [Package restore](../consume-packages/package-restore.md). +1. To change the source from which Visual Studio loads package metadata, select a source from the **Package source** selector. -> [!Tip] -> If a package source reappears after deleting it, it may be listed in a computer-level or user-level `NuGet.Config` files. See [Common NuGet configurations](../consume-packages/configuring-nuget-behavior.md) for the location of these files, then remove the source by editing the files manually or using the [nuget sources command](../reference/nuget-exe-CLI-reference.md). + ![Screenshot showing the Package source selector highlighted.](media/package-source-selector.png) -## Package manager Options control +1. To manage your package sources, select the **Settings** icon or select **Tools** > **Options**. -When a package is selected, the Package Manager UI displays a small, expandable **Options** control below the version selector (shown here both collapsed and expanded). Note that for some project types, only the **Show preview window** option is provided. + ![Screenshot showing the Package source settings icon highlighted.](media/package-source-settings.png) -![Package manager options](media/PackageManagerUIOptions.png) +1. To manage NuGet package sources, see [NuGet Options in Visual Studio](nuget-visual-studio-options.md#package-sources). -The following sections explain these options. +## NuGet Package Manager Options control -### Show preview window +When you select a package, the NuGet Package Manager displays an expandable **Options** control below the **Version** selector. For most project types, only the **Show preview window** option is provided. -When selected, a modal window displays which the dependencies of a chosen package before the package is installed: +![Screenshot showing the NuGet Package manager Options control expanded.](media/package-manager-options.png) -![Example Preview Dialog](media/InstallPreviewDialog.png) +The following sections explain the available options. -### Install and Update Options +### Install and update options -(Not available for all project types.) +These options are available only for certain project types: -**Dependency behavior** configures how NuGet decides which versions of dependent packages to install: +- **Dependency behavior**: This option configures how NuGet decides which versions of dependent packages to install. It has the following settings: -- *Ignore dependencies* skips installing any dependencies, which typically breaks the package being installed. -- *Lowest* [Default] installs the dependency with the minimal version number that meets the requirements of the primary chosen package. -- *Highest Patch* installs the version with the same major and minor version numbers, but the highest patch number. For example, if version 1.2.2 is specified then the highest version that starts with 1.2 will be installed -- *Highest Minor* installs the version with the same major version number but the highest minor number and patch number. If version 1.2.2 is specified, then the highest version that starts with 1 will be installed -- *Highest* installs the highest available version of the package. + - **Ignore dependencies** skips the installation of dependencies, which typically breaks the package being installed. + - **Lowest** [Default] installs the dependency with the minimal version number that meets the requirements of the primary chosen package. + - **Highest Patch** installs the version with the same major and minor version numbers, but the highest patch number. For example, if version 1.2.2 is specified then the highest version that starts with 1.2 will be installed + - **Highest Minor** installs the version with the same major version number but the highest minor number and patch number. If version 1.2.2 is specified, then the highest version that starts with 1 will be installed + - **Highest** installs the highest available version of the package. -**File conflict action** specifies how NuGet should handle packages that already exist in the project or local machine: +- **File conflict action**: This option specifies how NuGet should handle packages that already exist in the project or local machine. It has the following settings: -- *Prompt* instructs NuGet to ask whether to keep or overwrite existing packages. -- *Ignore All* instructs NuGet to skip overwriting any existing packages. -- *Overwrite All* instructs NuGet to overwrite any existing packages. + - **Prompt** instructs NuGet to ask whether to keep or overwrite existing packages. + - **Ignore All** instructs NuGet to skip overwriting any existing packages. + - **Overwrite All** instructs NuGet to overwrite any existing packages. -### Uninstall Options +### Uninstall options + +These options are available only for certain project types: + +- **Remove dependencies**: When selected, removes any dependent packages if they're not referenced elsewhere in the project. + +- **Force uninstall even if there are dependencies on it**: When selected, uninstalls a package even if it's still being referenced in the project. This option is typically used in combination with **Remove dependencies** to remove a package and whatever dependencies it installed. Using this option may, however, lead to broken references in the project. In such a case, you might need to [reinstall those other packages](../consume-packages/reinstalling-and-updating-packages.md). + +## Related video + +- Find NuGet videos on [Channel 9](/shows/nuget-101/) and [YouTube](https://www.youtube.com/playlist?list=PLdo4fOcmZ0oVLvfkFk8O9h6v2Dcdh2bh_). -(Not available for all project types.) +## See also -**Remove dependencies**: when selected, removes any dependent packages if they're not referenced elsewhere in the project. +For more information about NuGet, see the following articles: -**Force uninstall even if there are dependencies on it**: when selected, uninstalls a package even if it's still being referenced in the project. This is typically used in combination with **Remove dependencies** to remove a package and whatever dependencies it installed. Using this option may, however, lead to broken references in the project. In such cases, you may need to [reinstall those other packages](../consume-packages/reinstalling-and-updating-packages.md). +- [What is NuGet?](../what-is-nuget.md) +- [Package consumption workflow](overview-and-workflow.md) +- [Find and choose packages](finding-and-choosing-packages.md) +- [Package references in project files](package-references-in-project-files.md) +- [Install and use a package using the .NET CLI](../quickstart/install-and-use-a-package-using-the-dotnet-cli.md). diff --git a/docs/consume-packages/installing-signed-packages.md b/docs/consume-packages/installing-signed-packages.md index 2706438c4..0814218f4 100644 --- a/docs/consume-packages/installing-signed-packages.md +++ b/docs/consume-packages/installing-signed-packages.md @@ -1,8 +1,8 @@ --- title: Manage package trust boundaries description: Describes the process of installing signed NuGet packages and configuring package signature trust settings. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 11/29/2018 ms.topic: conceptual --- @@ -90,7 +90,7 @@ In some situations you may want to enable verification using certificates that d ### Sync repository certificates -Package repositories should announce the certificates they use in their [service index](../api/service-index.md). Eventually the repository will update these certificates, e.g. when the certificate expires. When that happens, clients with specific policies will require an update to the configuration to include the newly added certificate. You can easily upgrade the trusted signers associated to a repository by using the `nuget.exe` [trusted-signers sync command](../reference/cli-reference/cli-ref-trusted-signers.md#nuget-trusted-signers-sync--name-). +Package repositories should announce the certificates they use in their [service index](../api/service-index.md). Eventually the repository will update these certificates, e.g. when the certificate expires. When that happens, clients with specific policies will require an update to the configuration to include the newly added certificate. You can easily upgrade the trusted signers associated to a repository by using the `nuget.exe` [trusted-signers sync command](../reference/cli-reference/cli-ref-trusted-signers.md#nuget-trusted-signers-sync--name-name). ### Schema reference diff --git a/docs/consume-packages/managing-the-global-packages-and-cache-folders.md b/docs/consume-packages/managing-the-global-packages-and-cache-folders.md index 0fba9e3b3..43a0e01c5 100644 --- a/docs/consume-packages/managing-the-global-packages-and-cache-folders.md +++ b/docs/consume-packages/managing-the-global-packages-and-cache-folders.md @@ -1,8 +1,8 @@ --- title: How to manage the global packages, cache, temp folders in NuGet description: How to manage the global package installation folder, the package cache, and the temp folders that exist on a computer, which are used when installing, restoring, and updating packages. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 03/19/2018 ms.topic: conceptual --- @@ -11,22 +11,70 @@ ms.topic: conceptual Whenever you install, update, or restore a package, NuGet manages packages and package information in several folders outside of your project structure: -| Name | Description and Location (per user)| +| Name | Location | | --- | --- | -| global‑packages | The *global-packages* folder is where NuGet installs any downloaded package. Each package is fully expanded into a subfolder that matches the package identifier and version number. Projects using the PackageReference format always use packages directly from this folder. When using the `packages.config`, packages are installed to the *global-packages* folder, then copied into the project's `packages` folder.
  • Windows: `%userprofile%\.nuget\packages`
  • Mac/Linux: `~/.nuget/packages`
  • Override using the NUGET_PACKAGES environment variable, the `globalPackagesFolder` or `repositoryPath` [configuration settings](../reference/nuget-config-file.md#config-section) (when using PackageReference and `packages.config`, respectively), or the `RestorePackagesPath` MSBuild property (MSBuild only). The environment variable takes precedence over the configuration setting.
| -| http‑cache | The Visual Studio Package Manager (NuGet 3.x+) and the `dotnet` tool store copies of downloaded packages in this cache (saved as `.dat` files), organized into subfolders for each package source. Packages are not expanded, and the cache has an expiration time of 30 minutes.
  • Windows: `%localappdata%\NuGet\v3-cache`
  • Mac/Linux: `~/.local/share/NuGet/v3-cache`
  • Override using the NUGET_HTTP_CACHE_PATH environment variable.
| -| temp | A folder where NuGet stores temporary files during its various operations.
  • Windows: `%temp%\NuGetScratch`
  • Mac/Linux: `/tmp/NuGetScratch`
    • | -| plugins-cache **4.8+** | A folder where NuGet stores the results from the operation claims request.
    • Windows: `%localappdata%\NuGet\plugins-cache`
    • Mac/Linux: `~/.local/share/NuGet/plugins-cache`
    • Override using the NUGET_PLUGINS_CACHE_PATH environment variable.
    | +| [global-packages](#global-packages) |
    • Windows: `%userprofile%\.nuget\packages`
    • Mac/Linux: `~/.nuget/packages`
    • Override using the NUGET_PACKAGES environment variable, the `globalPackagesFolder` or `repositoryPath` [configuration settings](../reference/nuget-config-file.md#config-section) (when using PackageReference and `packages.config`, respectively), or the `RestorePackagesPath` MSBuild property (MSBuild only). The environment variable takes precedence over the configuration setting.
    | +| [http-cache](#http-cache) |
    • Windows: `%localappdata%\NuGet\v3-cache`
    • Mac/Linux: `~/.local/share/NuGet/v3-cache`
    • Override using the NUGET_HTTP_CACHE_PATH environment variable.
    | +| [temp](#temp) |
  • Windows: `%temp%\NuGetScratch`
  • Mac: `/tmp/NuGetScratch`
  • Linux: `/tmp/NuGetScratch`
  • Override using the NUGET_SCRATCH environment variable.
    • | +| [plugins-cache](#plugin-cache) **4.8+** |
    • Windows: `%localappdata%\NuGet\plugins-cache`
    • Mac/Linux: `~/.local/share/NuGet/plugins-cache`
    • Override using the NUGET_PLUGINS_CACHE_PATH environment variable.
    | > [!Note] > NuGet 3.5 and earlier uses *packages-cache* instead of the *http-cache*, which is located in `%localappdata%\NuGet\Cache`. By using the cache and *global-packages* folders, NuGet generally avoids downloading packages that already exist on the computer, improving the performance of install, update, and restore operations. When using PackageReference, the *global-packages* folder also avoids keeping downloaded packages inside project folders, where they might be inadvertently added to source control, and reduces NuGet's overall impact on computer storage. -When asked to retrieve a package, NuGet first looks in the *global-packages* folder. If the exact version of package is not there, then NuGet checks all non-HTTP package sources. If the package is still not found, NuGet looks for the package in the *http-cache* unless you specify `--no-cache` with `dotnet.exe` commands or `-NoCache` with `nuget.exe` commands. If the package is not in the cache, or the cache isn't used, NuGet then retrieves the package over HTTP . +When asked to retrieve a package, NuGet first looks in the *global-packages* folder. If the exact version of package is not there, then NuGet checks all non-HTTP package sources. If the package is still not found, NuGet looks for the package in the *http-cache* unless you specify `--no-http-cache` with `dotnet.exe` commands or `-NoHttpCache` with `nuget.exe` commands. If the package is not in the cache, or the cache isn't used, NuGet then retrieves the package over HTTP . For more information, see [What happens when a package is installed?](../concepts/package-installation-process.md). +## global-packages + +The *global-packages* folder is where NuGet installs any downloaded package. +Each package is fully expanded into a subfolder that matches the package identifier and version number. +Projects using the [PackageReference](package-references-in-project-files.md) format always use packages directly from this folder. +When using the [packages.config](../reference/packages-config.md), packages are installed to the *global-packages* folder, then copied into the project's `packages` folder. + +### Cleaning the global-packages directory + +The global-packages directory needs to be manually cleaned to remove packages that are no longer used. +You can do this with the `dotnet nuget locals global-packages --clean` command, or the "clear NuGet local resources" button in Visual Studio's options (equivalent to `dotnet nuget locals all --clear`). +After clearing the global-packages directory, you will need to restore your projects again to redownload all required packages. +In Visual Studio, you may need to reload your solution to clear NuGet's "up to date restores" cache, or alternatively do a command line restore (for example, within Visual Studio's terminal window) with `msbuild -t:restore your.sln`. + +To clean only unused packages, it's a two step process. +First, there is a [nuget.config setting `updatePackageLastAccessTime`](../reference/nuget-config-file.md) that should be enabled. +This setting will cause NuGet to update each package's `.nupkg.metadata` file when it is used in a restore. +When restore runs, but a project is considered already up to date, the package timestamps are *not* updated. +The `.nupkg.metadata` file is the last file that NuGet will create when downloading and extracting packages during a restore or install, and is the file that restore uses to check if a package has been extracted successfully. + +Second, run a tool to perform the cleanup. +After the `updatePackageLastAccessTime` setting is enabled, we recommend waiting a few days to make sure that all the packages you use regularly have had their timestamps updated. + +At this time, NuGet does not provide a tool or command to do this. +You can [add a 👍 reaction to this GitHub issue](https://github.com/NuGet/Home/issues/4980) to signal your interest. +Some community members have created their own open source NuGet cleaner tools that you can search for. + +If you are going to write your own cleanup tool, it is important that the `.nupkg.metadata` file is deleted if any of the other package files are deleted, so we recommend that this file is deleted first. +Otherwise projects referencing the package may have unexpected behavior. +If writing a cleanup tool in .NET, consider using `ConcurrencyUtilities.ExecuteWithFileLocked[Async](..)` from the [NuGet.Common package](https://www.nuget.org/packages/NuGet.Common), passing the full nupkg path of the package directory you're going to delete as the key, to avoid deleting a package that restore is trying to extract at the same time. +The global packages directory can be programatically found with the [NuGet.Configuration package](https://www.nuget.org/packages/NuGet.Configuration). +Use `Settings.LoadDefaultSettings(path)` to get an `ISettings` instance (you can pass `null` as the path, or pass a directory if you want to handle solutions with a nuget.config that redirects the global-packages directory), and then use `SettingsUtility.GetGlobalPackagesFolder(settings)`. +Alternatively, you can run `dotnet nuget locals global-packages --list` as a child process and parse the output. + +## http-cache + +NuGet will cache copies of most NuGet feed communications (excluding search), organized into subfolders for each package source. +Packages are not expanded, and files with a last modified date older than 30 minutes are typically considered expired. + +## temp + +A folder where NuGet may store temporary files during its various operations. + +## plugin-cache + +A folder where NuGet stores the results from the operation claims request. +See the [cross platform plugins reference](../reference/extensibility/NuGet-Cross-Platform-Plugins.md) for more information. + ## Viewing folder locations You can view locations using the [nuget locals command](../reference/cli-reference/cli-ref-locals.md): @@ -49,11 +97,11 @@ plugins-cache: C:\Users\user1\AppData\Local\NuGet\plugins-cache You can also view folder locations using the [dotnet nuget locals command](/dotnet/core/tools/dotnet-nuget-locals): -```cli +```dotnetcli dotnet nuget locals all --list ``` -Typical output (Mac/Linux; "user1" is the current username): +Typical output (Mac; "user1" is the current username): ```output info : http-cache: /home/user1/.local/share/NuGet/v3-cache @@ -62,10 +110,21 @@ info : temp: /tmp/NuGetScratch info : plugins-cache: /home/user1/.local/share/NuGet/plugins-cache ``` +Typical output (Linux; "user1" is the current username): + +```output +info : http-cache: /home/user1/.local/share/NuGet/v3-cache +info : global-packages: /home/user1/.nuget/packages/ +info : temp: /tmp/NuGetScratchuser1 +info : plugins-cache: /home/user1/.local/share/NuGet/plugins-cache +``` + To display the location of a single folder, use `http-cache`, `global-packages`, `temp`, or `plugins-cache` instead of `all`. ## Clearing local folders +### Command-line + If you encounter package installation problems or otherwise want to ensure that you're installing packages from a remote gallery, use the `locals --clear` option (dotnet.exe) or `locals -clear` (nuget.exe), specifying the folder to clear, or `all` to clear all folders: ```cli @@ -95,19 +154,33 @@ nuget locals all -clear Any packages used by projects that are currently open in Visual Studio are not cleared from the *global-packages* folder. -Starting in Visual Studio 2017, use the **Tools > NuGet Package Manager > Package Manager Settings** menu command, then select **Clear All NuGet Cache(s)**. Managing the cache isn't presently available through the Package Manager Console. In Visual Studio 2015, use the CLI commands instead. +### Visual Studio + +Visual Studio supports clearing all local folders in the "NuGet Package Manager" options found under the **Tools > NuGet Package Manager > Package Manager Settings** menu command. + +On the General page, select **Clear NuGet local resources**. +Once started, this action cannot be cancelled. +A progress bar will be shown and will contain the final status of the command. + +The [Output Window](/visualstudio/ide/output-window) when selecting Show output from "Package Manager" will show additional details about the clear command, including any error messages. + +### Clear NuGet Local Resources + +![Clear NuGet local resources button highlighted in the General page of NuGet options](media/vsoptions/general.png) + +Managing the cache isn't presently available through the Package Manager Console. -![NuGet option command for clearing caches](media/options-clear-caches.png) +For more information, see [NuGet Options in Visual Studio](nuget-visual-studio-options.md#clear-nuget-local-resources). ## Troubleshooting errors The following errors can occur when using `nuget locals` or `dotnet nuget locals`: -- *Error: The process cannot access the file because it is being used by another process* or *Clearing local resources failed: Unable to delete one or more files* +- *Error: The process cannot access the file \ because it is being used by another process* or *Clearing local resources failed: Unable to delete one or more files* One or more files in the folder are in use by another process; for example, a Visual Studio project is open that refers to packages in the *global-packages* folder. Close those processes and try again. -- *Error: Access to the path is denied* or *The directory is not empty* +- *Error: Access to the path \ is denied* or *The directory is not empty* You don't have permission to delete files in the cache. Change the folder permissions, if possible, and try again. Otherwise, contact your system administrator. diff --git a/docs/consume-packages/media/Finding-01-Popularity.png b/docs/consume-packages/media/Finding-01-Popularity.png index 06fbfc690..d50fbecf5 100644 Binary files a/docs/consume-packages/media/Finding-01-Popularity.png and b/docs/consume-packages/media/Finding-01-Popularity.png differ diff --git a/docs/consume-packages/media/Finding-02-SearchResults.png b/docs/consume-packages/media/Finding-02-SearchResults.png index 5e0d72df8..8563e48ac 100644 Binary files a/docs/consume-packages/media/Finding-02-SearchResults.png and b/docs/consume-packages/media/Finding-02-SearchResults.png differ diff --git a/docs/consume-packages/media/Finding-03-Downloads.png b/docs/consume-packages/media/Finding-03-Downloads.png index 0bca8f786..7cdd4b5e9 100644 Binary files a/docs/consume-packages/media/Finding-03-Downloads.png and b/docs/consume-packages/media/Finding-03-Downloads.png differ diff --git a/docs/consume-packages/media/Finding-04-VersionHistory.png b/docs/consume-packages/media/Finding-04-VersionHistory.png index 1a2cdf8bc..f03adbe65 100644 Binary files a/docs/consume-packages/media/Finding-04-VersionHistory.png and b/docs/consume-packages/media/Finding-04-VersionHistory.png differ diff --git a/docs/consume-packages/media/Finding-05-OperationChart.png b/docs/consume-packages/media/Finding-05-OperationChart.png deleted file mode 100644 index 6258d2830..000000000 Binary files a/docs/consume-packages/media/Finding-05-OperationChart.png and /dev/null differ diff --git a/docs/consume-packages/media/Finding-06-include-prerelease.png b/docs/consume-packages/media/Finding-06-include-prerelease.png index 3b6734714..0befb604f 100644 Binary files a/docs/consume-packages/media/Finding-06-include-prerelease.png and b/docs/consume-packages/media/Finding-06-include-prerelease.png differ diff --git a/docs/consume-packages/media/Finding-07-MostPopular.png b/docs/consume-packages/media/Finding-07-MostPopular.png new file mode 100644 index 000000000..ac05cde3d Binary files /dev/null and b/docs/consume-packages/media/Finding-07-MostPopular.png differ diff --git a/docs/consume-packages/media/Finding-08-FiltersAndSorts.png b/docs/consume-packages/media/Finding-08-FiltersAndSorts.png new file mode 100644 index 000000000..3f4ef4dfd Binary files /dev/null and b/docs/consume-packages/media/Finding-08-FiltersAndSorts.png differ diff --git a/docs/consume-packages/media/Finding-09-FrameworkFilterPanel.png b/docs/consume-packages/media/Finding-09-FrameworkFilterPanel.png new file mode 100644 index 000000000..e8a2ba20a Binary files /dev/null and b/docs/consume-packages/media/Finding-09-FrameworkFilterPanel.png differ diff --git a/docs/consume-packages/media/Finding-10-FrameworkBadgesInSearch.png b/docs/consume-packages/media/Finding-10-FrameworkBadgesInSearch.png new file mode 100644 index 000000000..fd8703fe3 Binary files /dev/null and b/docs/consume-packages/media/Finding-10-FrameworkBadgesInSearch.png differ diff --git a/docs/consume-packages/media/GitHub-Usage.png b/docs/consume-packages/media/GitHub-Usage.png new file mode 100644 index 000000000..fa3f61790 Binary files /dev/null and b/docs/consume-packages/media/GitHub-Usage.png differ diff --git a/docs/consume-packages/media/Options.png b/docs/consume-packages/media/Options.png deleted file mode 100644 index 20d91f19e..000000000 Binary files a/docs/consume-packages/media/Options.png and /dev/null differ diff --git a/docs/consume-packages/media/Package-Pattern-Examples.png b/docs/consume-packages/media/Package-Pattern-Examples.png new file mode 100644 index 000000000..3a9e81b6f Binary files /dev/null and b/docs/consume-packages/media/Package-Pattern-Examples.png differ diff --git a/docs/consume-packages/media/PackageManagerConsoleControls.png b/docs/consume-packages/media/PackageManagerConsoleControls.png deleted file mode 100644 index aed369a18..000000000 Binary files a/docs/consume-packages/media/PackageManagerConsoleControls.png and /dev/null differ diff --git a/docs/consume-packages/media/PackageManagerConsoleInstall.png b/docs/consume-packages/media/PackageManagerConsoleInstall.png index 716e941e0..dbb5f979e 100644 Binary files a/docs/consume-packages/media/PackageManagerConsoleInstall.png and b/docs/consume-packages/media/PackageManagerConsoleInstall.png differ diff --git a/docs/consume-packages/media/Restore-01-AutoRestoreOptions.png b/docs/consume-packages/media/Restore-01-AutoRestoreOptions.png deleted file mode 100644 index 1e5f04321..000000000 Binary files a/docs/consume-packages/media/Restore-01-AutoRestoreOptions.png and /dev/null differ diff --git a/docs/consume-packages/media/Restore-02-VSTSBuild.png b/docs/consume-packages/media/Restore-02-VSTSBuild.png deleted file mode 100644 index 2b66a9f3a..000000000 Binary files a/docs/consume-packages/media/Restore-02-VSTSBuild.png and /dev/null differ diff --git a/docs/consume-packages/media/Symbols_01-AddingSource.png b/docs/consume-packages/media/Symbols_01-AddingSource.png deleted file mode 100644 index 7d5960461..000000000 Binary files a/docs/consume-packages/media/Symbols_01-AddingSource.png and /dev/null differ diff --git a/docs/consume-packages/media/Used-By-section-Humanizer.png b/docs/consume-packages/media/Used-By-section-Humanizer.png new file mode 100644 index 000000000..594658790 Binary files /dev/null and b/docs/consume-packages/media/Used-By-section-Humanizer.png differ diff --git a/docs/consume-packages/media/ConsolidateTab.png b/docs/consume-packages/media/consolidate-tab.png similarity index 100% rename from docs/consume-packages/media/ConsolidateTab.png rename to docs/consume-packages/media/consolidate-tab.png diff --git a/docs/consume-packages/media/SolutionPackagesUI.png b/docs/consume-packages/media/manage-packages-for-solution.png similarity index 100% rename from docs/consume-packages/media/SolutionPackagesUI.png rename to docs/consume-packages/media/manage-packages-for-solution.png diff --git a/docs/consume-packages/media/options-clear-caches.png b/docs/consume-packages/media/options-clear-caches.png deleted file mode 100644 index 0a99c9b38..000000000 Binary files a/docs/consume-packages/media/options-clear-caches.png and /dev/null differ diff --git a/docs/consume-packages/media/package-manager-browse-tab.png b/docs/consume-packages/media/package-manager-browse-tab.png new file mode 100644 index 000000000..d48ddbd1b Binary files /dev/null and b/docs/consume-packages/media/package-manager-browse-tab.png differ diff --git a/docs/consume-packages/media/package-manager-install-tab.png b/docs/consume-packages/media/package-manager-install-tab.png new file mode 100644 index 000000000..253bf15f5 Binary files /dev/null and b/docs/consume-packages/media/package-manager-install-tab.png differ diff --git a/docs/consume-packages/media/PackageManagerUIOptions.png b/docs/consume-packages/media/package-manager-options.png similarity index 100% rename from docs/consume-packages/media/PackageManagerUIOptions.png rename to docs/consume-packages/media/package-manager-options.png diff --git a/docs/consume-packages/media/package-manager-package-details.png b/docs/consume-packages/media/package-manager-package-details.png new file mode 100644 index 000000000..4ec7cc9a7 Binary files /dev/null and b/docs/consume-packages/media/package-manager-package-details.png differ diff --git a/docs/consume-packages/media/package-manager-package-readme.png b/docs/consume-packages/media/package-manager-package-readme.png new file mode 100644 index 000000000..855595145 Binary files /dev/null and b/docs/consume-packages/media/package-manager-package-readme.png differ diff --git a/docs/consume-packages/media/PackageSourceDropDown.png b/docs/consume-packages/media/package-source-selector.png similarity index 100% rename from docs/consume-packages/media/PackageSourceDropDown.png rename to docs/consume-packages/media/package-source-selector.png diff --git a/docs/consume-packages/media/PackageSourceSettings.png b/docs/consume-packages/media/package-source-settings.png similarity index 100% rename from docs/consume-packages/media/PackageSourceSettings.png rename to docs/consume-packages/media/package-source-settings.png diff --git a/docs/consume-packages/media/PackageManagerUIAutoReferenced.png b/docs/consume-packages/media/package-update-disabled.png similarity index 100% rename from docs/consume-packages/media/PackageManagerUIAutoReferenced.png rename to docs/consume-packages/media/package-update-disabled.png diff --git a/docs/consume-packages/media/packageSourceMapping_PMUI_Status_Mapped.png b/docs/consume-packages/media/packageSourceMapping_PMUI_Status_Mapped.png new file mode 100644 index 000000000..e27bf3920 Binary files /dev/null and b/docs/consume-packages/media/packageSourceMapping_PMUI_Status_Mapped.png differ diff --git a/docs/consume-packages/media/packageSourceMapping_PMUI_Status_Off_Annotated.png b/docs/consume-packages/media/packageSourceMapping_PMUI_Status_Off_Annotated.png new file mode 100644 index 000000000..c2d698f20 Binary files /dev/null and b/docs/consume-packages/media/packageSourceMapping_PMUI_Status_Off_Annotated.png differ diff --git a/docs/consume-packages/media/prefix-reserved.png b/docs/consume-packages/media/prefix-reserved.png new file mode 100644 index 000000000..8396d40e0 Binary files /dev/null and b/docs/consume-packages/media/prefix-reserved.png differ diff --git a/docs/consume-packages/media/projectJson-dependency-1.png b/docs/consume-packages/media/projectJson-dependency-1.png deleted file mode 100644 index 50f1c7b77..000000000 Binary files a/docs/consume-packages/media/projectJson-dependency-1.png and /dev/null differ diff --git a/docs/consume-packages/media/projectJson-dependency-2.png b/docs/consume-packages/media/projectJson-dependency-2.png deleted file mode 100644 index badc8fef0..000000000 Binary files a/docs/consume-packages/media/projectJson-dependency-2.png and /dev/null differ diff --git a/docs/consume-packages/media/projectJson-dependency-3.png b/docs/consume-packages/media/projectJson-dependency-3.png deleted file mode 100644 index 8f5c85f67..000000000 Binary files a/docs/consume-packages/media/projectJson-dependency-3.png and /dev/null differ diff --git a/docs/consume-packages/media/projectJson-dependency-4.png b/docs/consume-packages/media/projectJson-dependency-4.png deleted file mode 100644 index d17973c52..000000000 Binary files a/docs/consume-packages/media/projectJson-dependency-4.png and /dev/null differ diff --git a/docs/consume-packages/media/projectJson-dependency-5.png b/docs/consume-packages/media/projectJson-dependency-5.png deleted file mode 100644 index 5e0df0b07..000000000 Binary files a/docs/consume-packages/media/projectJson-dependency-5.png and /dev/null differ diff --git a/docs/consume-packages/media/projectJson-dependency-6.png b/docs/consume-packages/media/projectJson-dependency-6.png deleted file mode 100644 index 5925eebd0..000000000 Binary files a/docs/consume-packages/media/projectJson-dependency-6.png and /dev/null differ diff --git a/docs/consume-packages/media/projectJson-dependency-7.png b/docs/consume-packages/media/projectJson-dependency-7.png deleted file mode 100644 index 7158cd1a6..000000000 Binary files a/docs/consume-packages/media/projectJson-dependency-7.png and /dev/null differ diff --git a/docs/consume-packages/media/projectJson-dependency-8.png b/docs/consume-packages/media/projectJson-dependency-8.png deleted file mode 100644 index 980604f43..000000000 Binary files a/docs/consume-packages/media/projectJson-dependency-8.png and /dev/null differ diff --git a/docs/consume-packages/media/right-column.png b/docs/consume-packages/media/right-column.png new file mode 100644 index 000000000..453d7419a Binary files /dev/null and b/docs/consume-packages/media/right-column.png differ diff --git a/docs/consume-packages/media/supported-frameworks.png b/docs/consume-packages/media/supported-frameworks.png new file mode 100644 index 000000000..22be75e34 Binary files /dev/null and b/docs/consume-packages/media/supported-frameworks.png differ diff --git a/docs/consume-packages/media/UninstallPackage.png b/docs/consume-packages/media/uninstall-package.png similarity index 100% rename from docs/consume-packages/media/UninstallPackage.png rename to docs/consume-packages/media/uninstall-package.png diff --git a/docs/consume-packages/media/UpdatePackages.png b/docs/consume-packages/media/update-package.png similarity index 100% rename from docs/consume-packages/media/UpdatePackages.png rename to docs/consume-packages/media/update-package.png diff --git a/docs/consume-packages/media/vsoptions/configuration-files.png b/docs/consume-packages/media/vsoptions/configuration-files.png new file mode 100644 index 000000000..73d576337 Binary files /dev/null and b/docs/consume-packages/media/vsoptions/configuration-files.png differ diff --git a/docs/consume-packages/media/vsoptions/general.png b/docs/consume-packages/media/vsoptions/general.png new file mode 100644 index 000000000..debce051c Binary files /dev/null and b/docs/consume-packages/media/vsoptions/general.png differ diff --git a/docs/consume-packages/media/vsoptions/package-source-add.png b/docs/consume-packages/media/vsoptions/package-source-add.png new file mode 100644 index 000000000..69113b750 Binary files /dev/null and b/docs/consume-packages/media/vsoptions/package-source-add.png differ diff --git a/docs/consume-packages/media/vsoptions/package-source-http-error.png b/docs/consume-packages/media/vsoptions/package-source-http-error.png new file mode 100644 index 000000000..9ce2f2722 Binary files /dev/null and b/docs/consume-packages/media/vsoptions/package-source-http-error.png differ diff --git a/docs/consume-packages/media/vsoptions/package-source-http-warn.png b/docs/consume-packages/media/vsoptions/package-source-http-warn.png new file mode 100644 index 000000000..f1a4569d4 Binary files /dev/null and b/docs/consume-packages/media/vsoptions/package-source-http-warn.png differ diff --git a/docs/consume-packages/media/vsoptions/package-source-machine-wide.png b/docs/consume-packages/media/vsoptions/package-source-machine-wide.png new file mode 100644 index 000000000..aae8df7eb Binary files /dev/null and b/docs/consume-packages/media/vsoptions/package-source-machine-wide.png differ diff --git a/docs/consume-packages/media/vsoptions/package-source-mapping-add.png b/docs/consume-packages/media/vsoptions/package-source-mapping-add.png new file mode 100644 index 000000000..7c9fc5183 Binary files /dev/null and b/docs/consume-packages/media/vsoptions/package-source-mapping-add.png differ diff --git a/docs/consume-packages/media/vsoptions/package-source-mapping-missing-source.png b/docs/consume-packages/media/vsoptions/package-source-mapping-missing-source.png new file mode 100644 index 000000000..120c2374b Binary files /dev/null and b/docs/consume-packages/media/vsoptions/package-source-mapping-missing-source.png differ diff --git a/docs/consume-packages/media/vsoptions/package-source-mapping.png b/docs/consume-packages/media/vsoptions/package-source-mapping.png new file mode 100644 index 000000000..eb4c24d0b Binary files /dev/null and b/docs/consume-packages/media/vsoptions/package-source-mapping.png differ diff --git a/docs/consume-packages/media/vsoptions/package-sources-page.png b/docs/consume-packages/media/vsoptions/package-sources-page.png new file mode 100644 index 000000000..8edf71c39 Binary files /dev/null and b/docs/consume-packages/media/vsoptions/package-sources-page.png differ diff --git a/docs/reference/migrate-packages-config-to-package-reference.md b/docs/consume-packages/migrate-packages-config-to-package-reference.md similarity index 68% rename from docs/reference/migrate-packages-config-to-package-reference.md rename to docs/consume-packages/migrate-packages-config-to-package-reference.md index bba29553d..5dcf4c9a1 100644 --- a/docs/reference/migrate-packages-config-to-package-reference.md +++ b/docs/consume-packages/migrate-packages-config-to-package-reference.md @@ -1,15 +1,15 @@ --- -title: Migrating from package.config to PackageReference formats -description: Details on how to migrate a project from the package.config management format to PackageReference as supported by NuGet 4.0+ and VS2017 and .NET Core 2.0 -author: karann-msft -ms.author: karann -ms.date: 05/24/2019 +title: Migrating from packages.config to PackageReference formats +description: Details on how to migrate a project from the packages.config management format to PackageReference as supported by NuGet 4.0+ and VS2017 and .NET Core 2.0 +author: JonDouglas +ms.author: jodou +ms.date: 08/23/2021 ms.topic: conceptual --- # Migrate from packages.config to PackageReference -Visual Studio 2017 Version 15.7 and later supports migrating a project from the [packages.config](./packages-config.md) management format to the [PackageReference](../consume-packages/Package-References-in-Project-Files.md) format. +Visual Studio 2017 Version 15.7 and later supports migrating a project from the [packages.config](../reference/packages-config.md) management format to the [PackageReference](../consume-packages/Package-References-in-Project-Files.md) format. ## Benefits of using PackageReference @@ -17,14 +17,16 @@ Visual Studio 2017 Version 15.7 and later supports migrating a project from the * **Uncluttered view of top-level dependencies**: Unlike packages.config, PackageReference lists only those NuGet packages you directly installed in the project. As a result, the NuGet Package Manager UI and the project file aren't cluttered with down-level dependencies. * **Performance improvements**: When using PackageReference, packages are maintained in the *global-packages* folder (as described on [Managing the global packages and cache folders](../consume-packages/managing-the-global-packages-and-cache-folders.md) rather than in a `packages` folder within the solution. As a result, PackageReference performs faster and consumes less disk space. * **Fine control over dependencies and content flow**: Using the existing features of MSBuild allows you to [conditionally reference a NuGet package](../consume-packages/Package-References-in-Project-Files.md#adding-a-packagereference-condition) and choose package references per target framework, configuration, platform, or other pivots. -* **PackageReference is under active development**: See [PackageReference issues on GitHub](https://aka.ms/nuget-pr-improvements). packages.config is no longer under active development. + ### Limitations -* NuGet PackageReference is not available in Visual Studio 2015 and earlier. Migrated projects can be opened only in Visual Studio 2017. +* NuGet PackageReference is not available in Visual Studio 2015 and earlier. Migrated projects can be opened only in Visual Studio 2017 and later. * Migration is not currently available for C++ and ASP.NET projects. * Some packages may not be fully compatible with PackageReference. For more information, see [package compatibility issues](#package-compatibility-issues). +In addition, there are some differences in how PackageReferences work compared to packages.config. For example, [Constraints on upgrade versions](../consume-packages/reinstalling-and-updating-packages.md#constraints-on-upgrade-versions) is not supported by PackageReference, but PackageReference adds support for [Floating Versions](../consume-packages/package-references-in-project-files.md#floating-versions). + ### Known Issues 1. The `Migrate packages.config to PackageReference...` option is not available in the right-click context menu @@ -85,7 +87,9 @@ You should now be able to see the migration option. Note that this option is not ## Create a package after migration -Once the migration is complete, we recommend that you add a reference to the [nuget.build.tasks.pack](https://www.nuget.org/packages/nuget.build.tasks.pack) nuget package, and then use [msbuild -t:pack](../reference/msbuild-targets.md#pack-target) to create the package. Although in some scenarios you could use `dotnet.exe pack` instead of `msbuild -t:pack`, it is not recommended. +Once the migration is complete, we recommend that you copy your package metadata from a `.nuspec` file to [MSBuild properties](../reference/msbuild-targets.md#pack-target), and then you can use `msbuild -t:pack` to create the package. +If you are using Visual Studio 2022 or earlier, you will also need to install the NuGet.Build.Tasks.Pack package. +From Visual Studio 2026, pack is built into MSBuild. ## Package compatibility issues @@ -93,31 +97,27 @@ Some aspects that were supported in packages.config are not supported in Package ### "install.ps1" scripts are ignored when the package is installed after the migration -| | | -| --- | --- | -| **Description** | With PackageReference, install.ps1 and uninstall.ps1 PowerShell scripts are not executed while installing or uninstalling a package. | -| **Potential impact** | Packages that depend on these scripts to configure some behavior in the destination project might not work as expected. | +* **Description**: With PackageReference, install.ps1 and uninstall.ps1 PowerShell scripts are not executed while installing or uninstalling a package. + +* **Potential impact**: Packages that depend on these scripts to configure some behavior in the destination project might not work as expected. ### "content" assets are not available when the package is installed after the migration -| | | -| --- | --- | -| **Description** | Assets in a package's `content` folder are not supported with PackageReference and are ignored. PackageReference adds support for `contentFiles` to have better transitive support and shared content. | -| **Potential impact** | Assets in `content` are not copied into the project and project code that depends on the presence of those assets requires refactoring. | +* **Description**: Assets in a package's `content` folder are not supported with PackageReference and are ignored. PackageReference adds support for `contentFiles` to have better transitive support and shared content. + +* **Potential impact**: Assets in `content` are not copied into the project and project code that depends on the presence of those assets requires refactoring. ### XDT transforms are not applied when the package is installed after the upgrade -| | | -| --- | --- | -| **Description** | XDT transforms are not supported with PackageReference and `.xdt` files are ignored when installing or uninstalling a package. | -| **Potential impact** | XDT transforms are not applied to any project XML files, most commonly, `web.config.install.xdt` and `web.config.uninstall.xdt`, which means the project's` web.config` file is not updated when the package is installed or uninstalled. | +* **Description**: XDT transforms are not supported with PackageReference and `.xdt` files are ignored when installing or uninstalling a package. + +* **Potential impact**: XDT transforms are not applied to any project XML files, most commonly, `web.config.install.xdt` and `web.config.uninstall.xdt`, which means the project's `web.config` file is not updated when the package is installed or uninstalled. ### Assemblies in the lib root are ignored when the package is installed after the migration -| | | -| --- | --- | -| **Description** | With PackageReference, assemblies present at the root of `lib` folder without a target framework specific sub-folder are ignored. NuGet looks for a sub-folder matching the target framework moniker (TFM) corresponding to the project’s target framework and installs the matching assemblies into the project. | -| **Potential impact** | Packages that do not have a sub-folder matching the target framework moniker (TFM) corresponding to the project’s target framework may not behave as expected after the transition or fail installation during the migration | +* **Description**: With PackageReference, assemblies present at the root of `lib` folder without a target framework specific sub-folder are ignored. NuGet looks for a sub-folder matching the target framework moniker (TFM) corresponding to the project’s target framework and installs the matching assemblies into the project. + +* **Potential impact**: Packages that do not have a sub-folder matching the target framework moniker (TFM) corresponding to the project’s target framework may not behave as expected after the transition or fail installation during the migration. ## Found an issue? Report it! diff --git a/docs/consume-packages/nuget-visual-studio-options.md b/docs/consume-packages/nuget-visual-studio-options.md new file mode 100644 index 000000000..b773e33e8 --- /dev/null +++ b/docs/consume-packages/nuget-visual-studio-options.md @@ -0,0 +1,161 @@ +--- +title: NuGet Options in Visual Studio +description: Reference guide for NuGet Package Manager options in Visual Studio, including General, Configuration Files, Package Sources, and Package Source Mapping settings. +author: donnie-msft +ms.author: eagoodso +ms.date: 10/03/2025 +ms.topic: reference +f1_keywords: + - "vs.toolsoptionspages.nuget_package_manager" + - "vs.toolsoptionspages.nuget_package_manager.general" + - "vs.toolsoptionspages.nuget_package_manager.configuration_files" + - "vs.toolsoptionspages.nuget_package_manager.package_sources" + - "vs.toolsoptionspages.nuget_package_manager.package_source_mapping" +--- + +# NuGet Package Manager Options in Visual Studio + +Visual Studio provides several options pages for configuring NuGet Package Manager behavior. +Configuration settings for NuGet are stored in your [NuGet.Config file(s)](../reference/nuget-config-file.md). + +## Accessing NuGet Options + +There are multiple ways to access NuGet Package Manager options: + +1. **From the main menu**: Go to **Tools > Options**, then expand **NuGet Package Manager** in the left pane. +1. **From the NuGet menu** found under the **Tools > NuGet Package Manager > Package Manager Settings** menu command. +1. **Quick search**: Use [Visual Studio search](/visualstudio/ide/visual-studio-search) to search for "NuGet" or a NuGet-related setting name to quickly jump to its Options page. +1. **From Package Manager UI**: Press the settings (gear) icon in the Package Manager UI toolbar. +1. **From Package Manager Console**: Click the settings (gear) icon in the Package Manager Console toolbar. + +## General + +The General options page contains settings that control NuGet's package management behavior. + +![Clear NuGet local resources button highlighted in the General page of NuGet options](media/vsoptions/general.png) + +### Package Restore + +Settings for automatic package restore during build operations: + +- **Allow NuGet to download missing packages**: Select to enable package restore and the Restore NuGet Packages command. +- **Automatically check for missing packages during build in Visual Studio**: Select to automatically restore any missing packages when you run a build from Visual Studio. + +See [Package Restore](Package-Restore.md) for more information on package restore behavior. + +### Binding Redirects + +- **Skip applying binding redirects**: When enabled, NuGet will not automatically add or update binding redirects in app.config or web.config files during package installation or updates + +### Package Management + +- **Default package management format**: Choose between the NuGet formats [PackageReference](package-references-in-project-files.md) (recommended for most projects) and [packages.config](../reference/packages-config.md) (legacy format for older projects). + For more information, see [Choose default package management format](package-restore.md#choose-default-package-management-format). + + - **PackageReference**: Stores package references directly in project files. This is the modern format that supports better dependency resolution and is required for SDK-style projects + - **packages.config**: Legacy XML file format that stores package information separately from the project file + +- **Prompt for format selection on first package install**: When enabled, Visual Studio will ask you to choose between PackageReference and packages.config the first time you install a package in a project that doesn't already have packages. + +### Clear NuGet Local Resources + +The **Clear NuGet Local Resources** command button allows you to clear NuGet's local caches, including: + +- **http-cache**: Downloaded package metadata and packages +- **global-packages**: Installed packages folder +- **temp**: Temporary files +- **plugins-cache**: Plugin operation results + +For more information on NuGet caches and folders, see [Managing the global packages, cache, and temp folders](managing-the-global-packages-and-cache-folders.md). + +## Configuration Files + +The Configuration Files options page displays the NuGet.Config files that apply to your current solution and allows you to open them directly in Visual Studio for editing. + +To edit a file, select a File Path and press the "Open" button. +The file will open in a new tab in Visual Studio where it may be edited directly. + +![Configuration files page of NuGet options with the Open button highlighted](media/vsoptions/configuration-files.png) + +Configuration files are listed in order from highest to lowest priority. +NuGet uses a hierarchical configuration system where settings from multiple config files are merged. +For more information, see [Common NuGet configurations](configuring-nuget-behavior.md). + +## Package Sources + +The Package Sources options page allows you to manage the sources from which NuGet downloads packages. + +![Package Sources page of NuGet options](media/vsoptions/package-sources-page.png) + +### Managing Package Sources + +Lists all configured package sources according to your NuGet.Config files. + +- **Name**: Display name for the source +- **Source**: URL or file path for the package source +- **Enabled checkbox**: Enable or disable a source without removing it. +- **Allow Insecure Connections**: Enable or disable allowing insecure HTTP connections + +To modify, use the **Add, Edit, and Remove buttons** below the table. +Checkboxes may be toggled directly in the table. +Press "Save" on the Add/Edit dialog and the changes will be updated in the relevant NuGet.Config file. + +![Add dialog on the Package Sources page](media/vsoptions/package-source-add.png) + +### Machine-wide Package Sources + +Package sources defined at the machine level appear in a dedicated section below. +These are generally provisioned by Visual Studio workloads and can only be enabled or disabled using the checkbox in the Enabled column. + +![Machine-wide sources table on the Package Sources page](media/vsoptions/package-source-machine-wide.png) + +### Allow Insecure Connections + +For security reasons, NuGet enforces the use of HTTPS sources by default. +If you need to use an HTTP source, you must explicitly allow it. +When an HTTP source is used, the first column of the Package Sources table will show an icon with information about a warning or an error with the package source in that row. + +⚠️ When an HTTP package source is used and Allow Insecure Connections is enabled, a warning is shown in the leftmost status column: + +> HTTP sources are insecure. Consider using HTTPS instead. 'AllowInsecureConnections' is enabled, permitting HTTP access. + +![Package Sources page with an HTTP source Warning and Allow Insecure Connections enabled](media/vsoptions/package-source-http-warn.png) + +❌ When an HTTP source is used and Allow Insecure Connections is disabled, an error is shown in the leftmost status column and NuGet restore will fail: + +> NuGet requires HTTPS sources. To use an HTTP source, you must explicitly set 'allowInsecureConnections' to true in your NuGet.Config file. + +![Package Sources page with an HTTP source Error and Allow Insecure Connections disabled](media/vsoptions/package-source-http-error.png) + +For more information on configuring HTTP source permissions, see . + +## Package Source Mapping + +Package Source Mapping allows you to control which package sources are used for specific packages, improving supply chain security. + +![Package Source Mapping page of NuGet options](media/vsoptions//package-source-mapping.png) + +To modify, use the **Add, Edit, and Remove buttons** below the table. + +### Managing Package Source Mappings + +Lists all configured package source mappings according to your NuGet.Config files. + +- **Package pattern**: Package pattern that is currently mapped (e.g., `Microsoft.*` or `Contoso.Contracts`) +- **Source**: One or more package sources mapped to the package pattern. + Package sources must be enabled to be shown. + +To modify, use the **Add, Edit, and Remove buttons** below the table. +Press "Save" on the Add/Edit dialog and the changes will be updated in the relevant NuGet.Config file. + +![Package Source Mapping add dialog](media/vsoptions/package-source-mapping-add.png) + +For more information, see [Package Source Mapping](Package-Source-Mapping.md). + +### Invalid Source Mappings + +If a package source listed in your existing source mapping isn't enabled in your NuGet.Config file(s), an error will appear in the leftmost column. + +Make sure all Source values in your mappings refer to package sources that are both available and enabled. Otherwise, the mapping may not work as expected. + +![Package Source Mapping with an invalid package source](media/vsoptions/package-source-mapping-missing-source.png) diff --git a/docs/create-packages/Creating-Localized-Packages.md b/docs/create-packages/Creating-Localized-Packages.md index ee318342f..e232765ba 100644 --- a/docs/create-packages/Creating-Localized-Packages.md +++ b/docs/create-packages/Creating-Localized-Packages.md @@ -1,8 +1,8 @@ --- title: How to Create a Localized NuGet Package description: Details on the two ways to create localized NuGet packages, either by including all assemblies in a single package or publishing separate assemblies. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 01/18/2018 ms.topic: conceptual --- @@ -22,34 +22,36 @@ Including localized resource assemblies in a single package is typically the sim For example, the following folder structure supports, German (de), Italian (it), Japanese (ja), Russian (ru), Chinese (Simplified) (zh-Hans), and Chinese (Traditional) (zh-Hant): - lib - └───net40 - │ Contoso.Utilities.dll - │ Contoso.Utilities.xml - │ - ├───de - │ Contoso.Utilities.resources.dll - │ Contoso.Utilities.xml - │ - ├───it - │ Contoso.Utilities.resources.dll - │ Contoso.Utilities.xml - │ - ├───ja - │ Contoso.Utilities.resources.dll - │ Contoso.Utilities.xml - │ - ├───ru - │ Contoso.Utilities.resources.dll - │ Contoso.Utilities.xml - │ - ├───zh-Hans - │ Contoso.Utilities.resources.dll - │ Contoso.Utilities.xml - │ - └───zh-Hant - Contoso.Utilities.resources.dll - Contoso.Utilities.xml +``` +lib +└───net40 + │ Contoso.Utilities.dll + │ Contoso.Utilities.xml + │ + ├───de + │ Contoso.Utilities.resources.dll + │ Contoso.Utilities.xml + │ + ├───it + │ Contoso.Utilities.resources.dll + │ Contoso.Utilities.xml + │ + ├───ja + │ Contoso.Utilities.resources.dll + │ Contoso.Utilities.xml + │ + ├───ru + │ Contoso.Utilities.resources.dll + │ Contoso.Utilities.xml + │ + ├───zh-Hans + │ Contoso.Utilities.resources.dll + │ Contoso.Utilities.xml + │ + └───zh-Hant + Contoso.Utilities.resources.dll + Contoso.Utilities.xml +``` You can see that the languages are all listed underneath the `net40` target framework folder. If you're [supporting multiple frameworks](../create-packages/supporting-multiple-target-frameworks.md), then you have a folder under `lib` for each variant. @@ -66,7 +68,7 @@ With these folders in place, you then reference all the files in your `.nuspec`: ``` -One example package that uses this approach is [Microsoft.Data.OData 5.4.0](http://nuget.org/packages/Microsoft.Data.OData/5.4.0). +One example package that uses this approach is [Microsoft.Data.OData 5.4.0](https://nuget.org/packages/Microsoft.Data.OData/5.4.0). ### Advantages and disadvantages (localized resource assemblies) @@ -87,24 +89,28 @@ Similar to how .NET Framework supports satellite assemblies, this method separat Do to this, your primary package uses the naming convention `{identifier}.{version}.nupkg` and contains the assembly for the default language (such as en-US). For example, `ContosoUtilities.1.0.0.nupkg` would contain the following structure: - lib - └───net40 - ContosoUtilities.dll - ContosoUtilities.xml +``` +lib +└───net40 + ContosoUtilities.dll + ContosoUtilities.xml +``` A satellite assembly then uses the naming convention `{identifier}.{language}.{version}.nupkg`, such as `ContosoUtilities.de.1.0.0.nupkg`. The identifier **must** exactly match that of the primary package. Because this is a separate package, it has its own `.nuspec` file that contains localized metadata. Be mindful that the language in the `.nuspec` **must** match the one used in the filename. -The satellite assembly **must** also declare an exact version of the primary package as a dependency, using the [] version notation (see [Package versioning](../reference/package-versioning.md)). For example, `ContosoUtilities.de.1.0.0.nupkg` must declare a dependency on `ContosoUtilities.1.0.0.nupkg` using the `[1.0.0]` notation. The satellite package can, of course, have a different version number than the primary package. +The satellite assembly **must** also declare an exact version of the primary package as a dependency, using the [] version notation (see [Package versioning](../concepts/package-versioning.md)). For example, `ContosoUtilities.de.1.0.0.nupkg` must declare a dependency on `ContosoUtilities.1.0.0.nupkg` using the `[1.0.0]` notation. The satellite package can, of course, have a different version number than the primary package. The satellite package's structure must then include the resource assembly and XML IntelliSense file in a subfolder that matches `{language}` in the package filename: - lib - └───net40 - └───de - ContosoUtilities.resources.dll - ContosoUtilities.xml +``` +lib +└───net40 + └───de + ContosoUtilities.resources.dll + ContosoUtilities.xml +``` **Note**: unless specific subcultures such as `ja-JP` are necessary, always use the higher level language identifier, like `ja`. @@ -114,11 +120,11 @@ When all of these conventions are met, NuGet will recognize the package as a sat You would create additional satellite assemblies in the same way for each supported language. For an example, examine the set of ASP.NET MVC packages: -- [Microsoft.AspNet.Mvc](http://nuget.org/packages/Microsoft.AspNet.Mvc) (English primary) -- [Microsoft.AspNet.Mvc.de](http://nuget.org/packages/Microsoft.AspNet.Mvc.de) (German) -- [Microsoft.AspNet.Mvc.ja](http://nuget.org/packages/Microsoft.AspNet.Mvc.ja) (Japanese) -- [Microsoft.AspNet.Mvc.zh-Hans](http://nuget.org/packages/Microsoft.AspNet.Mvc.zh-Hans) (Chinese (Simplified)) -- [Microsoft.AspNet.Mvc.zh-Hant](http://nuget.org/packages/Microsoft.AspNet.Mvc.zh-Hant) (Chinese (Traditional)) +- [Microsoft.AspNet.Mvc](https://nuget.org/packages/Microsoft.AspNet.Mvc) (English primary) +- [Microsoft.AspNet.Mvc.de](https://nuget.org/packages/Microsoft.AspNet.Mvc.de) (German) +- [Microsoft.AspNet.Mvc.ja](https://nuget.org/packages/Microsoft.AspNet.Mvc.ja) (Japanese) +- [Microsoft.AspNet.Mvc.zh-Hans](https://nuget.org/packages/Microsoft.AspNet.Mvc.zh-Hans) (Chinese (Simplified)) +- [Microsoft.AspNet.Mvc.zh-Hant](https://nuget.org/packages/Microsoft.AspNet.Mvc.zh-Hant) (Chinese (Traditional)) ### Summary of required conventions @@ -133,7 +139,7 @@ You would create additional satellite assemblies in the same way for each suppor Using satellite packages has a few benefits: 1. **Package size**: The overall footprint of the primary package is minimized, and consumers only incur the costs of each language they want to use. -1. **Separate metadata**: Each satellite package has its own `.nuspec` file and thus its own localized metadata because. This can allow some consumers to find packages more easily by searching nuget.org with localized terms. +1. **Separate metadata**: Each satellite package has its own `.nuspec` file and thus its own localized metadata. This can allow some consumers to find packages more easily by searching nuget.org with localized terms. 1. **Decoupled releases**: Satellite assemblies can be released over time, rather than all at once, allowing you to spread out your localization efforts. However, satellite packages have their own set of disadvantages: diff --git a/docs/create-packages/Creating-a-Package.md b/docs/create-packages/Creating-a-Package.md index d29316380..c894ade4a 100644 --- a/docs/create-packages/Creating-a-Package.md +++ b/docs/create-packages/Creating-a-Package.md @@ -1,9 +1,9 @@ --- title: Create a NuGet package using nuget.exe CLI -description: A detailed guide to the process of designing and creating a NuGet package, including key decision points like files and versioning. -author: karann-msft -ms.author: karann -ms.date: 07/09/2019 +description: A detailed guide on designing and creating a NuGet package, including files and versioning. +author: JonDouglas +ms.author: jodou +ms.date: 03/03/2025 ms.topic: conceptual --- @@ -15,7 +15,7 @@ No matter what your package does or what code it contains, you use one of the CL - For .NET Core and .NET Standard projects that use the [SDK-style format](../resources/check-project-format.md), and any other SDK-style projects, see [Create a NuGet package using the dotnet CLI](creating-a-package-dotnet-cli.md). -- For projects migrated from `packages.config` to [PackageReference](../consume-packages/package-references-in-project-files.md), use [msbuild -t:pack](../reference/migrate-packages-config-to-package-reference.md#create-a-package-after-migration). +- For projects migrated from `packages.config` to [PackageReference](../consume-packages/package-references-in-project-files.md), use [msbuild -t:pack](../consume-packages/migrate-packages-config-to-package-reference.md#create-a-package-after-migration). Technically speaking, a NuGet package is just a ZIP file that's been renamed with the `.nupkg` extension and whose contents match certain conventions. This topic describes the detailed process of creating a package that meets those conventions. @@ -63,8 +63,8 @@ Common optional properties: - A short description for the [Package Manager UI in Visual Studio](../consume-packages/install-use-packages-visual-studio.md) - A locale ID - Project URL -- License as an expression or file (`licenseUrl` is being deprecated, use the [`license` nuspec metadata element](../reference/nuspec.md#license)) -- An icon URL +- License as an expression or file (`licenseUrl` is deprecated, use [`license` nuspec metadata element](../reference/nuspec.md#license) instead) +- An icon file (`iconUrl` is deprecated use [`icon` nuspec metadata element](../reference/nuspec.md#icon) instead) - Lists of dependencies and references - Tags that assist in gallery searches @@ -72,13 +72,13 @@ The following is a typical (but fictitious) `.nuspec` file, with comments descri ```xml - + - + Contoso.Utility.UsefulStuff - - 1.8.3-beta + + 1.8.3 Dejana Tesic, Rajeev Dey @@ -96,8 +96,8 @@ The following is a typical (but fictitious) `.nuspec` file, with comments descri Apache-2.0 - - http://github.com/contoso/UsefulStuff/nuget_icon.png + + icon.png + ``` -For details on declaring dependencies and specifying version numbers, see [Package versioning](../reference/package-versioning.md). It is also possible to surface assets from dependencies directly in the package by using the `include` and `exclude` attributes on the `dependency` element. See [.nuspec Reference - Dependencies](../reference/nuspec.md#dependencies). +For details on declaring dependencies and specifying version numbers, see [packages.config](../reference/packages-config.md) and [Package versioning](../concepts/package-versioning.md). It is also possible to surface assets from dependencies directly in the package by using the `include` and `exclude` attributes on the `dependency` element. See [.nuspec Reference - Dependencies](../reference/nuspec.md#dependencies). Because the manifest is included in the package created from it, you can find any number of additional examples by examining existing packages. A good source is the *global-packages* folder on your computer, the location of which is returned by the following command: @@ -179,7 +180,9 @@ The folder conventions are as follows: | ref/{tfm} | Assembly (`.dll`), and symbol (`.pdb`) files for the given Target Framework Moniker (TFM) | Assemblies are added as references only for compile time; So nothing will be copied into project bin folder. | | runtimes | Architecture-specific assembly (`.dll`), symbol (`.pdb`), and native resource (`.pri`) files | Assemblies are added as references only for runtime; other files are copied into project folders. There should always be a corresponding (TFM) `AnyCPU` specific assembly under `/ref/{tfm}` folder to provide corresponding compile time assembly. See [Supporting multiple target frameworks](supporting-multiple-target-frameworks.md). | | content | Arbitrary files | Contents are copied to the project root. Think of the **content** folder as the root of the target application that ultimately consumes the package. To have the package add an image in the application's */images* folder, place it in the package's *content/images* folder. | -| build | MSBuild `.targets` and `.props` files | Automatically inserted into the project file or `project.lock.json` (NuGet 3.x+). | +| build | *(3.x+)* MSBuild `.targets` and `.props` files | Automatically inserted into the project. | +| buildMultiTargeting | *(4.0+)* MSBuild `.targets` and `.props` files for cross-framework targeting | Automatically inserted into the project. | +| buildTransitive | *(5.0+)* MSBuild `.targets` and `.props` files that flow transitively to any consuming project. See the [feature](https://github.com/NuGet/Home/wiki/Allow-package--authors-to-define-build-assets-transitive-behavior) page. | Automatically inserted into the project. | | tools | Powershell scripts and programs accessible from the Package Manager Console | The `tools` folder is added to the `PATH` environment variable for the Package Manager Console only (Specifically, *not* to the `PATH` as set for MSBuild when building the project). | Because your folder structure can contain any number of assemblies for any number of target frameworks, this method is necessary when creating packages that support multiple frameworks. @@ -213,6 +216,13 @@ nuget spec The resulting `.nuspec` file contains *tokens* that are replaced at packaging time with values from the project, including references to any other packages that have already been installed. +If you have package dependencies to include in the *.nuspec*, instead use `nuget pack`, and get the *.nuspec* file from within the generated *.nupkg* file. For example, use the following command. + +```cli +# Use in a folder containing a project file .csproj or .vbproj +nuget pack myproject.csproj +``` + A token is delimited by `$` symbols on both sides of the project property. For example, the `` value in a manifest generated in this way typically appears as follows: ```xml @@ -258,13 +268,13 @@ The package identifier (`` element) and the version number (`` elem **Best practices for the package version:** - In general, set the version of the package to match the library, though this is not strictly required. This is a simple matter when you limit a package to a single assembly, as described earlier in [Deciding which assemblies to package](#decide-which-assemblies-to-package). Overall, remember that NuGet itself deals with package versions when resolving dependencies, not assembly versions. -- When using a non-standard version scheme, be sure to consider the NuGet versioning rules as explained in [Package versioning](../reference/package-versioning.md). +- When using a non-standard version scheme, be sure to consider the NuGet versioning rules as explained in [Package versioning](../concepts/package-versioning.md). > The following series of brief blog posts are also helpful to understand versioning: > -> - [Part 1: Taking on DLL Hell](http://blog.davidebbo.com/2011/01/nuget-versioning-part-1-taking-on-dll.html) -> - [Part 2: The core algorithm](http://blog.davidebbo.com/2011/01/nuget-versioning-part-2-core-algorithm.html) -> - [Part 3: Unification via Binding Redirects](http://blog.davidebbo.com/2011/01/nuget-versioning-part-3-unification-via.html) +> - [Part 1: Taking on DLL Hell](https://blog.davidebbo.com/2011/01/nuget-versioning-part-1-taking-on-dll.html) +> - [Part 2: The core algorithm](https://blog.davidebbo.com/2011/01/nuget-versioning-part-2-core-algorithm.html) +> - [Part 3: Unification via Binding Redirects](https://blog.davidebbo.com/2011/01/nuget-versioning-part-3-unification-via.html) ## Add a readme and other files @@ -272,7 +282,7 @@ To directly specify files to include in the package, use the `` node in t ```xml - + @@ -298,17 +308,10 @@ When you include a file named `readme.txt` in the package root, Visual Studio di ## Include MSBuild props and targets in a package -In some cases, you might want to add custom build targets or properties in projects that consume your package, such as running a custom tool or process during build. You do this by placing files in the form `.targets` or `.props` (such as `Contoso.Utility.UsefulStuff.targets`) within the `\build` folder of the project. +In some cases, you might want to add custom build targets or properties in projects that consume your package, such as running a custom tool or process during build. +You can learn more about [MSBuild props and targets in NuGet packages](..\concepts\MSBuild-props-and-targets.md) -Files in the root `\build` folder are considered suitable for all target frameworks. To provide framework-specific files, first place them within appropriate subfolders, such as the following: - - \build - \netstandard1.4 - \Contoso.Utility.UsefulStuff.props - \Contoso.Utility.UsefulStuff.targets - \net462 - \Contoso.Utility.UsefulStuff.props - \Contoso.Utility.UsefulStuff.targets +Create `.targets` or `.props` (such as `Contoso.Utility.UsefulStuff.targets`) within the build folders of the project. Then in the `.nuspec` file, be sure to refer to these files in the `` node: @@ -328,13 +331,7 @@ Then in the `.nuspec` file, be sure to refer to these files in the `` nod ``` -Including MSBuild props and targets in a package was [introduced with NuGet 2.5](../release-notes/NuGet-2.5.md#automatic-import-of-msbuild-targets-and-props-files), therefore it is recommended to add the `minClientVersion="2.5"` attribute to the `metadata` element, to indicate the minimum NuGet client version required to consume the package. - -When NuGet installs a package with `\build` files, it adds MSBuild `` elements in the project file pointing to the `.targets` and `.props` files. (`.props` is added at the top of the project file; `.targets` is added at the bottom.) A separate conditional MSBuild `` element is added for each target framework. - -MSBuild `.props` and `.targets` files for cross-framework targeting can be placed in the `\buildMultiTargeting` folder. During package installation, NuGet adds the corresponding `` elements to the project file with the condition, that the target framework is not set (the MSBuild property `$(TargetFramework)` must be empty). - -With NuGet 3.x, targets are not added to the project but are instead made available through the `project.lock.json`. +When packages are added to a project, NuGet will automatically include these props and targets. ## Run nuget pack to generate the .nupkg file @@ -409,7 +406,7 @@ Once you've created a package, which is a `.nupkg` file, you can publish it to t You might also want to extend the capabilities of your package or otherwise support other scenarios as described in the following topics: -- [Package versioning](../reference/package-versioning.md) +- [Package versioning](../concepts/package-versioning.md) - [Supporting multiple target frameworks](../create-packages/supporting-multiple-target-frameworks.md) - [Transformations of source and configuration files](../create-packages/source-and-config-file-transformations.md) - [Localization](../create-packages/creating-localized-packages.md) @@ -419,5 +416,5 @@ You might also want to extend the capabilities of your package or otherwise supp Finally, there are additional package types to be aware of: -- [Native Packages](../create-packages/native-packages.md) -- [Symbol Packages](../create-packages/symbol-packages.md) +- [Native Packages](../guides/native-packages.md) +- [Symbol Packages](../create-packages/symbol-packages-snupkg.md) diff --git a/docs/create-packages/Overview-and-Workflow.md b/docs/create-packages/Overview-and-Workflow.md index a35c8e31c..96984557b 100644 --- a/docs/create-packages/Overview-and-Workflow.md +++ b/docs/create-packages/Overview-and-Workflow.md @@ -1,8 +1,8 @@ --- title: Overview and workflow of creating NuGet packages description: An overview of the process of creating and publishing a NuGet package, with links to other specific parts of the process. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 07/26/2017 ms.topic: conceptual --- @@ -30,8 +30,8 @@ From there, you can consider a number of other options for your package: - [Pre-release Packages](../create-packages/prerelease-packages.md) demonstrates how to release alpha, beta, and rc packages to those customers who are interested. - [Source and Config File Transformations](../create-packages/source-and-config-file-transformations.md) describes how you can do both one-way token replacements in files that are added to a project, and modify `web.config` and `app.config` with settings that are also backed out when the package is uninstalled. - [Symbol Packages](../create-packages/symbol-packages-snupkg.md) offers guidance for supplying symbols for your library that allow consumers to step into your code while debugging. -- [Package versioning](../reference/package-versioning.md) discusses how to identify the exact versions that you allow for your dependencies (other packages that you consume from your package). -- [Native Packages](../create-packages/native-packages.md) describes the process for creating a package for C++ consumers. +- [Package versioning](../concepts/package-versioning.md) discusses how to identify the exact versions that you allow for your dependencies (other packages that you consume from your package). +- [Native Packages](../guides/native-packages.md) describes the process for creating a package for C++ consumers. - [Signing Packages](../create-packages/sign-a-package.md) describes the process for adding a digital signature to a package. When you're then ready to publish a package to nuget.org, follow the simple process in [Publish a package](../nuget-org/publish-a-package.md). diff --git a/docs/create-packages/Package-authoring-best-practices.md b/docs/create-packages/Package-authoring-best-practices.md new file mode 100644 index 000000000..9d45b8bc1 --- /dev/null +++ b/docs/create-packages/Package-authoring-best-practices.md @@ -0,0 +1,180 @@ +--- +title: Package authoring best practices +description: A general guide of best practices for creating high quality NuGet packages. +author: nkolev92 +ms.author: nikolev +ms.date: 11/15/2021 +ms.topic: conceptual +--- + +# Package authoring best practices + +This guidance is intended to give NuGet package authors a lightweight reference to create and publish high-quality packages. It will primarily focus on package-specific best practices such as metadata and packing. For more in-depth suggestions for building high quality libraries, see the .NET [Open-source library guidance](/dotnet/standard/library-guidance/). + +## Types of recommendations + +Each article presents four types of recommendations: **Do**, **Consider**, **Avoid**, and **Do not**. The type of recommendation indicates how closely it should be followed. + +You should almost always follow a **Do** recommendation. For example: + +✔️ DO include a short description for your package that describes what it's for. + +On the other hand, **Consider** recommendations should generally be followed, but there are legitimate exceptions to the rule: + +✔️ CONSIDER choosing a NuGet package name with a prefix that meets NuGet's prefix reservation [criteria](../nuget-org/id-prefix-reservation.md). + +**Avoid** recommendations mention things that are generally not a good idea, but breaking the rule sometimes makes sense: + +❌ AVOID NuGet package references that demand an exact version. + +And finally, **Do not** recommendations indicate something you should almost never do: + +❌ DO NOT use the `LicenseUrl` metadata property. + +## Create a NuGet package + +The latest recommended way to to create a NuGet package is from an [SDK-style project](../resources/check-project-format.md). SDK-style project properties, including [target framework](/dotnet/standard/frameworks) and [package metadata](#package-metadata), are defined in the [project file](/visualstudio/ide/solutions-and-projects-in-visual-studio#project-file). + +Create a package from your SDK-style project by defining the required properties and packing in [Visual Studio](../quickstart/create-and-publish-a-package-using-visual-studio.md?tabs=netcore-cli) or the [dotnet CLI](../quickstart/create-and-publish-a-package-using-the-dotnet-cli.md). + +✔️ DO create an SDK-style project and create (pack) your package using Visual Studio or the dotnet CLI. + +For more detailed guidance regarding package creation including necessary client tools, project file example, and commands, see [Create a NuGet package using the dotnet CLI](./creating-a-package-dotnet-cli.md). + +To help decide which .NET frameworks to target, see our [latest guidance for cross-platform targeting](/dotnet/standard/library-guidance/cross-platform-targeting). + +## Package metadata + +Metadata is a foundational component of any NuGet package. The quality of your metadata can vastly influence the discoverability, usability, and trustworthiness of your package. + +In Visual Studio, the recommended way to specify package metadata is to go Project > [Project Name] Properties > Package. + +Package metadata elements can also be [specified directly in the project file](./creating-a-package-msbuild.md#set-properties). + +Below is a table mapping and describing available package metadata elements: + +| Visual Studio property name | [Project file/ MSBuild property name](/dotnet/core/tools/csproj#packagereleasenotes) | [Nuspec property name](/nuget/reference/nuspec#general-form-and-schema) | Description | +|----------------------------------------------- |----------------------------------------------------------------------------------------------------------------------------------------- |--------------------------------------------------------------------------------------------------- |------------------------------------------------------------------------------------------------------------------- | +| [`Package id`](#package-id) | [`PackageId`](/nuget/reference/msbuild-targets#pack-target) | [`id`](/nuget/reference/nuspec#id) | The package name or identifier. | +| [`Package version`](#package-version) | [`PackageVersion`](/nuget/reference/msbuild-targets#pack-target) | [`version`](/nuget/reference/nuspec#version) | NuGet package version. | +| [`Authors`](#authors) | [`Authors`](/nuget/reference/msbuild-targets#pack-target) | [`authors`](/nuget/reference/nuspec#authors) | A comma-separated list of package authors, often using the individual's or an organization's "pretty name." | +| [`Description`](#description) | [`Description`](/nuget/reference/msbuild-targets#pack-target) | [`description`](/nuget/reference/nuspec#description) | A description of the package. | +| [`Copyright`](#copyright) | [`Copyright`](/nuget/reference/msbuild-targets#pack-target) | [`copyright`](/nuget/reference/nuspec#copyright) | Copyright details for the package. | +| [`Project URL`](#project-url) | [`PackageProjectUrl`](/nuget/reference/msbuild-targets#pack-target) | [`projectUrl`](/nuget/reference/nuspec#projecturl) | A URL for the project homepage. | +| [`Icon File`](#icon) | [`PackageIcon`](/nuget/reference/msbuild-targets#packing-an-icon-image-file) | [`icon`](/nuget/reference/nuspec#icon) | Path to the package icon image file. | +| [`README`](#readme) | [`PackageReadmeFile`](/nuget/reference/msbuild-targets#packagereadmefile) | [`readme`](/nuget/reference/nuspec#readme) | Path to the package README markdown file. | +| [`Repository URL`](#repository-type-and-url) | [`RepositoryUrl`](/nuget/reference/msbuild-targets#pack-target) | [`repository url`](/nuget/reference/nuspec#repository) | URL to the repository from which the package was built. | +| [`Repository type`](#repository-type-and-url) | [`RepositoryType`](/nuget/reference/msbuild-targets#pack-target) | [`repository type`](/nuget/reference/nuspec#repository) | Type of repository the repository URL is pointing to (i.e. "git"). | +| [`Tags`](#tags) | [`PackageTags`](/nuget/reference/msbuild-targets#pack-target) | [`tags`](/nuget/reference/nuspec#tags) | A space-delimited list of tags and keywords that describe the package. Tags are used when searching for packages. | +| [`Release notes`](#release-notes) | [`PackageReleaseNotes`](/nuget/reference/msbuild-targets#pack-target) | [`releaseNotes`](/nuget/reference/nuspec#releasenotes) | A description of the changes made in this release of the package. | +| [`Licensing - Expression`](#licensing) | [`PackageLicenseExpression`](/nuget/reference/msbuild-targets#packing-a-license-expression-or-a-license-file) | [`license type="expression"`](/nuget/reference/nuspec#license) | An SPDX license expression. | +| [`Licensing - File`](#licensing) | [`PackageLicenseFile`](/nuget/reference/msbuild-targets#packing-a-license-expression-or-a-license-file) | [`license type="file"`](/nuget/reference/nuspec#license) | Path to a custom license file. | +### Package ID + +If you're publishing a completely new package: + +✔️ DO choose a package ID that is unique and clearly differentiated from existing packages on NuGet.org. +> You can check if a package ID is unique and differentiable by searching for the ID on NuGet.org or checking if the following link exists: https://www.nuget.org/packages/. + +✔️ CONSIDER choosing a NuGet package name with a prefix that meets NuGet's [prefix reservation criteria](../nuget-org/id-prefix-reservation.md#id-prefix-reservation-criteria). +> Reserving the prefix ID for your package will let you get the verified check mark: +> ![image](media/Verified-check-mark.png) +> +> Check out the [Package ID prefix reservation docs](../nuget-org/id-prefix-reservation.md) to learn more. + +### Package Version + +✔️ CONSIDER using [SemVer](https://semver.org/) to version your NuGet package. +> Essentially, this means using the Major.Minor.Patch[-prerelease] format. + +✔️ DO publish a package as a [pre-release package](./prerelease-packages.md) if it is non-stable or a preview. + +See the [.NET library versioning guide](/dotnet/standard/library-guidance/versioning) for more advanced guidance. + +### Authors + +✔️ DO use the author field for your or your organization's "pretty name." +> For example, if my NuGet.org username is "jdoe" then using "Jane Doe" for the author field may help consumers recognize me as an author. If my organization's NuGet.org username is "ContosoToolkit" then using "Contoso Corporation" may be more recognizable and inspire more consumer trust. + +### Description + +✔️ DO include a short description (up to 4000 characters) to describe your package. +> Package descriptions are one of the most prominent fields surfaced in NuGet search and will likely be the first thing potential consumers looks at to determine if a package is right for them. + +### Copyright + +✔️ DO add a copyright notice to your package with "Copyright (c) ." +> A copyright notice essentially indicates that your work cannot be copied without your permission. Including a copyright notice in your package is easy and won't do any harm! + +Example: Copyright (c) Contoso 2020 + +### Project URL + +✔️ DO include a link to an associated project, repository, or company website. +> Your project site should have everything users need to know about your package and will likely be where users look for documentation. + +### Icon + +✔️ CONSIDER [including an icon with your package](../reference/msbuild-targets.md#packing-an-icon-image-file) to help visually differentiate it. It's a relatively small addition that can improve perception of package quality. +> Icons can be specific to individual packages or be a brand logo. + +✔️ DO use an image that is 128x128 and has a transparent background (PNG) for best viewing results. +> NuGet will automatically scale your image to the client it is being displayed on. + +❌ DO NOT use the deprecated `IconUrl` metadata property. + +### README +✔️ DO [add a README markdown file](/nuget/reference/msbuild-targets#packagereadmefile) that provides an overview of what your package does and how to get started. +> A package README will significantly improve the quality perception of your package as well as new user onboarding. Also consider [previewing your README](../nuget-org/package-readme-on-nuget-org.md#preview-your-readme) before you upload it! See [how to include a README file in your NuGet package](/nuget/reference/msbuild-targets#packagereadmefile) for more details. + +### Repository Type and URL + +✔️ CONSIDER setting up [Source Link](/dotnet/standard/library-guidance/sourcelink) to automatically add source control metadata to your NuGet package and make your library easier to debug. +> Source Link automatically adds `Repository URL` and `Repository Type` to the package metadata. It also adds the specific commit associated with your package version. + +### Tags + +✔️ DO include several tags with key terms related to your package to enhance discoverability. +> Tags are taken into account in NuGet.org's search algorithm and are especially helpful for terms that are not in the Package ID but are relevant. + +For example, if I published a package to log strings to the console, I would include: "logging, log, console, string, output" + +### Release notes + +✔️ DO include release notes with each update describing what changes were made. +> While there is no specific format required for release notes, we recommend including: +> +> 1. Breaking changes +> 2. New features +> 3. Bug fixes +> +> If you already track release notes or a changelog in your repo, you can also include a link to the relevant file. + +### Licensing + +✔️ DO [include a license expression or license file in your package](../reference/msbuild-targets.md#packing-a-license-expression-or-a-license-file). +> [!IMPORTANT] +> A project without a license defaults to [exclusive copyright](https://choosealicense.com/no-permission/), meaning that you have not granted anyone permission to use your project. + +❌ DO NOT use the deprecated `LicenseUrl` metadata property. +> This presents legal ambiguity as license changes at the URL will retroactively change the displayed license for previous package versions. + +#### If your package is [open source](https://opensource.org/osd) + +✔️ DO [choose an open source license](https://choosealicense.com/) to make your package open source. +> *"Open source licenses are licenses that comply with the Open Source Definition — in brief, they allow software to be freely used, modified, and shared."* - Open Source Initiative. To learn more about open source software and the Open Source Initiative, check out https://opensource.org/. + +✔️ CONSIDER [including a license expression in your package](../reference/msbuild-targets.md#packing-a-license-expression-or-a-license-file). +> License expressions are surfaced the most clearly and make it more obvious to consumers if they can use your package or if the license has changed. +> [!Note] +> NuGet.org only accepts license expressions for licenses that are approved by the Open Source Initiative or the Free Software Foundation. + +#### If your package is not open source + +✔️ DO [include a license file in your package](../reference/msbuild-targets.md#packing-a-license-expression-or-a-license-file). +> Any license file (.txt or .md) can be added to your package, including non-standard licenses. + +## Related topics + +- [Create and publish a package (dotnet CLI)](../quickstart/create-and-publish-a-package-using-the-dotnet-cli.md) +- [Create and publish a package (Visual Studio)](../quickstart/create-and-publish-a-package-using-visual-studio.md?tabs=netcore-cli) diff --git a/docs/create-packages/Prerelease-Packages.md b/docs/create-packages/Prerelease-Packages.md index 2434bc05a..b8a08be74 100644 --- a/docs/create-packages/Prerelease-Packages.md +++ b/docs/create-packages/Prerelease-Packages.md @@ -1,8 +1,8 @@ --- title: Pre-release versions in NuGet packages description: Guidance for building pre-release packages -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 08/14/2017 ms.topic: conceptual --- @@ -15,11 +15,11 @@ Whenever you release an updated package with a new version number, NuGet conside A stable release is one that's considered reliable enough to be used in production. The latest stable release is also the one that will be installed as a package update or during package restore (subject to constraints as described in [Reinstalling and updating packages](../consume-packages/reinstalling-and-updating-packages.md)). -To support the software release lifecycle, NuGet 1.6 and later allows for the distribution of pre-release packages, where the version number includes a semantic versioning suffix such as `-alpha`, `-beta`, or `-rc`. For more information, see [Package versioning](../reference/package-versioning.md#pre-release-versions). +To support the software release lifecycle, NuGet 1.6 and later allows for the distribution of pre-release packages, where the version number includes a semantic versioning suffix such as `-alpha`, `-beta`, or `-rc`. For more information, see [Package versioning](../concepts/package-versioning.md#pre-release-versions). You can specify such versions using one of the following ways: -- **If your project uses [`PackageReference`](../consume-packages/package-references-in-project-files.md)**: include the semantic version suffix in the `.csproj` file's [`PackageVersion`](/dotnet/core/tools/csproj.md#packageversion) element: +- **If your project uses [`PackageReference`](../consume-packages/package-references-in-project-files.md)**: include the semantic version suffix in the `.csproj` file's [`PackageVersion`](/dotnet/core/tools/csproj#packageversion) element: ```xml @@ -33,7 +33,7 @@ You can specify such versions using one of the following ways: 1.0.1-alpha ``` -When you're ready to release a stable version, just remove the suffix and the package takes precedence over any pre-release versions. Again, see [Package versioning](../reference/package-versioning.md#pre-release-versions). +When you're ready to release a stable version, just remove the suffix and the package takes precedence over any pre-release versions. Again, see [Package versioning](../concepts/package-versioning.md#pre-release-versions). ## Installing and updating pre-release packages @@ -51,35 +51,5 @@ By default, NuGet does not include pre-release versions when working with packag ## Semantic versioning -The [Semantic Versioning or SemVer convention](http://semver.org/spec/v1.0.0.html) describes how to utilize strings in version numbers to convey the meaning of the underlying code. - -In this convention, each version has three parts, `Major.Minor.Patch`, with the following meaning: - -- `Major`: Breaking changes -- `Minor`: New features, but backwards compatible -- `Patch`: Backwards compatible bug fixes only - -Pre-release versions are then denoted by appending a hyphen and a string after the patch number. Technically speaking, you can use *any* string after the hyphen and NuGet will treat the package as pre-release. NuGet then displays the full version number in the applicable UI, leaving consumers to interpret the meaning for themselves. - -With this in mind, it's generally good to follow recognized naming conventions such as the following: - -- `-alpha`: Alpha release, typically used for work-in-progress and experimentation -- `-beta`: Beta release, typically one that is feature complete for the next planned release, but may contain known bugs. -- `-rc`: Release candidate, typically a release that's potentially final (stable) unless significant bugs emerge. - -> [!Note] -> NuGet 4.3.0+ supports [Semantic Versioning v2.0.0](http://semver.org/spec/v2.0.0.html), which supports pre-release numbers with dot notation, as in `1.0.1-build.23`. Dot notation is not supported with NuGet versions before 4.3.0. In earlier versions of NuGet, you could use a form like `1.0.1-build23` but this was always considered a pre-release version. - -Whatever suffixes you use, however, NuGet will give them precedence in reverse alphabetical order: - - 1.0.1 - 1.0.1-zzz - 1.0.1-rc - 1.0.1-open - 1.0.1-beta12 - 1.0.1-beta05 - 1.0.1-beta - 1.0.1-alpha2 - 1.0.1-alpha - -As shown, the version without any suffix will always take precedence over pre-release versions. Note also that if you use numerical suffixes with pre-release tags that might use double-digit numbers (or more), use leading zeroes as in beta01 and beta05 to ensure that they sort correctly when the numbers get larger. +The [Semantic Versioning or SemVer convention](https://semver.org/spec/v1.0.0.html) describes how to utilize strings in version numbers to convey the meaning of the underlying code. +[Learn more](../concepts/Package-Versioning.md) about the package versioning basics. diff --git a/docs/create-packages/Select-assemblies-referenced-by-projects.md b/docs/create-packages/Select-assemblies-referenced-by-projects.md index 66f46f884..c984846e1 100644 --- a/docs/create-packages/Select-assemblies-referenced-by-projects.md +++ b/docs/create-packages/Select-assemblies-referenced-by-projects.md @@ -9,22 +9,57 @@ ms.topic: conceptual # Select Assemblies Referenced By Projects -Explicit assembly references allows a subset of assemblies to be used for IntelliSense and compiling, while all assemblies are available at run-time. `PackageReference` and `packages.config` work differently, and as a result package authors need to take care to create the package to be compatible with both project types. +Assemblies are used in two different ways during a build. The first is for compile, which allows the package consumer's code to compile against APIs in the assembly, and for Intellisense to give suggestions. The second is runtime, where the assembly is copied to the `bin` directory and is used during program execution. Some package authors would like only their own assemblies (or a subset of their assemblies) available to their package consumers at compile time, but need to provide all their dependencies for runtime. This document looks at ways to achieve this outcome. -> [!Note] -> Explicit assembly references are related to .NET assemblies. It is not a method to distribute native assemblies that are P/Invoked by a managed assembly. +## Recommended: One assembly per package -## `PackageReference` support +Our recommendation is to have one package per assembly, and package dependencies to other assemblies. When NuGet restores a project, it does asset selection and supports including, excluding, and making private different asset classes. In order to prevent your package's dependencies from becoming compile time assets for anyone using your package, you can make `compile` assets private. In the generated package, that will cause `compile` to be excluded from the dependency. Note that the default private assets when none is supplied is `contentfiles;build;analyzers`. Therefore, you should use `PrivateAssets="compile;contentfiles;build;analyzers"` in your `PackageReference` or `ProjectReference`. -When a project uses a package with `PackageReference` and the package contains a `ref\\` directory, NuGet will classify those assembles as compile-time assets, while the `lib\\` assemblies are classified as runtime assets. Assemblies in `ref\\` are not used at runtime. This means it is necessary for any assembly in `ref\\` to have a matching assembly in either `lib\\` or a relevant `runtime\` directory, otherwise runtime errors will likely occur. Since assemblies in `ref\\` are not used at runtime, they may be [metadata-only assemblies](https://github.com/dotnet/roslyn/blob/master/docs/features/refout.md) to reduce package size. +```xml + + + + +``` -> [!Important] -> If a package contains the nuspec `` element (used by `packages.config`, see below) and does not contain assemblies in `ref\\`, NuGet will advertise the assemblies listed in the nuspec `` element as both the compile and runtime assets. This means there will be runtime exceptions when the referenced assemblies need to load any other assembly in the `lib\\` directory. +If you are creating a package from a custom `nuspec` file, rather than letting NuGet auto-generate one for you, your `nuspec` should use the `exclude` XML attribute . -> [!Note] -> If the package contains a `runtime\` directory, NuGet may not use the assets in the `lib\` directory. +```xml + + + + + + +``` + +There are three reasons why this is the recommended solution. + +Firstly, useful assemblies often get referenced by new assemblies/packages. While a utility assembly might be intended to only be used by a single package today, making it tempting to ship both assemblies in a single package, if a second package wants to use the "private" utility assembly in the future, either the utility assembly needs to be moved into a new package and the old package needs to be updated to declare it as a dependency, or the utility package needs to ship in both the existing and the new package. If the assembly ships in two different packages, and a project references both packages, if there are different versions of the utility assembly in the two packages, NuGet will be unable to assist in version management. + +Secondly, there may be times that the developers using your package want to also use APIs from your dependencies. For example, consider the package [Microsoft.ServiceHub.Client version 3.0.3078](https://www.nuget.org/packages/Microsoft.ServiceHub.Client/3.0.3078). If you download the package and check the `nuspec` file, you can see that it lists two packages starting with `Microsoft.VisualStudio.` as dependencies, meaning it needs them at runtime, but it also excludes their compile assets. This means that projects using Microsoft.ServiceHub.Client will not have the Visual Studio APIs available in IntelliSense or if they build the project, unless the project explicit installs those packages. And this is the advantage that a package dependency with an exclude asset has. Projects using your package, if they want to use your dependencies as well, they can add a reference to the package to make the APIs available to themselves. + +Finally, some package authors have been confused in the past about NuGet's assembly selection for packages supporting more than one target framework when their package also contains multiple assemblies. If your main assembly supports different target frameworks to your utility assembly, it may not be obvious which `lib/` directories to put all of the assemblies into. By separating each package by assembly name, it's more intuitive which `lib/` folders each assembly should go into. Note, this does not mean having `Package1.net48` and `Package1.net6.0` packages. It means having `lib/net48/Package1.dll` and `lib/net6.0/Package6.0` in `Package1`, and `lib/netstandard2.0/Package2.dll` and `lib/net5.0/Package2.dll` in `Package2`. When Nuget restores a project, Nuget will independently do asset selection for the two packages. + +Also note that dependency include/exclude assets is only used by projects using PackageReference. Any project installing your package using `packages.config` will install your dependencies and have its APIs available as well. `packages.config` is only supported by Visual Studio's older .NET Framework project templates. SDK style projects, even those targeting .NET Framework, do not support `packages.config`, and therefore do support dependency include/exclude assets. -## `packages.config` support +## Not recommended: Multiple assemblies in one package + +`PackageReference` and `packages.config` have different features available. Whether you want to support your package consumers who use `PackageReference`, `packages.config`, or both, changes how you must author your package. + +NuGet's MSBuild Pack target does not support automatically including project references in the package. It will only list those referenced projects as package dependencies. There is [an issue on GitHub](https://github.com/NuGet/Home/issues/3891), where community members shared ways they achieved this outcome, which usually involves using `PackagePath` MSBuild item metadata to place files anywhere in the package, as described in [the docs on including content in a package](../reference/msbuild-targets.md#including-content-in-a-package), and using [`SuppressDependenciesWhenPacking` to avoid the project references becoming package dependencies](../reference/msbuild-targets.md#pack-target-inputs). There also exist community developed tools that can be used as an alternative to NuGet's official pack, which support this feature. + +### `PackageReference` support + +When a package consumer uses `PackageReference`, NuGet selects compile and runtime assets independently, as previously described. + +Compile assets prefer `ref//*.dll` (for example `ref/net6.0/*.dll`), but if that does not exist, then it will fall back to `lib//*.dll` (for example `lib/net6.0/*.dll`). + +Runtime assets prefer `runtimes//lib//*.dll` (for example (`runtimes/win11-x64/lib/net6.0/*.dll`)), but if that does not exist, then it will fall back to `lib//*.dll`. + +Since assemblies in `ref\\` are not used at runtime, they may be [metadata-only assemblies](https://github.com/dotnet/roslyn/blob/main/docs/features/refout.md) to reduce package size. + +### `packages.config` support Projects using `packages.config` to manage NuGet packages normally add references to all assemblies in the `lib\\` directory. The `ref\` directory was added to support `PackageReference` and therefore isn't considered when using `packages.config`. To explicitly set which assemblies are referenced for projects using `packages.config`, the package must use the [`` element in the nuspec file](../reference/nuspec.md#explicit-assembly-references). For example: @@ -36,10 +71,17 @@ Projects using `packages.config` to manage NuGet packages normally add reference ``` +The MSBuild pack targets don't support the `` element. See [the docs on packing using a .nuspec file](../reference/msbuild-targets.md#packing-using-a-nuspec-file) when using MSBuild pack. + > [!Note] -> `packages.config` project use a process called [ResolveAssemblyReference](https://github.com/Microsoft/msbuild/blob/master/documentation/wiki/ResolveAssemblyReference.md) to copy assemblies to the `bin\\` output directory. Your project's assembly is copied, then the build system looks at the assembly manifest for referenced assemblies, then copies those assemblies and recursively repeats for all assemblies. This means that if any of the assemblies in your `lib\\` directory are not listed in any other assembly's manifest as a dependency (if the assembly is loaded at runtime using `Assembly.Load`, MEF or another dependency injection framework), then it may not be copied to your project's `bin\\` output directory despite being in `bin\\`. +> `packages.config` project use a process called [ResolveAssemblyReference](https://github.com/Microsoft/msbuild/blob/main/documentation/wiki/ResolveAssemblyReference.md) to copy assemblies to the `bin\\` output directory. Your project's assembly is copied, then the build system looks at the assembly manifest for referenced assemblies, then copies those assemblies and recursively repeats for all assemblies. This means that if any of the assemblies loaded only by reflection (`Assembly.Load`, MEF or another dependency injection framework), then it may not be copied to your project's `bin\\` output directory despite being in `bin\\`. This also means that this only works for .NET assemblies, not for native code called with P/Invoke. + +### Supporting both `PackageReference` and `packages.config` + +> [!Important] +> If a package contains the nuspec `` element and does not contain assemblies in `ref\\`, NuGet will advertise the assemblies listed in the nuspec `` element as both the compile and runtime assets. This means there will be runtime exceptions when the referenced assemblies need to load any other assembly in the `lib\\` directory. Therefore, it is important to use both the nuspec `` for `packages.config` support, as well as duplicating assemblies in the `ref/` folder for `PackageReference` support. The `runtimes/` package folder does not need to be used, it was added to the above section for completeness. -## Example +#### Example My package will contain three assemblies, `MyLib.dll`, `MyHelpers.dll` and `MyUtilities.dll`, which are targeting the .NET Framework 4.7.2. `MyUtilities.dll` contains classes intended to be used only by the other two assemblies, so I don't want to make those classes available in IntelliSense or at compile time to projects using my package. My `nuspec` file needs to contain the following XML elements: @@ -52,7 +94,7 @@ My package will contain three assemblies, `MyLib.dll`, `MyHelpers.dll` and `MyUt ``` -and the files in the package will be: +I need to ensure my package contents are: ```text lib\net472\MyLib.dll diff --git a/docs/create-packages/Sign-a-Package.md b/docs/create-packages/Sign-a-Package.md index fa171b720..bcfb5fa83 100644 --- a/docs/create-packages/Sign-a-Package.md +++ b/docs/create-packages/Sign-a-Package.md @@ -6,15 +6,24 @@ ms.author: rmpablos ms.date: 03/06/2018 ms.topic: conceptual ms.reviewer: anangaur +ms.custom: sfi-image-nochange --- -# Signing NuGet Packages +# Sign a NuGet package -Signed packages allows for content integrity verification checks which provides protection against content tampering. The package signature also serves as the single source of truth about the actual origin of the package and bolsters package authenticity for the consumer. This guide assumes you have already [created a package](creating-a-package.md). +A signed package allows for content integrity verification checks, which provides protection against content tampering. The package signature also serves as the single source of truth about the actual origin of the package and bolsters package authenticity for the consumer. This guide assumes you have already [created a package](creating-a-package.md). ## Get a code signing certificate -Valid certificates may be obtained from a public certificate authority such as [Symantec](https://trustcenter.websecurity.symantec.com/process/trust/productOptions?productType=SoftwareValidationClass3), [DigiCert](https://www.digicert.com/code-signing/), [Go Daddy](https://www.godaddy.com/web-security/code-signing-certificate), [Global Sign](https://www.globalsign.com/en/code-signing-certificate/), [Comodo](https://www.comodo.com/e-commerce/code-signing/code-signing-certificate.php), [Certum](https://www.certum.eu/certum/cert,offer_en_open_source_cs.xml), etc. The complete list of certification authorities trusted by Windows can be obtained from [http://aka.ms/trustcertpartners](http://aka.ms/trustcertpartners). +Valid certificates can be obtained from a public certificate authority such as: + +- [Certum](https://www.certum.eu/certum/cert,offer_en_open_source_cs.xml) +- [Comodo](https://www.comodo.com/e-commerce/code-signing/code-signing-certificate.php) +- [DigiCert](https://www.digicert.com/code-signing/) +- [GlobalSign](https://www.globalsign.com/en/code-signing-certificate/) +- [SSL.com](https://www.ssl.com/certificates/code-signing/) + +The complete list of certification authorities trusted by Windows can also be obtained from [http://aka.ms/trustcertpartners](/security/trusted-root/participants-list). You can use self-issued certificates for testing purposes. However, packages signed using self-issued certificates are not accepted by NuGet.org. Learn more about [creating a test certificate](#create-a-test-certificate) @@ -24,14 +33,19 @@ You can use self-issued certificates for testing purposes. However, packages sig ![Certificate Export Wizard](../reference/media/CertificateExportWizard.png) -* You can also export the certificate using the [Export-Certificate PowerShell command](/powershell/module/pkiclient/export-certificate). +* You can also export the certificate using the [Export-Certificate PowerShell command](/powershell/module/pki/export-certificate). ## Sign the package -> [!note] -> Requires nuget.exe 4.6.0 or later +Sign the package using [dotnet nuget sign](/dotnet/core/tools/dotnet-nuget-sign) (requires .NET 6.0.100 SDK or later). -Sign the package using [nuget sign](../reference/cli-reference/cli-ref-sign.md): +```cli +dotnet nuget sign MyPackage.nupkg --certificate-path --timestamper +``` + +or + +Sign the package using [nuget sign](../reference/cli-reference/cli-ref-sign.md) (requires nuget.exe 4.6.0 or later): ```cli nuget sign MyPackage.nupkg -CertificatePath -Timestamper @@ -49,23 +63,24 @@ nuget sign MyPackage.nupkg -CertificatePath -Timestamper To publish a signed package, you must first register the certificate with NuGet.org. You need the certificate as a `.cer` file in a binary DER format. 1. [Sign in](https://www.nuget.org/users/account/LogOn?returnUrl=%2F) to NuGet.org. -1. Go to `Account settings` (or `Manage Organization` **>** `Edit Organziation` if you would like to register the certificate with an Organization account). +1. Go to `Account settings` (or `Manage Organization` **>** `Edit Organization` if you would like to register the certificate with an Organization account). 1. Expand the `Certificates` section and select `Register new`. 1. Browse and select the certficate file that was exported earlier. ![Registered Certificates](../reference/media/registered-certs.png) -**Note** -* One user can submit multiple certificates and the same certificate can be registered by multiple users. -* Once a user has a certificate registered, all future package submissions **must** be signed with one of the certificates. See [Manage signing requirements for your package on NuGet.org](#manage-signing-requirements-for-your-package-on-nugetorg) -* Users can also remove a registered certificate from the account. Once a certificate is removed, new packages signed with that certificate will fail at submission. Existing packages aren't affected. +> [!NOTE] +> +> * One user can submit multiple certificates and the same certificate can be registered by multiple users. +> * Once a user has a certificate registered, all future package submissions **must** be signed with one of the certificates. See [Manage signing requirements for your package on NuGet.org](#manage-signing-requirements-for-your-package-on-nugetorg) +> * Users can also remove a registered certificate from the account. Once a certificate is removed, new packages signed with that certificate will fail at submission. Existing packages aren't affected. ## Publish the package -You are now ready to publish the package to NuGet.org. See [Publishing packages](../nuget-org/Publish-a-package.md). +You're now ready to publish the package to NuGet.org. See [Publishing packages](../nuget-org/Publish-a-package.md). ## Create a test certificate -You can use self-issued certificates for testing purposes. To create a self-issued certificate, use the [New-SelfSignedCertificate PowerShell command](/powershell/module/pkiclient/new-selfsignedcertificate). +You can use self-issued certificates for testing purposes. To create a self-issued certificate, use the [New-SelfSignedCertificate PowerShell command](/powershell/module/pki/new-selfsignedcertificate). ```ps New-SelfSignedCertificate -Subject "CN=NuGet Test Developer, OU=Use for testing purposes ONLY" ` @@ -85,14 +100,15 @@ This command creates a testing certificate available in the current user's perso > NuGet.org does not accept packages signed with self-issued certificates. ## Manage signing requirements for your package on NuGet.org + 1. [Sign in](https://www.nuget.org/users/account/LogOn?returnUrl=%2F) to NuGet.org. 1. Go to `Manage Packages` ![Configure package signers](../reference/media/configure-package-signers.png) -* If you are the sole owner of a package, you are the required signer i.e. you can use any of the registered certificates to sign and publish your packages to NuGet.org. +* If you are the sole owner of a package, you are the required signer, that is, you can use any of the registered certificates to sign and publish your packages to NuGet.org. -* If a package has multiple owners, by default, "Any" owner's certificates can be used to sign the package. As a co-owner of the package, you can override "Any" with yourself or any other co-owner to be the required signer. If you make an owner who does not have any certificate registered, then unsigned packages will be allowed. +* If a package has multiple owners, by default, "Any" owner's certificates can be used to sign the package. As a co-owner of the package, you can override "Any" with yourself or any other co-owner to be the required signer. If you make an owner who does not have any certificate registered, then unsigned packages will be allowed. * Similarly, if the default "Any" option is selected for a package where one owner has a certificate registered and another owner does not have any certificate registered, then NuGet.org accepts either a signed package with a signature registered by one of its owners or an unsigned package (because one of the owners does not have any certificate registered). @@ -100,3 +116,4 @@ This command creates a testing certificate available in the current user's perso - [Manage package trust boundaries](../consume-packages/installing-signed-packages.md) - [Signed Packages Reference](../reference/Signed-Packages-Reference.md) +- [.NET signed package verification](/dotnet/core/tools/nuget-signed-package-verification) diff --git a/docs/create-packages/Source-and-Config-File-Transformations.md b/docs/create-packages/Source-and-Config-File-Transformations.md index ad1bb50a7..79402e54c 100644 --- a/docs/create-packages/Source-and-Config-File-Transformations.md +++ b/docs/create-packages/Source-and-Config-File-Transformations.md @@ -1,8 +1,8 @@ --- title: Source and config file transformations for NuGet packages description: Details on the ability for NuGet packages to transform source code and configuration (XML) files when installed. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 04/24/2017 ms.topic: conceptual ms.reviewer: anangaur @@ -10,9 +10,7 @@ ms.reviewer: anangaur # Transforming source code and configuration files -For projects using `packages.config`, NuGet supports the ability to make transformations to source code and configuration files at package install and uninstall times. Only Source code transformations are applied when a package is installed in a project using [PackageReference](../consume-packages/package-references-in-project-files.md). - -A **source code transformation** applies one-way token replacement to files in the package's `content` or `contentFiles` folder (`content` for customers using `packages.config` and `contentFiles` for `PackageReference`) when the package is installed, where tokens refer to Visual Studio [project properties](/dotnet/api/vslangproj.projectproperties?view=visualstudiosdk-2017&viewFallbackFrom=netframework-4.7). This allows you to insert a file into the project's namespace, or to customize code that would typically go into `global.asax` in an ASP.NET project. +A **source code transformation** applies one-way token replacement to files in the package's `content` or `contentFiles` folder (`content` for customers using `packages.config` and `contentFiles` for `PackageReference`) when the package is installed, where tokens refer to Visual Studio [project properties](/dotnet/api/vslangproj.projectproperties). This allows you to insert a file into the project's namespace, or to customize code that would typically go into `global.asax` in an ASP.NET project. A **config file transformation** allows you to modify files that already exist in a target project, such as `web.config` and `app.config`. For example, your package might need to add an item to the `modules` section in the config file. This transformation is done by including special files in the package that describe the sections to add to the configuration files. When a package is uninstalled, those same changes are then reversed, making this a two-way transformation. @@ -42,14 +40,14 @@ A **config file transformation** allows you to modify files that already exist i Upon installation, NuGet replaces `$rootnamespace$` with `Fabrikam` assuming the target project's whose root namespace is `Fabrikam`. -The `$rootnamespace$` token is the most commonly used project property; all others are listed in [project properties](/dotnet/api/vslangproj.projectproperties?view=visualstudiosdk-2017&viewFallbackFrom=netframework-4.7). Be mindful, of course, that some properties might be specific to the project type. +The `$rootnamespace$` token is the most commonly used project property; all others are listed in [project properties](/dotnet/api/vslangproj.projectproperties). Be mindful, of course, that some properties might be specific to the project type. ## Specifying config file transformations As described in the sections that follow, config file transformations can be done in two ways: - Include `app.config.transform` and `web.config.transform` files in your package's `content` folder, where the `.transform` extension tells NuGet that these files contain the XML to merge with existing config files when the package is installed. When a package is uninstalled, that same XML is removed. -- Include `app.config.install.xdt` and `web.config.install.xdt` files in your package's `content` folder, using [XDT syntax](https://msdn.microsoft.com/library/dd465326.aspx) to describe the desired changes. With this option you can also include a `.uninstall.xdt` file to reverse changes when the package is removed from a project. +- Include `app.config.install.xdt` and `web.config.install.xdt` files in your package's `content` folder, using [XDT syntax](/previous-versions/aspnet/dd465326(v=vs.110)) to describe the desired changes. With this option you can also include a `.uninstall.xdt` file to reverse changes when the package is removed from a project. > [!Note] > Transformations are not applied to `.config` files referenced as a link in Visual Studio. @@ -109,7 +107,10 @@ To see the effect of installing and uninstalling the package, create a new ASP.N ### XDT transforms -You can modify config files using [XDT syntax](https://msdn.microsoft.com/library/dd465326.aspx). You can also have NuGet replace tokens with [project properties](/dotnet/api/vslangproj.projectproperties?view=visualstudiosdk-2017&viewFallbackFrom=netframework-4.7) by including the property name within `$` delimiters (case-insensitive). +> [!Note] +> As mentioned in the [package compatibility issues section of the docs for migrating from `packages.config` to `PackageReference`](../consume-packages/migrate-packages-config-to-package-reference.md#package-compatibility-issues), XDT transformations as described below are only supported by `packages.config`. If you add the below files to your package, consumers using your package with `PackageReference` will not have the transformations applied (refer to [this sample](https://github.com/NuGet/Samples/tree/main/XDTransformExample) to make XDT transforms work with`PackageReference`). + +You can modify config files using [XDT syntax](/previous-versions/aspnet/dd465326(v=vs.110)). You can also have NuGet replace tokens with [project properties](/dotnet/api/vslangproj.projectproperties) by including the property name within `$` delimiters (case-insensitive). For example, the following `app.config.install.xdt` file will insert an `appSettings` element into `app.config` containing the `FullPath`, `FileName`, and `ActiveConfigurationSettings` values from the project: @@ -173,4 +174,4 @@ To remove only the `MyNuModule` element during package uninstall, the `web.confi -``` +``` \ No newline at end of file diff --git a/docs/create-packages/Supporting-Multiple-Target-Frameworks.md b/docs/create-packages/Supporting-Multiple-Target-Frameworks.md index c66f70957..91576a3c8 100644 --- a/docs/create-packages/Supporting-Multiple-Target-Frameworks.md +++ b/docs/create-packages/Supporting-Multiple-Target-Frameworks.md @@ -1,8 +1,8 @@ --- title: Multi-targeting for NuGet Packages description: Description of the various methods to target multiple .NET Framework versions from within a single NuGet package. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 07/15/2019 ms.topic: conceptual --- @@ -11,7 +11,7 @@ ms.topic: conceptual Many libraries target a specific version of the .NET Framework. For example, you might have one version of your library that's specific to UWP, and another version that takes advantage of features in .NET Framework 4.6. To accommodate this, NuGet supports putting multiple versions of the same library in a single package. -This article describes the layout of a NuGet package, regardless of how the package or assemblies are built (that is, the layout is the same whether using multiple non-SDK-style *.csproj* files and a custom *.nuspec* file, or a single multi-targetecd SDK-style *.csproj*). For an SDK-style project, NuGet [pack targets](../reference/msbuild-targets.md) knows how the package must be layed out and automates putting the assemblies in the correct lib folders and creating dependency groups for each target framework (TFM). For detailed instructions, see [Support multiple .NET Framework versions in your project file](multiple-target-frameworks-project-file.md). +This article describes the layout of a NuGet package, regardless of how the package or assemblies are built (that is, the layout is the same whether using multiple non-SDK-style *.csproj* files and a custom *.nuspec* file, or a single multi-targeted SDK-style *.csproj*). For an SDK-style project, NuGet [pack targets](../reference/msbuild-targets.md) knows how the package must be layed out and automates putting the assemblies in the correct lib folders and creating dependency groups for each target framework (TFM). For detailed instructions, see [Support multiple .NET Framework versions in your project file](multiple-target-frameworks-project-file.md). You must manually lay out the package as described in this article when using the convention-based working directory method described in [Creating a package](../create-packages/creating-a-package.md#from-a-convention-based-working-directory). For an SDK-style project, the automated method is recommended, but you may also choose to manually lay out the package as described in this article. @@ -19,7 +19,9 @@ You must manually lay out the package as described in this article when using th When building a package that contains only one version of a library or target multiple frameworks, you always make subfolders under `lib` using different case-sensitive framework names with the following convention: - lib\{framework name}[{version}] +``` +lib\{framework name}[{version}] +``` For a complete list of supported names, see the [Target Frameworks reference](../reference/target-frameworks.md#supported-frameworks). @@ -27,15 +29,17 @@ You should never have a version of the library that is not specific to a framewo For example, the following folder structure supports four versions of an assembly that are framework-specific: - \lib - \net46 - \MyAssembly.dll - \net461 - \MyAssembly.dll - \uap - \MyAssembly.dll - \netcore - \MyAssembly.dll +``` +\lib + \net46 + \MyAssembly.dll + \net461 + \MyAssembly.dll + \uap + \MyAssembly.dll + \netcore + \MyAssembly.dll +``` To easily include all these files when building the package, use a recursive `**` wildcard in the `` section of your `.nuspec`: @@ -49,24 +53,26 @@ To easily include all these files when building the package, use a recursive `** If you have architecture-specific assemblies, that is, separate assemblies that target ARM, x86, and x64, you must place them in a folder named `runtimes` within sub-folders named `{platform}-{architecture}\lib\{framework}` or `{platform}-{architecture}\native`. For example, the following folder structure would accommodate both native and managed DLLs targeting Windows 10 and the `uap10.0` framework: - \runtimes - \win10-arm - \native - \lib\uap10.0 - \win10-x86 - \native - \lib\uap10.0 - \win10-x64 - \native - \lib\uap10.0 +``` +\runtimes + \win10-arm + \native + \lib\uap10.0 + \win10-x86 + \native + \lib\uap10.0 + \win10-x64 + \native + \lib\uap10.0 +``` -These assemblies will only be available at runtime, so if you want to provide the corresponding compile time assembly as well then have `AnyCPU` assembly in `/ref{tfm}` folder. +These assemblies will only be available at runtime, so if you want to provide the corresponding compile time assembly as well then have `AnyCPU` assembly in `/ref/{tfm}` folder. -Please note, NuGet always picks these compile or runtime assets from one folder so if there are some compatible assets from `/ref` then `/lib` will be ignored to add compile-time assemblies. Similarly, if there are some compatbile assets from `/runtime` then also `/lib` will be ignored for runtime. +Please note, NuGet always picks these compile or runtime assets from one folder so if there are some compatible assets from `/ref` then `/lib` will be ignored to add compile-time assemblies. Similarly, if there are some compatible assets from `/runtimes` then also `/lib` will be ignored for runtime. See [Create UWP Packages](../guides/create-uwp-packages.md) for an example of referencing these files in the `.nuspec` manifest. -Also, see [Packing a Windows store app component with NuGet](https://blogs.msdn.microsoft.com/mim/2013/09/02/packaging-a-windows-store-apps-component-with-nuget-part-2) +Also, see [Packing a Windows store app component with NuGet](/archive/blogs/mim/packaging-a-windows-store-apps-component-with-nuget-part-2) ## Matching assembly versions and the target framework in a project @@ -76,11 +82,13 @@ If a match is not found, NuGet copies the assembly for the highest version that For example, consider the following folder structure in a package: - \lib - \net45 - \MyAssembly.dll - \net461 - \MyAssembly.dll +``` +\lib + \net45 + \MyAssembly.dll + \net461 + \MyAssembly.dll +``` When installing this package in a project that targets .NET Framework 4.6, NuGet installs the assembly in the `net45` folder, because that's the highest available version that's less than or equal to 4.6. @@ -92,12 +100,14 @@ If the project targets .NET framework 4.0 and earlier, NuGet throws an appropria NuGet copies assemblies from only a single library folder in the package. For example, suppose a package has the following folder structure: - \lib - \net40 - \MyAssembly.dll (v1.0) - \MyAssembly.Core.dll (v1.0) - \net45 - \MyAssembly.dll (v2.0) +``` +\lib + \net40 + \MyAssembly.dll (v1.0) + \MyAssembly.Core.dll (v1.0) + \net45 + \MyAssembly.dll (v2.0) +``` When the package is installed in a project that targets .NET Framework 4.5, `MyAssembly.dll` (v2.0) is the only assembly installed. `MyAssembly.Core.dll` (v1.0) is not installed because it's not listed in the `net45` folder. NuGet behaves this way because `MyAssembly.Core.dll` might have merged into version 2.0 of `MyAssembly.dll`. @@ -107,7 +117,7 @@ If you want `MyAssembly.Core.dll` to be installed for .NET Framework 4.5, place NuGet also supports targeting a specific framework profile by appending a dash and the profile name to the end of the folder. - lib\{framework name}-{profile} +lib\{framework name}-{profile} The supported profiles are as follows: @@ -116,12 +126,38 @@ The supported profiles are as follows: - `wp`: Windows Phone - `cf`: Compact Framework +## Declaring dependencies (Advanced) + +When packing a project file, NuGet tries to automatically generate the dependencies from the project. The information in this section about using a *.nuspec* file to declare dependencies is typically necessary for advanced scenarios only. + +*(Version 2.0+)* You can declare package dependencies in the *.nuspec* corresponding to the target framework of the target project using `` elements within the `` element. For more information, see [dependencies element](../reference/nuspec.md#dependencies-element). + +Each group has an attribute named `targetFramework` and contains zero or more `` elements. Those dependencies are installed together when the target framework is compatible with the project's framework profile. See [Target frameworks](../reference/target-frameworks.md) for the exact framework identifiers. + +We recommend using one group per Target Framework Moniker (TFM) for files in the *lib/* and *ref/* folders. + +The following example shows different variations of the `` element: + +```xml + + + + + + + + + + + +``` + ## Determining which NuGet target to use When packaging libraries targeting the Portable Class Library it can be tricky to determine which NuGet target you should use in your folder names and `.nuspec` file, especially if targeting only a subset of the PCL. The following external resources will help you with this: -- [Framework profiles in .NET](http://blog.stephencleary.com/2012/05/framework-profiles-in-net.html) (stephencleary.com) -- [Portable Class Library profiles](http://embed.plnkr.co/03ck2dCtnJogBKHJ9EjY/preview) (plnkr.co): Table enumerating PCL profiles and their equivalent NuGet targets +- [Framework profiles in .NET](https://blog.stephencleary.com/2012/05/framework-profiles-in-net.html) (stephencleary.com) +- [Portable Class Library profiles](https://embed.plnkr.co/03ck2dCtnJogBKHJ9EjY/preview) (plnkr.co): Table enumerating PCL profiles and their equivalent NuGet targets - [Portable Class Library profiles tool](https://github.com/StephenCleary/PortableLibraryProfiles) (github.com): command line tool for determining PCL profiles available on your system ## Content files and PowerShell scripts @@ -131,24 +167,26 @@ When packaging libraries targeting the Portable Class Library it can be tricky t With `packages.config`, content files and PowerShell scripts can be grouped by target framework using the same folder convention inside the `content` and `tools` folders. For example: - \content - \net46 - \MyContent.txt - \net461 - \MyContent461.txt - \uap - \MyUWPContent.html - \netcore - \tools - init.ps1 - \net46 - install.ps1 - uninstall.ps1 - \uap - install.ps1 - uninstall.ps1 +``` +\content + \net46 + \MyContent.txt + \net461 + \MyContent461.txt + \uap + \MyUWPContent.html + \netcore +\tools + init.ps1 + \net46 + install.ps1 + uninstall.ps1 + \uap + install.ps1 + uninstall.ps1 +``` If a framework folder is left empty, NuGet doesn't add assembly references or content files or run the PowerShell scripts for that framework. > [!Note] -> Because `init.ps1` is executed at the solution level and not dependent on project, it must be placed directly under the `tools` folder. It's ignored if placed under a framework folder. +> Because `init.ps1` is executed at the solution level and not dependent on project, it must be placed directly under the `tools` folder. It's ignored if placed under a framework folder. \ No newline at end of file diff --git a/docs/create-packages/Symbol-Packages-snupkg.md b/docs/create-packages/Symbol-Packages-snupkg.md index 7c0410131..ea43a75f9 100644 --- a/docs/create-packages/Symbol-Packages-snupkg.md +++ b/docs/create-packages/Symbol-Packages-snupkg.md @@ -1,15 +1,10 @@ --- title: How to publish NuGet symbol packages using the new symbol package format '.snupkg'| Microsoft Docs -author: -- cristinamanu -- kraigb -ms.author: -- cristinamanu -- kraigb +author: JonDouglas +ms.author: jodou manager: skofman ms.date: 10/30/2018 ms.topic: reference -ms.prod: nuget ms.technology: null description: How to create NuGet symbol packages (snupkg). keywords: NuGet symbol packages, NuGet package debugging, supporting NuGet debugging, package symbols, symbol package conventions @@ -18,45 +13,60 @@ ms.reviewer: - karann --- - # Creating symbol packages (.snupkg) -Symbol packages allow you to improve the debugging experience of your NuGet packages. +A good debugging experience relies on the presence of debug symbols as they provide critical information like the association between the compiled and the source code, names of local variables, stack traces, and more. You can use symbol packages (.snupkg) to distribute these symbols and improve the debugging experience of your NuGet packages. + +> Note that symbol package isn't the only strategy to make the debug symbols available to the consumers of your library. It's also [possible to `embed`](/dotnet/core/deploying/single-file#include-pdb-files-inside-the-bundle) them in the `dll` or `exe` with the following project property: +> `embedded` ## Prerequisites -[nuget.exe v4.9.0 or above](https://www.nuget.org/downloads) or [dotnet.exe v2.2.0 or above](https://www.microsoft.com/net/download/dotnet-core/2.2), which implement the required [NuGet protocols](../api/nuget-protocols.md). +[nuget.exe v4.9.0 or above](https://www.nuget.org/downloads) or [dotnet CLI v2.2.0 or above](https://www.microsoft.com/net/download/dotnet-core/2.2), which implement the required [NuGet protocols](../api/nuget-protocols.md). ## Creating a symbol package -You can create a snupkg symbol package using dotnet.exe, NuGet.exe, or MSBuild. If you're using NuGet.exe, you can use the following commands to create a .snupkg file in addition to the .nupkg file: +If you're using dotnet CLI or MSBuild, you need to set the `IncludeSymbols` and `SymbolPackageFormat` properties to create a .snupkg file in addition to the .nupkg file. -``` -nuget pack MyPackage.nuspec -Symbols -SymbolPackageFormat snupkg +* Either add the following properties to your .csproj file: -nuget pack MyPackage.csproj -Symbols -SymbolPackageFormat snupkg -``` + ```xml + + true + snupkg + + ``` -If you're using dotnet.exe or MSBuild, use the following steps to create a .snupkg file in addition to the .nupkg file: +* Or specify these properties on the command-line: -1. Add the following properties to your .csproj file: + ```dotnetcli + dotnet pack MyPackage.csproj -p:IncludeSymbols=true -p:SymbolPackageFormat=snupkg + ``` - ```xml - - true - snupkg - - ``` + or + + ```cli + msbuild MyPackage.csproj /t:pack /p:IncludeSymbols=true /p:SymbolPackageFormat=snupkg + ``` -1. Pack your project with `dotnet pack MyPackage.csproj` or `msbuild -t:pack MyPackage.csproj`. +If you're using NuGet.exe, you can use the following commands to create a .snupkg file in addition to the .nupkg file: -The [`SymbolPackageFormat`](/dotnet/core/tools/csproj#symbolpackageformat) property can have one of two values: `symbols.nupkg` (the default) or `snupkg`. If the [`SymbolPackageFormat`](/dotnet/core/tools/csproj#symbolpackageformat) property is not specified, a legacy symbol package will be created. +```cli +nuget pack MyPackage.nuspec -Symbols -SymbolPackageFormat snupkg + +nuget pack MyPackage.csproj -Symbols -SymbolPackageFormat snupkg +``` + +The [`SymbolPackageFormat`](/dotnet/core/tools/csproj#symbolpackageformat) property can have one of two values: `symbols.nupkg` (the default) or `snupkg`. If this property is not specified, a legacy symbol package will be created. > [!Note] -> The legacy format `.symbols.nupkg` is still supported but only for compatibility reasons (see [Legacy Symbol Packages](Symbol-Packages.md)). NuGet.org's symbol server only accepts the new symbol package format - `.snupkg`. +> The legacy format `.symbols.nupkg` is still supported but only for compatibility reasons like native packages (see [Legacy Symbol Packages](Symbol-Packages.md)). NuGet.org's symbol server only accepts the new symbol package format - `.snupkg`. ## Publishing a symbol package +> [!Note] +> [Azure Devops Artifacts](https://azure.microsoft.com/services/devops/artifacts) does not currently support debugging via `.snupkg` files. + 1. For convenience, first save your API key with NuGet (see [publish a package](../nuget-org/publish-a-package.md)). ```cli @@ -82,41 +92,49 @@ NuGet will publish both packages to nuget.org. `MyPackage.nupkg` will be publish ## NuGet.org symbol server -NuGet.org supports its own symbols server repository and only accepts the new symbol package format - `.snupkg`. Package consumers can use the symbols published to nuget.org symbol server by adding `https://symbols.nuget.org/download/symbols` to their symbol sources in Visual Studio, which allows stepping into package code in the Visual Studio debugger. See [Specify symbol (.pdb) and source files in the Visual Studio debugger](https://docs.microsoft.com/en-us/visualstudio/debugger/specify-symbol-dot-pdb-and-source-files-in-the-visual-studio-debugger?view=vs-2017) for details on that process. +NuGet.org supports its own symbols server repository and only accepts the new symbol package format - `.snupkg`. Package consumers can use the symbols published to nuget.org symbol server by adding `https://symbols.nuget.org/download/symbols` to their symbol sources in Visual Studio, which allows stepping into package code in the Visual Studio debugger. See [Specify symbol (.pdb) and source files in the Visual Studio debugger](/visualstudio/debugger/specify-symbol-dot-pdb-and-source-files-in-the-visual-studio-debugger) for details on that process. + +### NuGet.org symbol package constraints -### Nuget.org symbol package constraints +NuGet.org has the following constraints for symbol packages: -The symbol packages supported on nuget.org have the following contraints +- Only the following file extensions are allowed in symbol packages: `.pdb`, `.nuspec`, `.xml`, `.psmdcp`, `.rels`, `.p7s` +- Only managed [Portable PDBs](https://github.com/dotnet/runtime/blob/87572a799bfd37779c079faf28544e3f9a16be58/src/libraries/System.Reflection.Metadata/specs/PortablePdb-Metadata.md) are supported on NuGet.org's symbol server. +- The PDBs and their associated .nupkg DLLs need to be built with the compiler in Visual Studio version 15.9 or above (see [PDB crypto hash](https://github.com/dotnet/roslyn/issues/24429)) -- Only the following file extensions are allowed to be added to a symbol package. ```.pdb,.nuspec,.xml,.psmdcp,.rels,.p7s``` -- Only managed [Portable pdbs](https://github.com/dotnet/corefx/blob/master/src/System.Reflection.Metadata/specs/PortablePdb-Metadata.md) are currently supported on nuget symbol server. -- The pdbs and associated nupkg dlls need to be built with the compiler in Visual Studio version 15.9 or above (see [pdb crypto hash](https://github.com/dotnet/roslyn/issues/24429)) +Symbol packages published to NuGet.org will fail validation if these constraints aren't met. -The symbol package publish on nuget.org will fail if any other file types are included in the .snupkg. +> [!NOTE] +> Native projects, such as C++ projects, produce Windows PDBs instead of Portable PDBs. These are not supported by NuGet.org's symbol server. Please use [Legacy Symbol Packages](Symbol-Packages.md) instead. ### Symbol package validation and indexing -Symbol packages published to [NuGet.org](https://www.nuget.org/) undergo several validations, such as virus checks. +Symbol packages published to [NuGet.org](https://www.nuget.org/) undergo several validations, including malware scanning. If a package fails a validation check, its package details page will display an error message. In addition, the package's owners will receive an email with instructions on how to fix the identified issues. -When the package has passed all validation checks, it might take a while for the symbols to index and be available for consumption from the NuGet.org symbol servers. If the package fails a validation check, the package details page for the .nupkg will update to display the associated error and you will also receive an email notifying you about it. +When the symbol package has passed all validations, the symbols will be indexed by NuGet.org's symbol servers and will be available for consumption. -Package validation and indexing usually takes under 15 minutes. If the package publishing is taking longer than expected, visit [status.nuget.org](https://status.nuget.org/) to check if nuget.org is experiencing any interruptions. If all systems are operational and the package hasn't been successfully published within an hour, please login to nuget.org and contact us using the Contact Support link on the package details page. +Package validation and indexing usually takes under 15 minutes. If the package publishing takes longer than expected, visit [status.nuget.org](https://status.nuget.org/) to check if NuGet.org is experiencing any interruptions. If all systems are operational and the package hasn't been successfully published within an hour, please login to nuget.org and contact us using the Contact Support link on the package details page. ## Symbol package structure -The .nupkg file would be exactly the same as it is today, but the .snupkg file would have the following characteristics: +The symbol package (.snupkg) has the following characteristics: + +1) The .snupkg has the same id and version as its corresponding NuGet package (.nupkg). +2) The .snupkg has the same folder structure as its corresponding .nupkg for any DLL or EXE files with the distinction that instead of DLLs/EXEs, their corresponding PDBs will be included in the same folder hierarchy. Files and folders with extensions other than PDB will be left out of the snupkg. +3) The symbol package's .nuspec file has the `SymbolsPackage` package type: + + ```xml + + + + ``` -1) The .snupkg will have the same id and version as the corresponding .nupkg. -2) The .snupkg will have the exact folder structure as the nupkg for any DLL or EXE files with the distinction that instead of DLLs/EXEs, their corresponding PDBs will be included in the same folder hierarchy. Files and folders with extensions other than PDB will be left out of the snupkg. -3) The .nuspec file in the .snupkg will also specify a new PackageType as below. This should the only one PackageType specified. -``` - - - -``` 4) If an author decides to use a custom nuspec to build their nupkg and snupkg, the snupkg should have the same folder hierarchy and files detailed in 2). -5) ```authors``` and ```owners``` field will be excluded from the snupkg's nuspec. +5) The following fields will be excluded from the snupkg's nuspec: ```authors```, ```owners```, ```requireLicenseAcceptance```, ```license type```, ```licenseUrl```, and ```icon```. +6) Do not use the `````` element. A .snupkg is covered under the same license as the corresponding .nupkg. + +## See also -## See Also +Consider using Source Link to enable source code debugging of .NET assemblies. For more information, please refer to the [Source Link guidance](/dotnet/standard/library-guidance/sourcelink). -[NuGet-Package-Debugging-&-Symbols-Improvements](https://github.com/NuGet/Home/wiki/NuGet-Package-Debugging-&-Symbols-Improvements) +For more information on symbol packages, please refer to the [NuGet Package Debugging & Symbols Improvements](https://github.com/NuGet/Home/wiki/NuGet-Package-Debugging-&-Symbols-Improvements) design spec. diff --git a/docs/create-packages/Symbol-Packages.md b/docs/create-packages/Symbol-Packages.md index 45292dc2e..3226ec766 100644 --- a/docs/create-packages/Symbol-Packages.md +++ b/docs/create-packages/Symbol-Packages.md @@ -1,29 +1,27 @@ --- -title: How to create NuGet symbol packages +title: Creating legacy symbol packages (.symbols.nupkg) description: How to create NuGet packages that contain only symbols to support debugging of other NuGet packages in Visual Studio. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 09/12/2017 ms.topic: conceptual ms.reviewer: anangaur --- -# Creating symbol packages (legacy) +# Creating legacy symbol packages (.symbols.nupkg) > [!Important] > The new recommended format for symbol packages is .snupkg. See [Creating symbol packages (.snupkg)](Symbol-Packages-snupkg.md).
    > .symbols.nupkg is still supported but only for compatibility reasons. -In addition to building packages for nuget.org or other sources, NuGet also supports creating associated symbol packages and publishing them to the SymbolSource repository. +In addition to building packages for nuget.org or other sources, NuGet also supports creating associated symbol packages that can be published to symbol servers. -Package consumers can then add `https://nuget.smbsrc.net` to their symbol sources in Visual Studio, which allows stepping into package code in the Visual Studio debugger. See [Specify symbol (.pdb) and source files in the Visual Studio debugger](/visualstudio/debugger/specify-symbol-dot-pdb-and-source-files-in-the-visual-studio-debugger) for details on that process. +## Creating a legacy symbol package -## Creating a symbol package - -To create a symbol package, follow these conventions: +To create a legacy symbol package, follow these conventions: - Name the primary package (with your code) `{identifier}.nupkg` and include all your files except `.pdb` files. -- Name the symbol package `{identifier}.symbols.nupkg` and include your assembly DLL, `.pdb` files, XMLDOC files, source files (see the sections that follow). +- Name the legacy symbol package `{identifier}.symbols.nupkg` and include your assembly DLL, `.pdb` files, XMLDOC files, source files (see the sections that follow). You can create both packages with the `-Symbols` option, either from a `.nuspec` file or a project file: @@ -35,52 +33,58 @@ nuget pack MyProject.csproj -Symbols Note that `pack` requires Mono 4.4.2 on Mac OS X and does not work on Linux systems. On a Mac, you must also convert Windows pathnames in the `.nuspec` file to Unix-style paths. -## Symbol package structure +## Legacy symbol package structure -A symbol package can target multiple target frameworks in the same way that a library package does, so the structure of the `lib` folder should be exactly the same as the primary package, only including `.pdb` files alongside the DLL. +A legacy symbol package can target multiple target frameworks in the same way that a library package does, so the structure of the `lib` folder should be exactly the same as the primary package, only including `.pdb` files alongside the DLL. -For example, a symbol package that targets .NET 4.0 and Silverlight 4 would have this layout: +For example, a legacy symbol package that targets .NET 4.0 and Silverlight 4 would have this layout: - \lib - \net40 - \MyAssembly.dll - \MyAssembly.pdb - \sl40 - \MyAssembly.dll - \MyAssembly.pdb +``` +\lib + \net40 + \MyAssembly.dll + \MyAssembly.pdb + \sl40 + \MyAssembly.dll + \MyAssembly.pdb +``` Source files are then placed in a separate special folder named `src`, which must follow the relative structure of your source repository. This is because PDBs contain absolute paths to source files used to compile the matching DLL, and they need to be found during the publishing process. A base path (common path prefix) can be stripped out. For example, consider a library built from these files: - C:\Projects - \MyProject - \Common - \MyClass.cs - \Full - \Properties - \AssemblyInfo.cs - \MyAssembly.csproj (producing \lib\net40\MyAssembly.dll) - \Silverlight - \Properties - \AssemblyInfo.cs - \MySilverlightExtensions.cs - \MyAssembly.csproj (producing \lib\sl4\MyAssembly.dll) - -Apart from the `lib` folder, a symbol package would need to contain this layout: - - \src +``` +C:\Projects + \MyProject \Common \MyClass.cs \Full \Properties \AssemblyInfo.cs + \MyAssembly.csproj (producing \lib\net40\MyAssembly.dll) \Silverlight \Properties \AssemblyInfo.cs \MySilverlightExtensions.cs + \MyAssembly.csproj (producing \lib\sl4\MyAssembly.dll) +``` + +Apart from the `lib` folder, a legacy symbol package would need to contain this layout: + +``` +\src + \Common + \MyClass.cs + \Full + \Properties + \AssemblyInfo.cs + \Silverlight + \Properties + \AssemblyInfo.cs + \MySilverlightExtensions.cs +``` ## Referring to files in the nuspec -A symbol package can be built by conventions, from a folder structure as described in the previous section, or by specifying its contents in the `files` section of the manifest. For example, to build the package shown in the previous section, use the following in the `.nuspec` file: +A legacy symbol package can be built by conventions, from a folder structure as described in the previous section, or by specifying its contents in the `files` section of the manifest. For example, to build the package shown in the previous section, use the following in the `.nuspec` file: ```xml @@ -92,40 +96,6 @@ A symbol package can be built by conventions, from a folder structure as describ ``` -## Publishing a symbol package - -> [!Important] -> To push packages to nuget.org you must use [nuget.exe v4.9.1 or above](https://www.nuget.org/downloads), which implements the required [NuGet protocols](../api/nuget-protocols.md). - -1. For convenience, first save your API key with NuGet (see [publish a package](../nuget-org/publish-a-package.md), which will apply to both nuget.org and symbolsource.org, because symbolsource.org will check with nuget.org to verify that you are the package owner. - - ```cli - nuget SetApiKey Your-API-Key - ``` - -2. After publishing your primary package to nuget.org, push the symbol package as follows, which will automatically use symbolsource.org as the target because of the `.symbols` in the filename: - - ```cli - nuget push MyPackage.symbols.nupkg - ``` - -3. To publish to a different symbol repository, or to push a symbol package that doesn't follow the naming convention, use the `-Source` option: - - ```cli - nuget push MyPackage.symbols.nupkg -source https://nuget.smbsrc.net/ - ``` - -4. You can also push both primary and symbol packages to both repositories at the same time using the following: - - ```cli - nuget push MyPackage.nupkg - ``` - - > [!Note] - > With nuget.exe 4.5.0 or above, the symbols packages are not automatically pushed to symbolsource.org. You would need to push the symbols packages separately as explained in the next step. - -In this case, NuGet will publish `MyPackage.symbols.nupkg`, if present, to https://nuget.smbsrc.net/ (the push URL for symbolsource.org), after it publishes the primary package to nuget.org. - -## See Also +## See also -[Moving to the new SymbolSource engine](https://tripleemcoder.com/2015/10/04/moving-to-the-new-symbolsource-engine/) (symbolsource.org) +* [Creating symbol packages (.snupkg)](Symbol-Packages-snupkg.md) - The new recommended format for symbol packages diff --git a/docs/create-packages/author-packages-with-COM-interop-assemblies.md b/docs/create-packages/author-packages-with-COM-interop-assemblies.md index baedc7736..e37c68ce4 100644 --- a/docs/create-packages/author-packages-with-COM-interop-assemblies.md +++ b/docs/create-packages/author-packages-with-COM-interop-assemblies.md @@ -1,15 +1,15 @@ --- title: Create packages with COM interop assemblies description: Describes how to create packages that contain COM interop assemblies -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 07/09/2019 ms.topic: conceptual --- -## Create NuGet packages that contain COM interop assemblies +# Create NuGet packages that contain COM interop assemblies -Packages that contain COM interop assemblies must include an appropriate [targets file](creating-a-package.md#include-msbuild-props-and-targets-in-a-package) so that the correct `EmbedInteropTypes` metadata is added to projects using the PackageReference format. By default, the `EmbedInteropTypes` metadata is always false for all assemblies when PackageReference is used, so the targets file adds this metadata explicitly. To avoid conflicts, the target name should be unique; ideally, use a combination of your package name and the assembly being embedded, replacing the `{InteropAssemblyName}` in the example below with that value. (Also see [NuGet.Samples.Interop](https://github.com/NuGet/Samples/tree/master/NuGet.Samples.Interop) for an example.) +Packages that contain COM interop assemblies must include an appropriate [targets file](creating-a-package.md#include-msbuild-props-and-targets-in-a-package) so that the correct `EmbedInteropTypes` metadata is added to projects using the PackageReference format. By default, the `EmbedInteropTypes` metadata is always false for all assemblies when PackageReference is used, so the targets file adds this metadata explicitly. To avoid conflicts, the target name should be unique; ideally, use a combination of your package name and the assembly being embedded, replacing the `{InteropAssemblyName}` in the example below with that value. (Also see [NuGet.Samples.Interop](https://github.com/NuGet/Samples/tree/main/NuGet.Samples.Interop) for an example.) ```xml @@ -21,7 +21,7 @@ Packages that contain COM interop assemblies must include an appropriate [target ``` -Note that when using the `packages.config` management format, adding references to the assemblies from the packages causes NuGet and Visual Studio to check for COM interop assemblies and set the `EmbedInteropTypes` to true in the project file. In this case the targets are overriden. +Note that when using the `packages.config` management format, adding references to the assemblies from the packages causes NuGet and Visual Studio to check for COM interop assemblies and set the `EmbedInteropTypes` to true in the project file. In this case, the targets are overridden. Additionally, by default the [build assets do not flow transitively](../consume-packages/package-references-in-project-files.md#controlling-dependency-assets). Packages authored as described here work differently when they are pulled as a transitive dependency from a project to project reference. The package consumer can allow them to flow by modifying the PrivateAssets default value to not include build. diff --git a/docs/create-packages/creating-a-package-dotnet-cli.md b/docs/create-packages/creating-a-package-dotnet-cli.md index 0d8684f02..498587233 100644 --- a/docs/create-packages/creating-a-package-dotnet-cli.md +++ b/docs/create-packages/creating-a-package-dotnet-cli.md @@ -1,133 +1,134 @@ --- -title: Create a NuGet package using the dotnet CLI -description: A detailed guide to the process of designing and creating a NuGet package, including key decision points like files and versioning. -author: karann-msft -ms.author: karann -ms.date: 07/09/2019 +title: Create a NuGet package with the dotnet CLI +description: Read a detailed guide about the process of designing and creating a NuGet package, including key decision points like files and versioning. +author: JonDouglas +ms.author: jodou +ms.date: 03/03/2025 ms.topic: conceptual --- -# Create a NuGet package using the dotnet CLI +# Create a NuGet package with the dotnet CLI -No matter what your package does or what code it contains, you use one of the CLI tools, either `nuget.exe` or `dotnet.exe`, to package that functionality into a component that can be shared with and used by any number of other developers. This article describes how to create a package using the dotnet CLI. To install the `dotnet` CLI, see [Install NuGet client tools](../install-nuget-client-tools.md). Starting in Visual Studio 2017, the dotnet CLI is included with .NET Core workloads. +NuGet packages contain code that developers can reuse in their projects. No matter what your code does or contains, you use a command-line tool, either `nuget.exe` or `dotnet.exe`, to create the NuGet package. -For .NET Core and .NET Standard projects that use the [SDK-style format](../resources/check-project-format.md), and any other SDK-style projects, NuGet uses information in the project file directly to create a package. For step-by-step tutorials, see [Create .NET Standard Packages with dotnet CLI](../quickstart/create-and-publish-a-package-using-the-dotnet-cli.md), [Create .NET Standard Packages with Visual Studio](../quickstart/create-and-publish-a-package-using-visual-studio.md). +This article describes how to create a package by using the [dotnet CLI](). Starting in Visual Studio 2017, the dotnet CLI is included with all .NET and .NET Core workloads. If you need to install the dotnet CLI or other NuGet client tools, see [Install NuGet client tools](../install-nuget-client-tools.md). -`msbuild -t:pack` is functionality equivalent to `dotnet pack`. To build with MSBuild, the concepts are the same as described in this article, but the command line commands are slightly different. Similarly, with a non-SDK-style project and ``, you can use `msbuild /t:pack`. In these scenarios, you need to add the NuGet.Build.Tasks.Pack package to their dependencies. See [NuGet pack and restore as MSBuild targets](../reference/msbuild-targets.md). +This topic applies only to .NET and other projects that use the [SDK-style format](../resources/check-project-format.md). For these projects, NuGet uses information from the project file to create a package. For quickstart tutorials, see [Create packages with the dotnet CLI](../quickstart/create-and-publish-a-package-using-the-dotnet-cli.md) or [Create packages with Visual Studio](../quickstart/create-and-publish-a-package-using-visual-studio.md). -> [!IMPORTANT] -> This topic applies to [SDK-style](../resources/check-project-format.md) projects, typically .NET Core and .NET Standard projects. +The MSBuild [msbuild -t:pack](creating-a-package-msbuild.md#run-the-msbuild--tpack-command) command is functionally equivalent to [dotnet pack](/dotnet/core/tools/dotnet-pack). For more information about creating a package with MSBuild, see [Create a NuGet package using MSBuild](creating-a-package-msbuild.md). -## Set properties +> [!NOTE] +> - To create and publish packages for non-SDK-style projects, typically .NET Framework projects, see [Create a package using the nuget.exe CLI](Creating-a-Package.md) or [Create and publish a package using Visual Studio (.NET Framework)](../quickstart/create-and-publish-a-package-using-visual-studio-net-framework.md). +> +> - For projects migrated from *packages.config* to [PackageReference](../consume-packages/package-references-in-project-files.md), use `msbuild -t:pack`. For more information, see [Create a package after migration](../consume-packages/migrate-packages-config-to-package-reference.md#create-a-package-after-migration). -The following properties are required to create a package. +## Set properties -- `PackageId`, the package identifier, which must be unique across the gallery that hosts the package. If not specified, the default value is `AssemblyName`. -- `Version`, a specific version number in the form *Major.Minor.Patch[-Suffix]* where *-Suffix* identifies [pre-release versions](prerelease-packages.md). If not specified, the default value is 1.0.0. -- The package title as it should appear on the host (like nuget.org) -- `Authors`, author and owner information. If not specified, the default value is `AssemblyName`. -- `Company`, your company name. If not specified, the default value is `AssemblyName`. +You can create an example class library project by using the `dotnet new classlib` command, and package the project by using `dotnet pack`. The `dotnet pack` command uses the following properties. If you don't specify values in the project file, the command uses default values. -In Visual Studio, you can set these values in the project properties (right-click the project in Solution Explorer, choose **Properties**, and select the **Package** tab). You can also set these properties directly in the project files (`.csproj`). +- `PackageId`, the package identifier, must be unique across nuget.org and any other targets that host the package. If you don't specify a value, the command uses the `AssemblyName`. +- `Version` is a specific version number in the form `Major.Minor.Patch[-Suffix]`, where `-Suffix` identifies [prerelease versions](prerelease-packages.md). If not specified, the default value is `1.0.0`. +- `Authors` are the authors of the package. If not specified, the default value is the `AssemblyName`. +- `Company` is company information. If not specified, the default value is the `Authors` value. +- `Product` is product information. If not specified, the default value is the `AssemblyName`. - ```xml - - ... - AppLogger - 1.0.0 - your_name - your_company - - ``` +In Visual Studio, you can set these values in the project properties. Right-click the project in **Solution Explorer**, select **Properties**, and then select the **Package** section. You can also add the properties directly to the *.csproj* or other project file. -> [!Important] -> Give the package an identifier that's unique across nuget.org or whatever package source you're using. +The following example shows a project file with package properties added. -You can also set the optional properties, such as `Title`, `PackageDescription`, and `PackageTags`, as described in [MSBuild pack targets](../reference/msbuild-targets.md#pack-target), [Controlling dependency assets](../consume-packages/package-references-in-project-files.md#controlling-dependency-assets), and [NuGet metadata properties](/dotnet/core/tools/csproj#nuget-metadata-properties). +```xml + + + netstandard2.0 + UniqueID + 1.0.0 + Author Name + Company Name + Product Name + + +``` -> [!NOTE] -> For packages built for public consumption, pay special attention to the **PackageTags** property, as tags help others find your package and understand what it does. +You can add other optional properties, such as `Title`, `PackageDescription`, and `PackageTags`. -For details on declaring dependencies and specifying version numbers, see [Package versioning](../reference/package-versioning.md). It is also possible to surface assets from dependencies directly in the package by using the `` and `` attributes. For more information, seee [Controlling dependency assets](../consume-packages/package-references-in-project-files.md#controlling-dependency-assets). +>[!NOTE] +> For packages you build for public consumption, pay special attention to the `PackageTags` property. Tags help others find your package and understand what it does. -## Choose a unique package identifier and setting the version number +The `dotnet pack` command automatically converts `PackageReference`s in your project files to dependencies in the created package. You can control which assets to include through the `IncludeAssets`, `ExcludeAssets` and `PrivateAssets` tags. For more information, see [Controlling dependency assets](../consume-packages/package-references-in-project-files.md#controlling-dependency-assets). -The package identifier and the version number are the two most important values in the project because they uniquely identify the exact code that's contained in the package. +For more information about dependencies, optional properties, and versioning, see: -**Best practices for the package identifier:** +- [Package references in project files](../consume-packages/package-references-in-project-files.md) +- [Package versioning](../concepts/package-versioning.md) +- [NuGet metadata properties](/dotnet/core/tools/csproj#nuget-metadata-properties) +- [MSBuild pack targets](../reference/msbuild-targets.md#pack-target) -- **Uniqueness**: The identifier must be unique across nuget.org or whatever gallery hosts the package. Before deciding on an identifier, search the applicable gallery to check if the name is already in use. To avoid conflicts, a good pattern is to use your company name as the first part of the identifier, such as `Contoso.`. -- **Namespace-like names**: Follow a pattern similar to namespaces in .NET, using dot notation instead of hyphens. For example, use `Contoso.Utility.UsefulStuff` rather than `Contoso-Utility-UsefulStuff` or `Contoso_Utility_UsefulStuff`. Consumers also find it helpful when the package identifier matches the namespaces used in the code. -- **Sample Packages**: If you produce a package of sample code that demonstrates how to use another package, attach `.Sample` as a suffix to the identifier, as in `Contoso.Utility.UsefulStuff.Sample`. (The sample package would of course have a dependency on the other package.) When creating a sample package, use the `contentFiles` value in ``. In the `content` folder, arrange the sample code in a folder called `\Samples\` as in `\Samples\Contoso.Utility.UsefulStuff.Sample`. +### Choose a unique package identifier and set the version number -**Best practices for the package version:** +[!INCLUDE [choose-package-id](includes/choose-package-id.md)] -- In general, set the version of the package to match the project (or assembly), though this is not strictly required. This is a simple matter when you limit a package to a single assembly. Overall, remember that NuGet itself deals with package versions when resolving dependencies, not assembly versions. -- When using a non-standard version scheme, be sure to consider the NuGet versioning rules as explained in [Package versioning](../reference/package-versioning.md). NuGet is mostly [semver 2 compliant](../reference/package-versioning.md#semantic-versioning-200). +### Add an optional description field -> For information on dependency resolution, see [Dependency resolution with PackageReference](../consume-packages/dependency-resolution.md#dependency-resolution-with-packagereference). For older information that may also be helpful to better understand versioning, see this series of blog posts. -> -> - [Part 1: Taking on DLL Hell](http://blog.davidebbo.com/2011/01/nuget-versioning-part-1-taking-on-dll.html) -> - [Part 2: The core algorithm](http://blog.davidebbo.com/2011/01/nuget-versioning-part-2-core-algorithm.html) -> - [Part 3: Unification via Binding Redirects](http://blog.davidebbo.com/2011/01/nuget-versioning-part-3-unification-via.html) +[!INCLUDE [add description to package](includes/add-description.md)] ## Run the pack command -To build a NuGet package (a `.nupkg` file) from the project, run the `dotnet pack` command, which also builds the project automatically: +To build the NuGet package or *.nupkg* file, run the [dotnet pack](/dotnet/core/tools/dotnet-pack) command from the project folder, which also builds the project automatically. -```cli -# Uses the project file in the current folder by default +```dotnetcli dotnet pack ``` -The output shows the path to the `.nupkg` file: +The output shows the path to the *.nupkg* file: ```output -Microsoft (R) Build Engine version 15.5.180.51428 for .NET Core -Copyright (C) Microsoft Corporation. All rights reserved. - - Restore completed in 29.91 ms for D:\proj\AppLoggerNet\AppLogger\AppLogger.csproj. - AppLogger -> D:\proj\AppLoggerNet\AppLogger\bin\Debug\netstandard2.0\AppLogger.dll +MSBuild version 17.3.0+92e077650 for .NET + Determining projects to restore... + Restored D:\proj\AppLoggerNet\AppLogger\AppLogger.csproj (in 97 ms). Successfully created package 'D:\proj\AppLoggerNet\AppLogger\bin\Debug\AppLogger.1.0.0.nupkg'. ``` ### Automatically generate package on build -To automatically run `dotnet pack` when you run `dotnet build`, add the following line to your project file within ``: +To automatically run `dotnet pack` whenever you run `dotnet build`, add the following line to your project file in the `` tag: ```xml true ``` -When you run `dotnet pack` on a solution, this packs all the projects in the solution that are packable ([](/dotnet/core/tools/csproj#nuget-metadata-properties) property is set to `true`. - > [!NOTE] -> When you automatically generate the package, the time to pack increases the build time for your project. +> When you automatically generate the package, packing increases the build time for your project. + +Running `dotnet pack` on a solution packs all the projects in the solution that are packable, that is, have the `IsPackable` property set to `true`. ### Test package installation -Before publishing a package, you typically want to test the process of installing a package into a project. The tests make sure that the necessarily files all end up in their correct places in the project. +Before you publish a package, you should test installing the package into a project. Testing ensures that the necessary files end up in their correct places in the project. -You can test installations manually in Visual Studio or on the command line using the normal [package installation steps](../consume-packages/overview-and-workflow.md#ways-to-install-a-nuget-package). +Test the installation manually in Visual Studio or on the command line by using the normal [package installation process](../consume-packages/overview-and-workflow.md#ways-to-install-a-nuget-package). > [!IMPORTANT] -> Packages are immutable. If you correct a problem, change the contents of the package and pack again, when you retest you will still be using the old version of the package until you [clear your global packages](../consume-packages/managing-the-global-packages-and-cache-folders.md#clearing-local-folders) folder. This is especially relevant when testing packages that don't use a unique prerelease label on every build. +> - You can't change packages once created. If you correct a problem, change the package contents and repack. +> +> - After you recreate the package, retesting still uses the old version of the package until you [clear your global packages folder](../consume-packages/managing-the-global-packages-and-cache-folders.md#clearing-local-folders). Clearing the folder is especially important for packages that don't use a unique prerelease label on every build. -## Next Steps +## Next steps -Once you've created a package, which is a `.nupkg` file, you can publish it to the gallery of your choice as described on [Publishing a Package](../nuget-org/publish-a-package.md). +Once you create the package, you can publish the *.nupkg* file to the host of your choice. -You might also want to extend the capabilities of your package or otherwise support other scenarios as described in the following topics: +> [!div class="nextstepaction"] +> [Publish a package](../nuget-org/publish-a-package.md) -- [Package versioning](../reference/package-versioning.md) +See the following articles for ways to extend the capabilities of your package or support other scenarios: + +- [Package versioning](../concepts/package-versioning.md) - [Support multiple target frameworks](../create-packages/multiple-target-frameworks-project-file.md) +- [Add a package icon](../reference/nuspec.md#icon) - [Transformations of source and configuration files](../create-packages/source-and-config-file-transformations.md) - [Localization](../create-packages/creating-localized-packages.md) -- [Pre-release versions](../create-packages/prerelease-packages.md) +- [Prerelease versions](../create-packages/prerelease-packages.md) - [Set package type](../create-packages/set-package-type.md) +- [MSBuild props and targets](../concepts/MSBuild-props-and-targets.md) - [Create packages with COM interop assemblies](../create-packages/author-packages-with-COM-interop-assemblies.md) - -Finally, there are additional package types to be aware of: - -- [Native Packages](../create-packages/native-packages.md) -- [Symbol Packages](../create-packages/symbol-packages.md) +- [Create native packages](../guides/native-packages.md) +- [Create symbol packages (.snupkg)](symbol-packages-snupkg.md) diff --git a/docs/create-packages/creating-a-package-msbuild.md b/docs/create-packages/creating-a-package-msbuild.md new file mode 100644 index 000000000..a07d92d5f --- /dev/null +++ b/docs/create-packages/creating-a-package-msbuild.md @@ -0,0 +1,211 @@ +--- +title: Create a NuGet package using MSBuild +description: A detailed guide to the process of designing and creating a NuGet package using MSBuild, including key decision points like files and versioning. +author: JonDouglas +ms.author: jodou +ms.date: 08/17/2023 +ms.topic: conceptual +--- + +# Create a NuGet package using MSBuild + +When you create a NuGet package from your code, you package that functionality into a component that can be shared with and used by any number of other developers. This article describes how to create a package using MSBuild. MSBuild comes preinstalled with every Visual Studio workload that contains NuGet. Additionally you can also use MSBuild through the dotnet CLI with [dotnet msbuild](/dotnet/core/tools/dotnet-msbuild). + +For .NET Core and .NET Standard projects that use the [SDK-style format](../resources/check-project-format.md), and any other SDK-style projects, NuGet uses information in the project file directly to create a package. For a non-SDK-style project that uses ``, NuGet also uses the project file to create a package. + +SDK-style projects have the pack functionality available by default. +For non-SDK-style PackageReference projects, it is also available by default starting from Visual Studio 2026. +In earlier versions of Visual Studio you need to add the NuGet.Build.Tasks.Pack package to the project dependencies and we recommend removing this package reference when upgrading to Visual Studio 2026. +For detailed information about MSBuild pack targets, see [NuGet pack and restore as MSBuild targets](../reference/msbuild-targets.md). + +For SDK-style projects, `msbuild -t:pack` is functionally equivalent to `dotnet pack`. + +> [!IMPORTANT] +> This topic applies to [SDK-style](../resources/check-project-format.md) projects, typically .NET Core and .NET Standard projects, and to non-SDK-style projects that use PackageReference. + +## Set properties + +The following properties are required to create a package. + +- `PackageId`, the package identifier, which must be unique across the gallery that hosts the package. If not specified, the default value is `AssemblyName`. +- `Version`, a specific version number in the form *Major.Minor.Patch[-Suffix]* where *-Suffix* identifies [pre-release versions](prerelease-packages.md). If not specified, the default value is 1.0.0. +- The package title as it should appear on the host (like nuget.org) +- `Authors`, author and owner information. If not specified, the default value is `AssemblyName`. +- `Company`, your company name. If not specified, the default value is `AssemblyName`. + +Additionally if you are packing non-SDK-style projects that use PackageReference, the following is required: + +- `PackageOutputPath`, the output folder for the package generated when calling pack. + +In Visual Studio, you can set these values in the project properties (right-click the project in Solution Explorer, choose **Properties**, and select the **Package** tab). You can also set these properties directly in the project files (*.csproj*). + +```xml + + ClassLibDotNetStandard + 1.0.0 + your_name + your_company + +``` + +> [!Important] +> Give the package an identifier that's unique across nuget.org or whatever package source you're using. + +The following example shows a simple, complete project file with these properties included. + +```xml + + + netstandard2.0 + ClassLibDotNetStandard + 1.0.0 + your_name + your_company + + +``` + +You can also set the optional properties, such as `Title`, `PackageDescription`, and `PackageTags`, as described in [MSBuild pack targets](../reference/msbuild-targets.md#pack-target), [Controlling dependency assets](../consume-packages/package-references-in-project-files.md#controlling-dependency-assets), and [NuGet metadata properties](/dotnet/core/tools/csproj#nuget-metadata-properties). + +> [!NOTE] +> For packages built for public consumption, pay special attention to the **PackageTags** property, as tags help others find your package and understand what it does. + +For details on declaring dependencies and specifying version numbers, see [Package references in project files](../consume-packages/package-references-in-project-files.md) and [Package versioning](../concepts/package-versioning.md). It is also possible to surface assets from dependencies directly in the package by using the `` and `` attributes. For more information, seee [Controlling dependency assets](../consume-packages/package-references-in-project-files.md#controlling-dependency-assets). + +## Add an optional description field + +[!INCLUDE [add description to package](includes/add-description.md)] + +## Choose a unique package identifier and set the version number + +[!INCLUDE [choose-package-id](includes/choose-package-id.md)] + +## Configure project for pack + +SDK-style projects do not require any additional configuration. + +Non-SDK-style projects either need at least one package installed (via PackageReference, not packages.config), or the project explicitly needs to instruct NuGet to treat the project as a PackageReference project via the `RestoreProjectStyle` property. + +Visual Studio 2022 and earlier does not have pack built-in, so you also need to install the NuGet.Build.Tasks.Pack package. +When upgrading to Visual Studio 2026 or later, we recommend uninstalling the package, so that you benefit from new features and bug fixes. + +1. Edit the project file. + + If you want to explicitly instruct NuGet to treat the project as PackageReference (the project does not have any packages installed), find or add a `` that does not have any `Condition` statement, and add: + + ```xml + + + PackageReference + + + ``` + + If you are using Visual Studio 2022 or earlier, add the following after the `` element: + + ```xml + + + + + + ``` + + > [!NOTE] + > [Consider using the latest version of this package available.](https://www.nuget.org/packages/nuget.build.tasks.pack) + +2. Open a Developer command prompt (In the **Search** box, type **Developer command prompt**). + + You typically want to start the Developer Command Prompt for Visual Studio from the **Start** menu, as it will be configured with all the necessary paths for MSBuild. + +3. Switch to the folder containing the project file and type the following command to restore the NuGet.Build.Tasks.Pack package. + + ```cmd + # Uses the project file in the current folder by default + msbuild -t:restore + ``` + + Make sure that the MSBuild output indicates that the build completed successfully. + +## Run the msbuild -t:pack command + +To build a NuGet package (a `.nupkg` file) from the project, run the `msbuild -t:pack` command, which also builds the project automatically: + +In the Developer command prompt for Visual Studio, type the following command: + +```cmd +# Uses the project file in the current folder by default +msbuild -t:pack +``` + +The output shows the path to the `.nupkg` file. + +```output +Microsoft (R) Build Engine version 16.1.76+g14b0a930a7 for .NET Framework +Copyright (C) Microsoft Corporation. All rights reserved. + +Build started 8/5/2019 3:09:15 PM. +Project "C:\Users\username\source\repos\ClassLib_DotNetStandard\ClassLib_DotNetStandard.csproj" on node 1 (pack target(s)). +GenerateTargetFrameworkMonikerAttribute: +Skipping target "GenerateTargetFrameworkMonikerAttribute" because all output files are up-to-date with respect to the input files. +CoreCompile: + ... +CopyFilesToOutputDirectory: + Copying file from "C:\Users\username\source\repos\ClassLib_DotNetStandard\obj\Debug\netstandard2.0\ClassLib_DotNetStandard.dll" to "C:\Use + rs\username\source\repos\ClassLib_DotNetStandard\bin\Debug\netstandard2.0\ClassLib_DotNetStandard.dll". + ClassLib_DotNetStandard -> C:\Users\username\source\repos\ClassLib_DotNetStandard\bin\Debug\netstandard2.0\ClassLib_DotNetStandard.dll + Copying file from "C:\Users\username\source\repos\ClassLib_DotNetStandard\obj\Debug\netstandard2.0\ClassLib_DotNetStandard.pdb" to "C:\Use + rs\username\source\repos\ClassLib_DotNetStandard\bin\Debug\netstandard2.0\ClassLib_DotNetStandard.pdb". +GenerateNuspec: + Successfully created package 'C:\Users\username\source\repos\ClassLib_DotNetStandard\bin\Debug\AppLogger.1.0.0.nupkg'. +Done Building Project "C:\Users\username\source\repos\ClassLib_DotNetStandard\ClassLib_DotNetStandard.csproj" (pack target(s)). + +Build succeeded. + 0 Warning(s) + 0 Error(s) + +Time Elapsed 00:00:01.21 +``` + +### Automatically generate package on build + +To automatically run `msbuild -t:pack` when you build or restore the project, add the following line to your project file within ``: + +```xml +true +``` + +When you run `msbuild -t:pack` on a solution, this packs all the projects in the solution that are packable ([``](/dotnet/core/tools/csproj#nuget-metadata-properties) property is set to `true`). + +> [!NOTE] +> When you automatically generate the package, the time to pack increases the build time for your project. + +### Test package installation + +Before publishing a package, you typically want to test the process of installing a package into a project. The tests make sure that the necessarily files all end up in their correct places in the project. + +You can test installations manually in Visual Studio or on the command line using the normal [package installation steps](../consume-packages/overview-and-workflow.md#ways-to-install-a-nuget-package). + +> [!IMPORTANT] +> Packages are immutable. If you correct a problem, change the contents of the package and pack again, when you retest you will still be using the old version of the package until you [clear your global packages](../consume-packages/managing-the-global-packages-and-cache-folders.md#clearing-local-folders) folder. This is especially relevant when testing packages that don't use a unique prerelease label on every build. + +## Next Steps + +Once you've created a package, which is a `.nupkg` file, you can publish it to the gallery of your choice as described on [Publishing a Package](../nuget-org/publish-a-package.md). + +You might also want to extend the capabilities of your package or otherwise support other scenarios as described in the following topics: + +- [NuGet pack and restore as MSBuild targets](../reference/msbuild-targets.md) +- [Package versioning](../concepts/package-versioning.md) +- [Support multiple target frameworks](../create-packages/multiple-target-frameworks-project-file.md) +- [Transformations of source and configuration files](../create-packages/source-and-config-file-transformations.md) +- [Localization](../create-packages/creating-localized-packages.md) +- [Pre-release versions](../create-packages/prerelease-packages.md) +- [Set package type](../create-packages/set-package-type.md) +- [MSBuild props and targets](../concepts/MSBuild-props-and-targets.md) +- [Create packages with COM interop assemblies](../create-packages/author-packages-with-COM-interop-assemblies.md) + +Finally, there are additional package types to be aware of: + +- [Native Packages](../guides/native-packages.md) +- [Symbol Packages](../create-packages/symbol-packages-snupkg.md) diff --git a/docs/create-packages/includes/add-description.md b/docs/create-packages/includes/add-description.md new file mode 100644 index 000000000..62111c133 --- /dev/null +++ b/docs/create-packages/includes/add-description.md @@ -0,0 +1,21 @@ +The package's optional description appears on the **README** tab of the package's nuget.org page. The description pulls from the `` in the project file or the `$description` in the [.nuspec file](../../reference/nuspec.md). + +The following example shows a `Description` in the *.csproj* file for a .NET package: + +```xml + + + Azure.Storage.Blobs + 12.4.0 + Microsoft Azure Storage Blobs;Microsoft;Azure;Blobs;Blob;Storage;StorageScalable + + This client library enables working with the Microsoft Azure Storage Blob service for storing binary and text data. + For this release see notes - https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/storage/Azure.Storage.Blobs/README.md and https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/storage/Azure.Storage.Blobs/CHANGELOG.md + in addition to the breaking changes https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/storage/Azure.Storage.Blobs/BreakingChanges.txt + Microsoft Azure Storage quickstarts and tutorials - https://learn.microsoft.com/azure/storage/ + Microsoft Azure Storage REST API Reference - https://learn.microsoft.com/rest/api/storageservices/ + REST API Reference for Blob Service - https://learn.microsoft.com/rest/api/storageservices/blob-service-rest-api + + + +``` diff --git a/docs/create-packages/includes/choose-package-id.md b/docs/create-packages/includes/choose-package-id.md new file mode 100644 index 000000000..6e6c5f436 --- /dev/null +++ b/docs/create-packages/includes/choose-package-id.md @@ -0,0 +1,22 @@ +The package identifier and the version number uniquely identify the exact code that's contained in the package. + +Follow these best practices to create the package identifier: + +- The identifier must be *unique* across nuget.org and all other locations that host the package. To avoid conflicts, a good pattern is to use your company name as the first part of the identifier. +- Follow a *.NET namespace-like naming convention*, using dot notation. For example, use `Contoso.Utility.UsefulStuff` rather than `Contoso-Utility-UsefulStuff` or `Contoso_Utility_UsefulStuff`. It's also helpful for consumers if you match the package identifier to the namespace the code uses. +- If you produce a package of *sample code* that demonstrates how to use another package, append `.Sample` to the identifier, as in `Contoso.Utility.UsefulStuff.Sample`. + + The sample package has a dependency on the original package. When you create the sample package, add `` with the `contentFiles` value. In the *content* folder, arrange the sample code in a folder called *\\Samples\\\*, such as *\\Samples\\Contoso.Utility.UsefulStuff.Sample*. + +Follow these best practices to set the package version: + +- In general, set the package version to *match the project or assembly version*, although this isn't strictly required. Matching the version is simple when you limit a package to a single assembly. NuGet itself deals with package versions when resolving dependencies, not assembly versions. + +- If you use a non-standard version scheme, be sure to consider the *NuGet versioning rules* as explained in [Package versioning](../../concepts/package-versioning.md). NuGet is mostly [Semantic Versioning 2.0.0](../../concepts/package-versioning.md#semantic-versioning-200)-compliant. + +>[!NOTE] +> For more information about dependency resolution, see [Dependency resolution with PackageReference](../../concepts/dependency-resolution.md#dependency-resolution-with-packagereference). For information that might help you understand versioning, see this series of blog posts: +> +> - [Part 1: Taking on DLL Hell](https://blog.davidebbo.com/2011/01/nuget-versioning-part-1-taking-on-dll.html) +> - [Part 2: The core algorithm](https://blog.davidebbo.com/2011/01/nuget-versioning-part-2-core-algorithm.html) +> - [Part 3: Unification via binding redirects](https://blog.davidebbo.com/2011/01/nuget-versioning-part-3-unification-via.html) diff --git a/docs/create-packages/media/Verified-check-mark.png b/docs/create-packages/media/Verified-check-mark.png new file mode 100644 index 000000000..655262af9 Binary files /dev/null and b/docs/create-packages/media/Verified-check-mark.png differ diff --git a/docs/create-packages/media/publish_APIKey.png b/docs/create-packages/media/publish_APIKey.png deleted file mode 100644 index d9dd46836..000000000 Binary files a/docs/create-packages/media/publish_APIKey.png and /dev/null differ diff --git a/docs/create-packages/multiple-target-frameworks-project-file.md b/docs/create-packages/multiple-target-frameworks-project-file.md index af38598b3..326dc1e6f 100644 --- a/docs/create-packages/multiple-target-frameworks-project-file.md +++ b/docs/create-packages/multiple-target-frameworks-project-file.md @@ -1,8 +1,8 @@ --- title: Multi-targeting for NuGet Packages in your project file -description: Description of the various methods to target multiple .NET Framework versions from within a single NuGet package. -author: karann-msft -ms.author: karann +description: Description of the various methods to target multiple .NET Framework versions from within a single NuGet package in your project file. +author: JonDouglas +ms.author: jodou ms.date: 07/15/2019 ms.topic: conceptual --- @@ -22,13 +22,17 @@ For SDK-style projects, you can configure support for multiple targets framework We recommend that you create a .NET Standard class library for best compatibility. -2. Edit the *.csproj* file to support the target frameworks. - - For example, change `netstandard2.0` to `netstandard2.0;net45`. +2. Edit the *.csproj* file to support the target frameworks. For example, change + + `netstandard2.0` + + to: + + `netstandard2.0;net45` Make sure that you change the XML element changed from singular to plural (add the "s" to both the open and close tags). -3. If you have any code that only works in one TFM, you can use `#if NET45` or `#if NETSTANDARD20` to separate TFM-dependent code. (For more information, see [How to multitarget](/dotnet/core/tutorials/libraries#how-to-multitarget).) For example, you can use the following code: +3. If you have any code that only works in one TFM, you can use `#if NET45` or `#if NETSTANDARD2_0` to separate TFM-dependent code. (For more information, see [How to multitarget](/dotnet/core/tutorials/libraries#how-to-multitarget).) For example, you can use the following code: ```csharp public string Platform { @@ -67,5 +71,5 @@ Here is the *.csproj* file that is generated using the preceding steps and .NET ## See also -[How to specify target frameworks](/dotnet/standard/frameworks#how-to-specify-target-frameworks) -[Cross-platform targeting](/dotnet/standard/library-guidance/cross-platform-targeting) +* [How to specify target frameworks](/dotnet/standard/frameworks#how-to-specify-target-frameworks) +* [Cross-platform targeting](/dotnet/standard/library-guidance/cross-platform-targeting) diff --git a/docs/create-packages/native-files-in-net-packages.md b/docs/create-packages/native-files-in-net-packages.md new file mode 100644 index 000000000..8a690cb55 --- /dev/null +++ b/docs/create-packages/native-files-in-net-packages.md @@ -0,0 +1,183 @@ +--- +title: Native files in .NET packages +description: How to pack native libraries in .NET packages +author: zivkan +ms.author: zivkan +ms.date: 09/26/2023 +ms.topic: conceptual +--- + +# Including native libraries in .NET packages + +This document explains how to create packages that work for projects targeting .NET (5+), where a .NET managed assembly uses [Platform Invoke (P/Invoke)](/dotnet/standard/native-interop/pinvoke) from a .NET managed language project, with the .NET runtime using [probing paths](/dotnet/core/dependency-loading/default-probing) to load and locate the native library. + +If you wish to support .NET Framework with your package, see the [section on projects targeting .NET Framework](#projects-targeting-net-framework). +In general, your best option is to package your own [MSBuild props and targets files](../concepts/MSBuild-props-and-targets.md), and handle build and publish targets yourself. +By not using NuGet and the .NET runtime's built in feature, you need to be sufficiently knowledgeable in MSBuild and the build systems for the relevant project types. + +While NuGet has a [`contentFiles/` feature](../reference/msbuild-targets.md#including-content-in-a-package), it is not recommended to use this, as it doesn't support per-RID selection, and therefore doesn't participate in the .NET runtime's probing paths features. + +## Background + +First we'll consider a project referencing packages. +When the app is published for a specific [Runtime Identifier (RID)](/dotnet/core/rid-catalog), then NuGet package assets for that RID will be copied into the output directory. +When the app is published without a specific RID, all RID specific content will be published in subdirectories, and a `{project}.deps.json` file is created that the .NET runtime loads to determine which directory to use as a probing path. + +Also, be aware that .NET 8 introduces breaking changes regarding [how it determines compatible RIDs from the `.deps.json` file](/dotnet/core/compatibility/deployment/8.0/rid-asset-list) and [which RIDs are recognized by the SDK](/dotnet/core/compatibility/sdk/8.0/rid-graph). + +## Understanding NuGet package asset selection + +There are three types of assets in a NuGet file that are most relevant to this scenario: compile, runtime, and native assets. +For a complete list of asset types, see the docs on [controlling dependency assets in `PackageReference` projects](../consume-packages/Package-References-in-Project-Files.md#controlling-dependency-assets). + +|Asset type|Short Description| +|--|--| +|[compile](#compile-assets)|Managed assemblies passed to the compiler. `ref/{tfm}/` if it exists, otherwise `lib/{tfm}/`.| +|[runtime](#runtime-assets)|Managed assemblies copied to the output directory. `runtimes/{rid}/lib/{tfm}/` if it exists, otherwise `lib/{tfm}/`.| +|[native](#native-assets)|Native libraries copied to the output directory. `runtimes/{rid}/native/`.| + +In all cases, NuGet chooses the "most compatible" directory for a given RID and Target Framework, and only the files in that directory are copied. +Therefore, you cannot put common assets in an inherited RID (such as `any`), because if any other RID is a better match, the `any` RID contents will not be considered. + +To inspect the implementation of NuGet's asset selection, see [`NuGet.Client`'s `ManagedCodeConventions.cs` file](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Packaging/ContentModel/ManagedCodeConventions.cs). + +### Compile assets + +Compile assets are passed to the compiler, and therefore must only contain .NET assemblies. +NuGet will select compile assets from `ref/{tfm}/`, and if that directory does not exist, it will fall back to `lib/{tfm}`, where `{tfm}` is the target framework that is the closest match the project referencing the package. +However, in this scenario of creating a .NET package with native libraries, it is recommended to use `ref/` because if `lib/` is used, NuGet will think the package is compatible with projects using `packages.config`, but those projects will fail at runtime because the native files will not be copied. + +The .NET compiler will generate warnings when an assembly targets a different architecture than what the current compilation is targeting, so your package consumers will have the best experience if your `ref/` or `lib/` assemblies target `AnyCPU`. + +If your assembly contains a lot of managed code, not just P/Invoke method definitions, you can save space by making the `ref/` assembly a [reference assembly](/dotnet/standard/assembly/reference-assemblies#generating-reference-assemblies), but be sure to include it under `ref/` in your package, not `lib/`. + +Therefore, there is no capability to provide different compile-time assemblies for different RIDs, you will need to provide the same API surface for all RIDs, and do runtime checks (for example, throw `PlatformNotSupportedException`). + +### Runtime assets + +Runtime assets are .NET managed assemblies copied to the output directory on build and publish, and the .NET SDK generates the `deps.json` with all the RID-specific asset information. +NuGet will select runtime assets from `runtimes/{rid}/lib/{tfm}/`, and if that doesn't exist, then it will fall back to `lib/{tfm}/`. +The best `{rid}` directory is selected first, followed by `{tfm}`. +However, in this scenario of creating a .NET package with native libraries, it is recommended to use `runtimes/` because if `lib/` is used, NuGet will think the package is compatible with projects using `packages.config`, but those projects will fail at runtime because the native assets will not be copied. + +### Native assets + +Native assets are also copied to the output directory on build and publish, and are present in the `deps.json` file. +NuGet will select native assets from the `runtimes/{rid}/native/` directory. + +> [!NOTE] +> The [.NET SDK flattens any directory structure](https://github.com/dotnet/sdk/issues/9643) under `runtimes/{rid}/native/` when copying to the output directory. + +## Putting it together + +How to build any binaries native libraries is out of scope of this document. +It is assumed that all the native binaries and the .NET assemblies have been completed and copied to a machine for packing. + +When packing with [NuGet's MSBuild Pack target](../reference/msbuild-targets.md#pack-target), you can include arbitrary files in arbitrary package paths using `Pack="true" PackagePath="{path}"` metadata on MSBuild items. +For example, ``. + +Consider a package `Contoso.Native` that provides .NET APIs to `contoso.dll` on Windows, `libcontoso.dylib` on OSX, and `libcontoso.so` on Linux, using `[DllImport("contoso")]`. +The package contents should be (excluding files required by the [Open Packaging Conventions](https://en.wikipedia.org/wiki/Open_Packaging_Conventions)) + +### Example 1 + +If `Contoso.Native` is built as AnyCPU: + +```text +Contoso.Native.1.0.0.nuspec +ref/net8.0/Contoso.Native.dll +runtimes/any/lib/net8.0/Contoso.Native.dll +runtimes/linux-arm64/native/libcontoso.so +runtimes/linux-x64/native/libcontoso.so +runtimes/osx-arm64/native/libcontoso.dylib +runtimes/osx-x64/native/libcontoso.dylib +runtimes/win-arm64/native/contoso.dll +runtimes/win-x64/native/contoso.dll +``` + +While the `ref/` and `runtimes/any/lib` copies of `Contoso.Native.dll` could be deduplicated into a single `lib/net8.0/Contoso.Native.dll` file, this is not recommended because NuGet will believe this package is compatible with projects using `packages.config`, and these projects will fail at runtime when the native `contoso.dll` is not found. + +### Example 2 + +If `Contoso.Native` has any differences between architectures. +For example, but not limited to, using `#if` to compile difference code for different RIDs, or using `` (or anything else that causes `-platform:` to be passed to the compiler) with a value other than `AnyCPU`. + +```text +Contoso.Native.1.0.0.nuspec +ref/net8.0/Contoso.Native.dll +runtimes/linux-arm64/lib/net8.0/Contoso.Native.dll +runtimes/linux-arm64/native/libcontoso.so +runtimes/linux-x64/lib/net8.0/Contoso.Native.dll +runtimes/linux-x64/native/libcontoso.so +runtimes/osx-arm64/lib/net8.0/Contoso.Native.dll +runtimes/osx-arm64/native/libcontoso.dylib +runtimes/osx-x64/lib/net8.0/Contoso.Native.dll +runtimes/osx-x64/native/libcontoso.dylib +runtimes/win-arm64/lib/net8.0/Contoso.Native.dll +runtimes/win-arm64/native/contoso.dll +runtimes/win-x64/lib/net8.0/Contoso.Native.dll +runtimes/win-x64/native/contoso.dll +``` + +### Example 3 + +If `Contoso.Native` has conditional compilation per operating system, but not per CPU architecture. + +```text +Contoso.Native.1.0.0.nuspec +ref/net8.0/Contoso.Native.dll +runtimes/linux/lib/net8.0/Contoso.Native.dll +runtimes/linux-arm64/native/libcontoso.so +runtimes/linux-x64/native/libcontoso.so +runtimes/osx/lib/net8.0/Contoso.Native.dll +runtimes/osx-arm64/native/libcontoso.dylib +runtimes/osx-x64/native/libcontoso.dylib +runtimes/win/lib/net8.0/Contoso.Native.dll +runtimes/win-arm64/native/contoso.dll +runtimes/win-x64/native/contoso.dll +``` + +## Projects Targeting .NET Framework + +.NET has evolved over time, causing project and package incompatibility when certain features are used. +What was described above assumes that the project using the package targets .NET 5 or higher, or .NET Core (`netcoreapp`), which uses the maximum features to simplify the package contents as much as possible. +Projects targeting .NET Standard are not particularly relevant to this document, as those projects can only be class libraries, which cannot be run directly. +However, projects targeting .NET Framework can use either SDK style or non-SDK style projects, and non-SDK style projects may use either `PackageReference` or `packages.config` to use NuGet packages. +All of these combinations have different levels of support, and impose constraints on package authors who wish to support .NET Framework projects using the package. + +Our recommendation is to split the package into 3 packages. +The first is a meta-package (a package with no contents/assets, only dependencies to other packages), that has dependencies to one of the other two packages, depending on target framework. +The second package contains the .NET 5+ `ref/*` and `runtimes/*` assets as described above. +The last package will contain the .NET Framework assets, and will not use the `ref/*` or `runtime/*` conventions. +This is due to the build system having (partial) support for these NuGet conventions, but the runtime working sufficiently differently that it's easier to avoid it, to maximize project compatibility. + +The package with .NET Framework native libraries should have custom [MSBuild targets and props files](../concepts/MSBuild-props-and-targets.md), under `buildTransitive//.[props|targets]`. +For example, `buildTransitive/net472/Contoso.Native.targets`. +To support `packages.config` projects, also have a `build//.[props|targets]` which imports the `buildTransitive` file. +This MSBuild script should copy the native library to subdirectories. +Alternatively, the native libraries should have different filenames per CPU architecture, so they can all be copied into the same directory. + +Finally, the managed library, that uses P/Invoke to call into the native library, it should have runtime checks to determine what platform the current executable is running in (x86, x64, or ARM64), and then P/Invoke into the native library with the correct filename or in the correct subdirectory. + +### SDK style projects targeting .NET Framework + +When the .NET SDK builds a project targeting the .NET Framework, if one of `RuntimeIdentifier` or `PlatformTarget` is set, the .NET SDK will set the other property to an appropriate value, and package `runtimes/` contents (that [follow NuGet's conventions](#understanding-nuget-package-asset-selection)) will be copied to the output directory. +If the project does not set either `RuntimeIdentifier` or `PlatformTarget`, but any package contains RID specific contents, then the .NET SDK will set `PlatformTarget` to `x86`. +Therefore, SDK style projects targeting .NET Framework will only use `AnyCPU` by default when none of the packages contain RID specific content. + +`dotnet build -r `, or the `publish` equivalent (for example, `dotnet publish -r win-arm64`) can be used to explicitly build or publish for a specific platform. + +In order to support `AnyCPU` projects, package authors must not use the `runtimes/` conventions in their package, and must use the MSBuild targets/props files [as suggested above](#projects-targeting-net-framework). + +### Non-SDK style projects targeting .NET Framework with `PackageReference` + +If you test a non-SDK style `PackageReference` project with a package using the `runtimes/*` convention, the following behavior occurs. +If the project's configuration targets the "Any CPU" platform, the build will not copy any of the RID specific assets from the package, and the app will fail at runtime. +Using Visual Studio's Configuration Manager, the .NET projects can be changed to target x64, x86, or ARM64, instead of "Any CPU", in which case the app will work correctly at runtime. + +In order to support `AnyCPU` projects, package authors must use the MSBuild targets/props files [as suggested above](#projects-targeting-net-framework). + +### `packages.config` + +NuGet's original restore style, `packages.config`, does not support `ref/*` or `runtimes/*` conventions. +Therefore, package authors must create their own MSBuild props and targets file to support projects still using `packages.config`. diff --git a/docs/create-packages/set-package-type.md b/docs/create-packages/set-package-type.md index 89acf41e1..048bd1eff 100644 --- a/docs/create-packages/set-package-type.md +++ b/docs/create-packages/set-package-type.md @@ -1,34 +1,136 @@ --- title: Set a NuGet package type description: Describes packages types to indicate intended use of a package. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 07/09/2019 ms.topic: conceptual --- # Set a NuGet package type -With NuGet 3.5+, packages can be marked with a specific *package type* to indicate its intended use. Packages not marked with a type, including all packages created with earlier versions of NuGet, default to the `Dependency` type. +Packages can be marked with one more more *package types* to indicate its intended use. + +## Known package types - `Dependency` type packages add build- or run-time assets to libraries and applications, and can be installed in any project type (assuming they are compatible). -- `DotnetCliTool` type packages are extensions to the [dotnet CLI](/dotnet/articles/core/tools/index) and are invoked from the command line. Such packages can be installed only in .NET Core projects and have no effect on restore operations. More details about these per-project extensions are available in the [.NET Core extensibility](/dotnet/articles/core/tools/extensibility#per-project-based-extensibility) documentation. +- `DotnetTool` type packages are .NET tools that can be installed by the [dotnet CLI](/dotnet/articles/core/tools/index). + +- `MSBuildSdk` type packages are [MSBuild project SDKs](/visualstudio/msbuild/how-to-use-project-sdk) that simplifies using software development kits. + +- `Template` type packages provide [custom templates](/dotnet/core/tools/custom-templates) that can be used to create files or projects like an app, service, tool, or class library. + +- `McpServer` type packages contain MCP servers. This package type is always accompanied by the `DotnetTool` package type, because a local MCP server is distributed as a .NET tool. For information on MCP server and NuGet, see [MCP servers in NuGet packages](../concepts/nuget-mcp.md). + +Packages not marked with a type, including all packages created with earlier versions of NuGet, default to the `Dependency` type. + +> [!NOTE] +> Support for package types was added in NuGet 3.5. +> If you don't need a custom package type, it's best to *not* explicitly set the package type. +> NuGet defaults to the `Dependency` type when no type is specified. + +## Custom package types + +You can mark your package with one or more custom package types if its use does not fit the [known package types](#known-package-types). + +For example, imagine that customers of the `Contoso` app can install extensions. The app could require extension authors to use the custom package type `ContosoExtension` to identify their packages as proper extensions that follow the required conventions. + +> [!WARNING] +> A package with a custom package type cannot be installed by Visual Studio or nuget.exe. See [NuGet/Home#10468](https://github.com/NuGet/Home/issues/10468) for more information. + +# [Using dotnet CLI](#tab/dotnet) + +Package types can be set in the project file (`.csproj`): + +```xml + + + + net5.0 + + ContosoExtension + + + +``` + +Packages with multiple intended uses can be marked with multiple package types using the `;` delimiter: + +```xml + + + + net5.0 + + PackageType1;PackageType2 + -- Custom type packages use an arbitrary type identifier that conforms to the same format rules as package IDs. Any type other than `Dependency` and `DotnetCliTool`, however, are not recognized by the NuGet Package Manager in Visual Studio. + +``` -Package types are set in the `.nuspec` file. It's best for backwards compatibility to *not* explicitly set the `Dependency` type and to instead rely on NuGet assuming this type when no type is specified. +Package types can be versioned using a `,` delimiter between the package type and its [`Version`](/dotnet/api/system.version) string: -- `.nuspec`: Indicate the package type within a `packageTypes\packageType` node under the `` element: +```xml + - ```xml - - - + + net5.0 + + PackageType1, 1.0.0.0;PackageType2 + + + +``` + +# [Using nuget.exe](#tab/nugetexe) + +Package types are set in the `.nuspec` file within a `packageTypes\packageType` node under the `` element: + +```xml + + + + + + + + + +``` + +Packages with multiple intended uses may be marked with multiple package types: + +```xml + + + - + + - - - ``` + + +``` + +Package types can be versioned using a [`Version`](/dotnet/api/system.version) string: + +```xml + + + + + + + + + + +``` + +--- + +The format of a package type string is exactly like a package ID. That is, a package type is a case-insensitive string matching the regular expression `^\w+([_.-]\w+)*$` having at least one character and at most 100 characters. + +If provided, the package type version is a [`Version`](/dotnet/api/system.version) string. The package type version is optional and defaults to `0.0`. diff --git a/docs/docfx.json b/docs/docfx.json index 19ee61793..33e9af360 100644 --- a/docs/docfx.json +++ b/docs/docfx.json @@ -4,7 +4,7 @@ { "files": [ "**/*.md", - "**/**.yml" + "**/*.yml" ], "exclude": [ "**/obj/**", @@ -21,7 +21,6 @@ "**/*.png", "**/*.jpg", "**/*.svg", - "**/*.json", "**/*.xml" ], "exclude": [ @@ -34,18 +33,21 @@ "overwrite": [], "externalReference": [], "globalMetadata": { - "feedback_system": "GitHub", + "ms.service": "nuget", + "uhfHeaderId": "MSDocsHeader-DotNet", + "feedback_system": "Standard", "feedback_github_repo": "NuGet/docs.microsoft.com-nuget", "feedback_product_url": "https://github.com/NuGet/Home/issues/", "breadcrumb_path": "~/_breadcrumb/toc.yml", "ROBOTS": "INDEX,FOLLOW", "ms.topic": "conceptual", - "ms.prod": "nuget", - "author": "karann-msft", - "ms.author": "karann", + "author": "JonDouglas", + "ms.author": "jodou", "ms.reviewer": [ - "karann", - "unnir" + "anangaur", + "jodou", + "chgill", + "jiacjian" ], "ms.workload": [ "dotnet", @@ -55,7 +57,6 @@ "searchScope": [ "NuGet" ], - "uhfHeaderId": "MSDocsHeader-NuGet" }, "fileMetadata": {}, "template": [], diff --git a/docs/faqs/NuGet-FAQ.md b/docs/faqs/NuGet-FAQ.md deleted file mode 100644 index aaaa5e423..000000000 --- a/docs/faqs/NuGet-FAQ.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -title: NuGet Frequently-Asked Questions -description: Common questions and answers for using NuGet on the command line and in Visual Studio -author: shishirx34 -ms.author: shishirh -ms.date: 06/05/2019 -ms.topic: conceptual ---- - -# NuGet frequently-asked questions - -**What is required to run NuGet?** - -All the information around both UI and command-line tools is available in the [Install guide](../install-nuget-client-tools.md). - -**Does NuGet support Mono?** - -The command-line tool, `nuget.exe`, builds and runs under Mono 3.2+ and can create packages in Mono. - -Although `nuget.exe` works fully on Windows, there are known issues on Linux and OS X. Refer to [Mono issues](https://github.com/NuGet/Home/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+mono) on GitHub. - -A [graphical client](https://github.com/mrward/monodevelop-nuget-addin) is available as an add-in for MonoDevelop. - -**How can I determine what a package contains and whether it's stable and useful for my application?** - -The primary source for learning about a package is its listing page on nuget.org (or another private feed). Each package page on nuget.org includes a description of the package, its version history, and usage statistics. The **Info** section on the package page also contains a link to the project's web site where you typically find many examples and other documentation to help you learn how the package is used. - -For more information, see [Finding and choosing packages](../consume-packages/finding-and-choosing-packages.md). - -## NuGet in Visual Studio - -**How is NuGet supported in different Visual Studio products?** - -- Visual Studio on Windows supports the [Package Manager UI](../consume-packages/install-use-packages-visual-studio.md) and the [Package Manager Console](../consume-packages/install-use-packages-powershell.md). -- Visual Studio for Mac has built-in NuGet capabilities as described on [Including a NuGet package in your project](/visualstudio/mac/nuget-walkthrough). -- Visual Studio Code (all platforms) does not have any direct NuGet integration. Use the [NuGet CLI](../reference/nuget-exe-cli-reference.md) or the [dotnet CLI](../reference/dotnet-commands.md). -- Azure DevOps provides [a build step to restore NuGet packages](/vsts/build-release/tasks/package/nuget). You can also [host private NuGet package feeds on Azure DevOps](https://docs.microsoft.com/azure/devops/artifacts/nuget/publish). - -**How do I check the exact version of the NuGet tools that are installed?** - -In Visual Studio, use the **Help > About Microsoft Visual Studio** command and look at the version displayed next to **NuGet Package Manager**. - -Alternatively, launch the Package Manager Console (**Tools > NuGet Package Manager > Package Manager Console**) and enter `$host` to see information about NuGet including the version. - -**What programming languages are supported by NuGet?** - -NuGet generally works for .NET languages and is designed to bring .NET libraries into a project. Because it also supports MSBuild and Visual Studio automation in some project types, it also supports other projects and languages to various degrees. - -The most recent version of NuGet supports C#, Visual Basic, F#, WiX, and C++. - -**What project templates are supported by NuGet?** - -NuGet has full support for a variety of project templates like Windows, Web, Cloud, SharePoint, Wix, and so on. - -**How do I update packages that are part of Visual Studio templates?** - -Go to the **Updates** tab in the Package Manager UI and select **Update All**, or use the [`Update-Package` command](../reference/ps-reference/ps-ref-update-package.md) from the Package Manager Console. - -To update the template itself, you need to manually update the template repository. See [Xavier Decoster's blog](http://www.xavierdecoster.com/update-project-template-to-latest-nuget-packages) on this subject. Note that this is done at your own risk, because manual updates might corrupt the template if the latest version of all dependencies are not compatible with each other. - -**Can I use NuGet outside of Visual Studio?** - -Yes, NuGet works directly from the command line. See the [Install guide](../install-nuget-client-tools.md) and the [CLI reference](../reference/nuget-exe-cli-reference.md). - -## NuGet command line - -**How do I get the latest version of NuGet command line tool?** - -See the [Install guide](../install-nuget-client-tools.md). - -**What is the license for nuget.exe?** - -You are allowed to redistribute nuget.exe under the terms of the MIT license. You are responsible for updating and servicing any copies of nuget.exe that you choose to redistribute. - -**Is it possible to extend the NuGet command line tool?** - -Yes, it's possible to add custom commands to `nuget.exe`, as described in [Rob Reynold's post](http://geekswithblogs.net/robz/archive/2011/07/15/extend-nuget-command-line.aspx). - -## NuGet Package Manager Console (Visual Studio on Windows) - -**How do I get access to the DTE object in the Package Manager console?** - -The top-level object in the Visual Studio automation object model is called the DTE (Development Tools Environment) object. The console provides this through a variable named `$DTE`. For more information, see [Automation Model Overview](/visualstudio/extensibility/internals/automation-model-overview) in the Visual Studio Extensibility documentation. - -**I try to cast the $DTE variable to the type DTE2, but I get an error: Cannot convert the "EnvDTE.DTEClass" value of type "EnvDTE.DTEClass" to type "EnvDTE80.DTE2". What's wrong?** - -This is a known issue with how PowerShell interacts with a COM object. Try the following: - -```ps -`$dte2 = Get-Interface $dte ([EnvDTE80.DTE2])` -``` - -`Get-Interface` is a helper function added by the NuGet PowerShell host. - -## Creating and publishing packages - -**How do I list my package in a feed?** - -See [Creating and publishing a package](../quickstart/create-and-publish-a-package.md). - -**I have multiple versions of my library that target different versions of the .NET Framework. How do I build a single package that supports this?** - -See [Supporting Multiple .NET Framework Versions and Profiles](../create-packages/supporting-multiple-target-frameworks.md). - -**How do I set up my own repository or feed?** - -See the [Hosting packages overview](../hosting-packages/overview.md). - -**How can I upload packages to my NuGet feed in bulk?** - -See [Bulk publishing NuGet packages](http://jeffhandley.com/archive/2012/12/13/Bulk-Publishing-NuGet-Packages.aspx) (jeffhandly.com). - -## Working with packages - -**What is the difference between a project-level package and a solution-level package?** - -A solution-level package (NuGet 3.x+) is installed only once in a solution and is then available for all projects in the solution. A project-level package is installed in each project that uses it. A solution-level package might also install new commands that can be called from within the Package Manager Console. - -**Is it possible to install NuGet packages without Internet connectivity?** - -Yes, see Scott Hanselman's Blog post [How to access NuGet when nuget.org is down (or you're on a plane)](http://www.hanselman.com/blog/HowToAccessNuGetWhenNuGetorgIsDownOrYoureOnAPlane.aspx) (hanselman.com). - -**How do I install packages in a different location from the default packages folder?** - -Set the [`repositoryPath`](../reference/nuget-config-file.md#config-section) setting in `Nuget.Config` using `nuget config -set repositoryPath=`. - -**How do I avoid adding the NuGet packages folder into to source control?** - -Set the [`disableSourceControlIntegration`](../reference/nuget-config-file.md#solution-section) in `Nuget.Config` to `true`. This key works at the solution level and hence need to be added to the `$(Solutiondir)\.nuget\Nuget.Config` file. Enabling package restore from Visual Studio creates this file automatically. - -**How do I turn off package restore?** - -See [Enabling and disabling package restore](../consume-packages/package-restore.md#enable-and-disable-package-restore-visual-studio). - -**Why do I get an "Unable to resolve dependency error" when installing a local package with remote dependencies?** - -You need to select the **All** source when installing a local package into the project. This aggregates all the feeds instead of using just one. The reason this error appears is that users of a local repository often want to avoid accidentally installing a remote package due to corporate polices. - -**I have multiple projects in the same folder, how can I use separate packages.config files for each project?** - -In most projects where separate projects live in separate folders, this is not a problem as NuGet identifies the `packages.config` files in each project. With NuGet 3.3+ and multiple projects in the same folder, you can insert the name of the project into the `packages.config` filenames use the pattern `packages.{project-name}.config`, and NuGet uses that file. - -This is not an issue when using PackageReference, as each project file contains its own list of dependencies. - -**I don't see nuget.org in my list of repositories, how do I get it back?** - -- Add `https://api.nuget.org/v3/index.json` to your list of sources, or -- Delete `%appdata%\.nuget\NuGet.Config` (Windows) or `~/.nuget/NuGet/NuGet.Config` (Mac/Linux) and let NuGet re-create it. diff --git a/docs/guides/Create-NET-Standard-Packages-VS2015.md b/docs/guides/Create-NET-Standard-Packages-VS2015.md index 013eb7228..8d4e839dc 100644 --- a/docs/guides/Create-NET-Standard-Packages-VS2015.md +++ b/docs/guides/Create-NET-Standard-Packages-VS2015.md @@ -1,8 +1,8 @@ --- title: Create .NET Standard and .NET Framework NuGet Packages with Visual Studio 2015 description: An end-to-end walkthrough of creating .NET Standard and .NET Framework NuGet packages using NuGet 3.x and Visual Studio 2015. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 02/02/2018 ms.topic: tutorial --- @@ -120,7 +120,7 @@ If you have any dependencies on other NuGet packages, list those in the manifest     ``` -The syntax of the *version* attribute here indicates that version 8.0.3 or above is acceptable. To specify different version ranges, refer to [Package versioning](../reference/package-versioning.md). +The syntax of the *version* attribute here indicates that version 8.0.3 or above is acceptable. To specify different version ranges, refer to [Package versioning](../concepts/package-versioning.md). ### Adding a readme @@ -164,7 +164,7 @@ Note that `pack` requires Mono 4.4.2 on Mac OS X and does not work on Linux syst - [Supporting multiple .NET framework versions](../create-packages/supporting-multiple-target-frameworks.md) - [Include MSBuild props and targets in a package](../create-packages/creating-a-package.md#include-msbuild-props-and-targets-in-a-package) - [Creating localized packages](../create-packages/creating-localized-packages.md) -- [Symbol packages](../create-packages/symbol-packages.md) -- [Package versioning](../reference/package-versioning.md) +- [Symbol packages](../create-packages/symbol-packages-snupkg.md) +- [Package versioning](../concepts/package-versioning.md) - [.NET Standard Library documentation](/dotnet/articles/standard/library) - [Porting to .NET Core from .NET Framework](/dotnet/articles/core/porting/index) diff --git a/docs/guides/Create-UI-Controls.md b/docs/guides/Create-UI-Controls.md index 04fe7e4a7..80a7b7c8f 100644 --- a/docs/guides/Create-UI-Controls.md +++ b/docs/guides/Create-UI-Controls.md @@ -1,15 +1,15 @@ --- title: How to package UI controls with NuGet description: How to create NuGet packages that contain UWP or WPF controls, including the necessary metadata and supporting files for the Visual Studio and Blend designers. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 05/23/2018 ms.topic: tutorial --- # Creating UI controls as NuGet packages -Starting with Visual Studio 2017, you can take advantage of added capabilities for UWP and WPF controls that you deliver in NuGet packages. This guide walks you through these capabilities in context of UWP controls using the [ExtensionSDKasNuGetPackage sample](https://github.com/NuGet/Samples/tree/master/ExtensionSDKasNuGetPackage). The same applies to WPF controls unless mentioned otherwise. +Starting with Visual Studio 2017, you can take advantage of added capabilities for UWP and WPF controls that you deliver in NuGet packages. This guide walks you through these capabilities in context of UWP controls using the [ExtensionSDKasNuGetPackage sample](https://github.com/NuGet/Samples/tree/main/ExtensionSDKasNuGetPackage). The same applies to WPF controls unless mentioned otherwise. ## Prerequisites @@ -31,17 +31,19 @@ Alternately, edit the the project file to add `true - + @@ -56,6 +58,7 @@ where: - *your_package_file*: the name of your control file, such as `ManagedPackage.winmd` ("ManagedPackage" is an arbitrary named used for this example and has no other meaning). - *vs_category*: The label for the group in which the control should appear in the Visual Studio designer’s toolbox. A `VSCategory` is necessary for the control to appear in the toolbox. +*ui_framework*: The name of the Framework, such as 'WPF', note that `UIFramework` attribute is required on ToolboxItems nodes on Visual Studio 16.7 Preview 3 or above for the control to appear in toolbox. - *blend_category*: The label for the group in which the control should appear in the Blend designer’s Assets pane. A `BlendCategory` is necessary for the control to appear in Assets. - *type_full_name_n*: The fully-qualified name for each control, including the namespace, such as `ManagedPackage.MyCustomControl`. Note that the dot format is used for both managed and native types. @@ -66,7 +69,7 @@ In the following example, the control implemented in `ManagedPackage.winmd` will ```xml - + @@ -82,13 +85,13 @@ In the following example, the control implemented in `ManagedPackage.winmd` will ## Add custom icons to your controls -To display a custom icon in the toolbox/assets pane, add an image to your project or the corresponding `design.dll` project with the name “Namespace.ControlName.extension” and set the build action to “Embedded Resource”. You must also ensure that the associated `AssemblyInfo.cs` specifies the ProvideMetadata attribute - `[assembly: ProvideMetadata(typeof(RegisterMetadata))]`. See this [sample](https://github.com/NuGet/Samples/blob/master/ExtensionSDKasNuGetPackage/NativePackage.Design/Properties/AssemblyInfo.cs#L20). +To display a custom icon in the toolbox/assets pane, add an image to your project or the corresponding `design.dll` project with the name “Namespace.ControlName.extension” and set the build action to “Embedded Resource”. You must also ensure that the associated `AssemblyInfo.cs` specifies the ProvideMetadata attribute - `[assembly: ProvideMetadata(typeof(RegisterMetadata))]`. See this [sample](https://github.com/NuGet/Samples/blob/main/ExtensionSDKasNuGetPackage/NativePackage.Design/Properties/AssemblyInfo.cs#L20). Supported formats are `.png`, `.jpg`, `.jpeg`, `.gif`, and `.bmp`. The recommended format is BMP24 in 16 pixels by 16 pixels. ![Tool box icon sample](https://raw.githubusercontent.com/NuGet/docs.microsoft.com-nuget/live/docs/guides/media/ColorPicker_16x16x24.bmp) -The pink background is replaced at runtime. The icons are recolored when the Visual Studio theme is changed and that background color is expected. For more information, please reference [Images and Icons for Visual Studio](https://docs.microsoft.com/en-us/visualstudio/extensibility/ux-guidelines/images-and-icons-for-visual-studio). +The pink background is replaced at runtime. The icons are recolored when the Visual Studio theme is changed and that background color is expected. For more information, please reference [Images and Icons for Visual Studio](/visualstudio/extensibility/ux-guidelines/images-and-icons-for-visual-studio). In the example below, the project contains an image file named “ManagedPackage.MyCustomControl.png”. @@ -103,38 +106,45 @@ UWP packages have a TargetPlatformVersion (TPV) and TargetPlatformMinVersion (TP For example, let’s say you’ve set the TPMinV for your controls package to Windows 10 Anniversary Edition (10.0; Build 14393), so you want to ensure that the package is consumed only by UWP projects that match that lower bound. To allow your package to be consumed by UWP projects, you must package your controls with the following folder names: - \lib\uap10.0.14393\* - \ref\uap10.0.14393\* +``` +\lib\uap10.0.14393\* +\ref\uap10.0.14393\* +``` NuGet will automatically check the TPMinV of the consuming project, and fail installation if it is lower than Windows 10 Anniversary Edition (10.0; Build 14393) In case of WPF, let's say you would like your WPF controls package to be consumed by projects targeting .NET Framework v4.6.1 or higher. To enforce that, you must package your controls with the following folder names: - \lib\net461\* - \ref\net461\* +``` +\lib\net461\* +\ref\net461\* +``` ## Add design-time support To configure where the control properties show up in the property inspector, add custom adorners, etc., place your `design.dll` file inside the `lib\uap10.0.14393\Design` folder as appropriate to the target platform. Also, to ensure that the **[Edit Template > Edit a Copy](/windows/uwp/controls-and-patterns/xaml-styles#modify-the-default-system-styles)** feature works, you must include the `Generic.xaml` and any resource dictionaries that it merges in the `\Themes` folder (again, using your actual assembly name). (This file has no impact on the runtime behavior of a control.) The folder structure would thus appear as follows: - \lib - \uap10.0.14393 - \Design - \MyControl.design.dll - \your_assembly_name - \Themes - Generic.xaml - +``` +\lib + \uap10.0.14393 + \Design + \MyControl.design.dll + \your_assembly_name + \Themes + Generic.xaml +``` For WPF, continuing with the example where you would like your WPF controls package to be consumed by projects targeting .NET Framework v4.6.1 or higher: - \lib - \net461 - \Design - \MyControl.design.dll - \your_assembly_name - \Themes - Generic.xaml +``` +\lib + \net461 + \Design + \MyControl.design.dll + \your_assembly_name + \Themes + Generic.xaml +``` > [!Note] > By default, control properties will show up under the Miscellaneous category in the property inspector. @@ -143,7 +153,7 @@ For WPF, continuing with the example where you would like your WPF controls pack You can embed string resources (`.resw`) in your package that can be used by your control or the consuming UWP project, set the **Build Action** property of the `.resw` file to **PRIResource**. -For an example, refer to [MyCustomControl.cs](https://github.com/NuGet/Samples/blob/master/ExtensionSDKasNuGetPackage/ManagedPackage/MyCustomControl.cs) in the ExtensionSDKasNuGetPackage sample. +For an example, refer to [MyCustomControl.cs](https://github.com/NuGet/Samples/blob/main/ExtensionSDKasNuGetPackage/ManagedPackage/MyCustomControl.cs) in the ExtensionSDKasNuGetPackage sample. > [!Note] > This is applicable only to UWP controls. @@ -151,4 +161,4 @@ For an example, refer to [MyCustomControl.cs](https://github.com/NuGet/Samples/b ## See also - [Create UWP Packages](create-uwp-packages.md) -- [ExtensionSDKasNuGetPackage sample](https://github.com/NuGet/Samples/tree/master/ExtensionSDKasNuGetPackage) +- [ExtensionSDKasNuGetPackage sample](https://github.com/NuGet/Samples/tree/main/ExtensionSDKasNuGetPackage) diff --git a/docs/guides/Create-UWP-Packages-CS.md b/docs/guides/Create-UWP-Packages-CS.md new file mode 100644 index 000000000..1efb113a9 --- /dev/null +++ b/docs/guides/Create-UWP-Packages-CS.md @@ -0,0 +1,218 @@ +--- +title: Create NuGet Packages for the UWP Platform (C#) +description: An end-to-end walkthrough of creating NuGet packages using a Windows Runtime Component for the Universal Windows Platform in C#. +author: JonDouglas +ms.author: jodou +ms.date: 11/01/2023 +ms.topic: tutorial +--- + +# Create UWP packages (C#) + +The [Universal Windows Platform (UWP)](/windows/uwp) provides a common app platform for every device that runs Windows 10. Within this model, UWP apps can call both the WinRT APIs that are common to all devices, and also APIs (including Win32 and .NET) that are specific to the device family on which the app is running. + +In this walkthrough you create a NuGet package with a C# UWP component (including a XAML control) that can be used in both Managed and Native projects. + +## Prerequisites + +1. Visual Studio 2019. Install the 2019 Community edition for free from [visualstudio.com](https://www.visualstudio.com/). You can also use the Professional and Enterprise editions. + +1. NuGet CLI. Download the latest version of `nuget.exe` from [nuget.org/downloads](https://nuget.org/downloads) and save the tool to a location of your choice. (The download is the `.exe` file directly.) Add the tool file location to your PATH environment variable, if it isn't already. For more information, see [Installing nuget.exe](../reference/nuget-exe-cli-reference.md#installing-nugetexe). + +## Create a UWP Windows Runtime component + +1. In Visual Studio, select **File > New > Project**, and search for "uwp c#". Select the **Windows Runtime Component (Universal Windows)** template and select **Next**. Change the name to ImageEnhancer, and select **Create**. Accept the default values for Target Version and Minimum Version when prompted. + + ![Creating a new UWP Windows Runtime Component project](media/UWP-NewProject-CS.png) + +1. Right-click the project in Solution Explorer, select **Add > New Item**, select **Templated Control**, change the name to AwesomeImageControl.cs, and select **Add**: + + ![Adding a new XAML Templated Control item to the project](media/UWP-NewXAMLControl-CS.png) + +1. Right-click the project in Solution Explorer and select **Properties.** In the Properties page, choose **Build** tab and enable **XML Documentation File**: + + ![Setting Generate XML Documentation Files to Yes](media/UWP-GenerateXMLDocFiles-CS.png) + +1. Right-click the *solution* and select **Batch Build**. Select the five build boxes, as shown in the following image. This makes sure that when you do a build, you generate a full set of artifacts for each of the target systems that Windows supports. + + ![Batch Build](media/UWP-BatchBuild-CS.png) + +1. In the Batch Build dialog, and select **Build** to verify the project and create the output files that you need for the NuGet package. + +> [!Note] +> In this walkthrough you use the Debug artifacts for the package. For non-debug package, check the Release options in the Batch Build dialog instead, and refer to the resulting Release folders in the steps that follow. + +## Create and update the .nuspec file + +To create the initial `.nuspec` file, complete the following steps. The subsequent sections guide you through other necessary updates. + +1. Open a command prompt and browse to the folder that contains the `ImageEnhancer.csproj` file, which should be a subfolder of the folder that contains the solution file. + +1. Run the [`NuGet spec`](../reference/cli-reference/cli-ref-spec.md) command to generate the `ImageEnhancer.nuspec` file. The name of the file is taken from the name of the `.csroj` file. + + ```cli + nuget spec + ``` + +1. Open `ImageEnhancer.nuspec` in an editor and update it to match the following, replacing YOUR_NAME with an appropriate value. Don't leave any of the $propertyName$ values. The `` value, specifically, must be unique across nuget.org (see the naming conventions described in [Creating a package](../create-packages/creating-a-package.md#choose-a-unique-package-identifier-and-setting-the-version-number)). Also note that you must also update the author and description tags or you get an error during the packing step. + + ```xml + + + + ImageEnhancer.YOUR_NAME + 1.0.0 + ImageEnhancer + YOUR_NAME + YOUR_NAME + false + Awesome Image Enhancer + First release + Copyright 2020 + image enhancer imageenhancer + + + ``` + +> [!Note] +> For packages built for public consumption, pay special attention to the `` element, as these tags help others find your package and understand what it does. + +### Adding Windows metadata to the package + +A Windows Runtime Component requires metadata that describes all of its publicly available types, which makes it possible for other apps and libraries to consume the component. This metadata is contained in a .winmd file, which is created when you compile the project and must be included in your NuGet package. An XML file with IntelliSense data is also built at the same time, and should be included as well. + +Add the following `` node to the `.nuspec` file: + +```xml + + + ... + + + + + + + + +``` + +### Adding XAML content + +To include a XAML control with your component, you need to add the XAML file that has the default template for the control (as generated by the project template). This also goes in the `` section: + +```xml + + + + ... + + + ... + + + + + + +``` + +### Adding the native implementation libraries + +Within your component, the core logic of the ImageEnhancer type is in native code, which is contained in the various `ImageEnhancer.winmd` assemblies that are generated for each target runtime (ARM, ARM64, x86, and x64). To include these in the package, reference them in the `` section along with their associated .pri resource files: + +```xml + + + + ... + + + ... + + + + + + + + + + + + + + + + +``` + +### Final .nuspec + +Your final `.nuspec` file should now look like the following, where again YOUR_NAME should be replaced with an appropriate value: + +```xml + + + + ImageEnhancer.YOUR_NAME + 1.0.0 + ImageEnhancer + YOUR_NAME + YOUR_NAME + false + Awesome Image Enhancer + First Release + Copyright 2020 + image enhancer imageenhancer + + + + + + + + + + + + + + + + + + + + + + + + +``` + +## Package the component + +With the completed `.nuspec` referencing all the files you need to include in the package, you're ready to run the [`nuget pack`](../reference/cli-reference/cli-ref-pack.md) command: + +```cli +nuget pack ImageEnhancer.nuspec +``` + +This generates `ImageEnhancer.YOUR_NAME.1.0.0.nupkg`. Opening this file in a tool like the [NuGet Package Explorer](https://github.com/NuGetPackageExplorer/NuGetPackageExplorer) and expanding all the nodes, you see the following contents: + +![NuGet Package Explorer showing the ImageEnhancer package](media/UWP-PackageExplorer.png) + +> [!Tip] +> A `.nupkg` file is just a ZIP file with a different extension. You can also examine package contents, then, by changing `.nupkg` to `.zip`, but remember to restore the extension before uploading a package to nuget.org. + +To make your package available to other developers, follow the instructions on [Publish a package](../nuget-org/publish-a-package.md). + +## Related topics + +- [.nuspec Reference](../reference/nuspec.md) +- [Symbol packages](../create-packages/symbol-packages-snupkg.md) +- [Package versioning](../concepts/package-versioning.md) +- [Supporting Multiple .NET Framework Versions](../create-packages/supporting-multiple-target-frameworks.md) +- [Include MSBuild props and targets in a package](../create-packages/creating-a-package.md#include-msbuild-props-and-targets-in-a-package) +- [Creating Localized Packages](../create-packages/creating-localized-packages.md) \ No newline at end of file diff --git a/docs/guides/Create-UWP-Packages.md b/docs/guides/Create-UWP-Packages.md index d31077e87..dcb17dc79 100644 --- a/docs/guides/Create-UWP-Packages.md +++ b/docs/guides/Create-UWP-Packages.md @@ -1,8 +1,8 @@ --- title: Create NuGet Packages for the Universal Windows Platform description: An end-to-end walkthrough of creating NuGet packages using a Windows Runtime Component for the Universal Windows Platform. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 03/21/2017 ms.topic: tutorial --- @@ -248,8 +248,8 @@ To make your package available to other developers, follow the instructions on ## Related topics - [.nuspec Reference](../reference/nuspec.md) -- [Symbol packages](../create-packages/symbol-packages.md) -- [Package versioning](../reference/package-versioning.md) +- [Symbol packages](../create-packages/symbol-packages-snupkg.md) +- [Package versioning](../concepts/package-versioning.md) - [Supporting Multiple .NET Framework Versions](../create-packages/supporting-multiple-target-frameworks.md) - [Include MSBuild props and targets in a package](../create-packages/creating-a-package.md#include-msbuild-props-and-targets-in-a-package) - [Creating Localized Packages](../create-packages/creating-localized-packages.md) diff --git a/docs/create-packages/Native-Packages.md b/docs/guides/Native-Packages.md similarity index 89% rename from docs/create-packages/Native-Packages.md rename to docs/guides/Native-Packages.md index f4864c1c6..14f5c5353 100644 --- a/docs/create-packages/Native-Packages.md +++ b/docs/guides/Native-Packages.md @@ -1,8 +1,8 @@ --- title: Creating Native NuGet Packages description: Details on creating native NuGet packages that contains C++ code instead of managed code, for use in C++ projects. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 01/09/2017 ms.topic: conceptual --- @@ -16,6 +16,6 @@ To be consumable in a C++ project, a package must target the `native` framework. > [!Note] > Be sure to include *native* in the `` section of your `.nuspec` to help other developers find your package by searching on that tag. -Native NuGet packages targeting `native` then provide files in `\build`, `\content`, and `\tools` folders; `\lib` is not used in this case (NuGet cannot directly add references to a C++ project). A package may also include targets and props files in `\build` that NuGet will automatically import into projects that consume the package. Those files must be named the same as the package ID with the `.targets` and/or `.props` extensions. For example, the [cpprestsdk](https://nuget.org/packages/cpprestsdk/) package includes a `cpprestsdk.targets` file in its `\build` folder. +Native NuGet packages targeting `native` then provide files in `\build`, `\content`, and `\tools` folders; `\lib` is not used in this case (NuGet cannot directly add references to a C++ project). A package may also include targets and props files in `\build` that NuGet will automatically import into projects that consume the package. Those files must be named the same as the package ID with the `.targets` and/or `.props` extensions. For example, the [Microsoft.Web.WebView2](https://www.nuget.org/packages/Microsoft.Web.WebView2) package includes a `Microsoft.Web.WebView2.targets` file in its `\build` folder. The `\build` folder can be used for all NuGet packages and not just native packages. The `\build` folder respects target frameworks just like the `\content`, `\lib`, and `\tools` folders. This means you can create a `\build\net40` folder and a `\build\net45` folder and NuGet will import the appropriate props and targets files into the project. (Use of PowerShell scripts to import MSBuild targets is not needed.) diff --git a/docs/reference/analyzers-conventions.md b/docs/guides/analyzers-conventions.md similarity index 82% rename from docs/reference/analyzers-conventions.md rename to docs/guides/analyzers-conventions.md index eebfb9767..8122c81dc 100644 --- a/docs/reference/analyzers-conventions.md +++ b/docs/guides/analyzers-conventions.md @@ -1,15 +1,15 @@ --- title: .NET Compiler Platform Analyzer Formats for NuGet description: Conventions for .NET analyzers that are packaged and distributed with NuGet packages that implement an API or library. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 01/09/2017 ms.topic: conceptual --- # Analyzer NuGet formats -The .NET Compiler Platform (also known as "Roslyn") allows developers to create [analyzers](https://github.com/dotnet/roslyn/wiki/How-To-Write-a-C%23-Analyzer-and-Code-Fix) that examine the syntax tree and semantics of code as it's being written. This provides developers with a way to create domain-specific analysis tools, such as those that would help guide the use of a particular API or library. You can find more information on the [.NET/Roslyn](https://github.com/dotnet/roslyn/wiki) GitHub wiki. Also see the article, [Use Roslyn to Write a Live Code Analyzer for your API](https://msdn.microsoft.com/magazine/dn879356.aspx) in MSDN Magazine. +The .NET Compiler Platform (also known as "Roslyn") allows developers to create [analyzers](https://github.com/dotnet/roslyn/blob/main/docs/wiki/How-To-Write-a-C%23-Analyzer-and-Code-Fix.md) that examine the syntax tree and semantics of code as it's being written. This provides developers with a way to create domain-specific analysis tools, such as those that would help guide the use of a particular API or library. You can find more information on the [.NET/Roslyn](https://github.com/dotnet/roslyn/wiki) GitHub wiki. Also see the article, [Use Roslyn to Write a Live Code Analyzer for your API](/archive/msdn-magazine/2014/special-issue/csharp-and-visual-basic-use-roslyn-to-write-a-live-code-analyzer-for-your-api) in MSDN Magazine. Analyzers themselves are typically packaged and distributed as part of the NuGet packages that implement the API or library in question. @@ -38,9 +38,11 @@ Also note that because this package has no platform-specific requirements, the ` The use of the `analyzers` folder is similar to that used for [target frameworks](../create-packages/supporting-multiple-target-frameworks.md), except the specifiers in the path describe development host dependencies instead of build-time. The general format is as follows: - $/analyzers/{framework_name}{version}/{supported_architecture}/{supported_language}/{analyzer_name}.dll +``` +$/analyzers/{framework_name}{version}/{supported_architecture}/{supported_language}/{analyzer_name}.dll +``` -- **framework_name**: the *optional* API surface area of the .NET Framework that the contained DLLs need to run. `dotnet` is presently the only valid value because Roslyn is the only host that can run analyzers. If no target is specified, DLLs are assumed to apply to *all* targets. +- **framework_name** and **version**: the *optional* API surface area of the .NET Framework that the contained DLLs need to run. `dotnet` is presently the only valid value because Roslyn is the only host that can run analyzers. If no target is specified, DLLs are assumed to apply to *all* targets. - **supported_language**: the language for which the DLL applies, one of `cs` (C#) and `vb` (Visual Basic), and `fs` (F#). The language indicates that the analyzer should be loaded only for a project using that language. If no language is specified then the DLL is assumed to apply to *all* languages that support analyzers. - **analyzer_name**: specifies the DLLs of the analyzer. If you need additional files beyond DLLs, they must be included through a targets or properties files. diff --git a/docs/guides/api/query-for-all-published-packages.md b/docs/guides/api/query-for-all-published-packages.md index ea7a78af6..6d747555e 100644 --- a/docs/guides/api/query-for-all-published-packages.md +++ b/docs/guides/api/query-for-all-published-packages.md @@ -49,7 +49,9 @@ DateTime cursor = DateTime.UtcNow.AddHours(-1); The location of every resource (endpoint) in the NuGet API should be discovered using the [service index](../../api/service-index.md). Because this guide focuses on nuget.org, we'll be using nuget.org's service index. - GET https://api.nuget.org/v3/index.json +``` +GET https://api.nuget.org/v3/index.json +``` The service document is JSON document containing all of the resources on nuget.org. Look for the resource having the `@type` property value of `Catalog/3.0.0`. The associated `@id` property value is the URL to the catalog index itself. @@ -57,13 +59,17 @@ The service document is JSON document containing all of the resources on nuget.o Using the `@id` property value found in the previous step, download the catalog index: - GET https://api.nuget.org/v3/catalog0/index.json +``` +GET https://api.nuget.org/v3/catalog0/index.json +``` Deserialize the [catalog index](../../api/catalog-resource.md#catalog-index). Filter out all [catalog page objects](../../api/catalog-resource.md#catalog-page-object-in-the-index) with `commitTimeStamp` less than or equal to your current cursor value. For each remaining catalog page, download the full document using the `@id` property. - GET https://api.nuget.org/v3/catalog0/page2926.json +``` +GET https://api.nuget.org/v3/catalog0/page2926.json +``` Deserialize the [catalog page](../../api/catalog-resource.md#catalog-page). Filter out all [catalog leaf objects](../../api/catalog-resource.md#catalog-item-object-in-a-page) with `commitTimeStamp` less than or equal to your current cursor value. @@ -73,9 +79,11 @@ After you have downloaded all of the catalog pages not filtered out, you have a At this point, you can perform any custom processing you'd like on the catalog items. If all you need is the ID and version of the package, you can inspect the `nuget:id` and `nuget:version` properties on the catalog item objects found in the pages. Make sure to look at the `@type` property to know if the catalog item concerns an existing package or a deleted package. -If you are interested in the metadata about the package (such at the description, dependencies, .nupkg size, etc), you can fetch the [catalog leaf document](../../api/catalog-resource.md#catalog-leaf) using the `@id` property. +If you are interested in the metadata about the package (such as the description, dependencies, .nupkg size, etc), you can fetch the [catalog leaf document](../../api/catalog-resource.md#catalog-leaf) using the `@id` property. - GET https://api.nuget.org/v3/catalog0/data/2015.02.01.11.18.40/windowsazure.storage.1.0.0.json +``` +GET https://api.nuget.org/v3/catalog0/data/2015.02.01.11.18.40/windowsazure.storage.1.0.0.json +``` This document has all of the metadata included in the [package metadata resource](../../api/registration-base-url-resource.md), and more! @@ -97,7 +105,7 @@ If, for some reason, you have a bug in how you process catalog leaves, you can s Because the catalog is a set of JSON documents available over HTTP, it can be interacted with using any programming language that has an HTTP client and JSON deserializer. -C# samples are available in the [NuGet/Samples repository](https://github.com/NuGet/Samples/tree/master/CatalogReaderExample). +C# samples are available in the [NuGet/Samples repository](https://github.com/NuGet/Samples/tree/main/CatalogReaderExample). ```cli git clone https://github.com/NuGet/Samples.git @@ -105,11 +113,11 @@ git clone https://github.com/NuGet/Samples.git ### Catalog SDK -The easiest way to consume the catalog is to use the pre-release .NET catalog SDK package: [NuGet.Protocol.Catalog](https://dotnet.myget.org/feed/nuget-build/package/nuget/NuGet.Protocol.Catalog). This package is available on the `nuget-build` MyGet feed, for which you use the NuGet package source URL `https://dotnet.myget.org/F/nuget-build/api/v3/index.json`. +The easiest way to consume the catalog is to use the pre-release .NET catalog SDK package `NuGet.Protocol.Catalog`, which is available on Azure Artifacts using the following NuGet package source URL: `https://pkgs.dev.azure.com/dnceng/public/_packaging/nuget-build/nuget/v3/index.json`. You can install this package to a project compatible with `netstandard1.3` or greater (such as .NET Framework 4.6). -A sample using this package is available on GitHub in the [NuGet.Protocol.Catalog.Sample project](https://github.com/NuGet/Samples/tree/master/CatalogReaderExample/NuGet.Protocol.Catalog.Sample). +A sample using this package is available on GitHub in the [NuGet.Protocol.Catalog.Sample project](https://github.com/NuGet/Samples/tree/main/CatalogReaderExample/NuGet.Protocol.Catalog.Sample). #### Sample output @@ -147,9 +155,9 @@ warn: NuGet.Protocol.Catalog.CatalogProcessor[0] ### Minimal sample -For an example with fewer dependencies that illustrates the interaction with the catalog in more detail, see the [CatalogReaderExample sample project](https://github.com/NuGet/Samples/tree/master/CatalogReaderExample/CatalogReaderExample). The project targets `netcoreapp2.0` and depends on the [NuGet.Protocol 4.4.0](https://www.nuget.org/packages/NuGet.Protocol/4.4.0) (for resolving the service index) and [Newtonsoft.Json 9.0.1](https://www.nuget.org/packages/Newtonsoft.Json/9.0.1) (for JSON deserialization). +For an example with fewer dependencies that illustrates the interaction with the catalog in more detail, see the [CatalogReaderExample sample project](https://github.com/NuGet/Samples/tree/main/CatalogReaderExample/CatalogReaderExample). The project targets `netcoreapp2.0` and depends on the [NuGet.Protocol 4.4.0](https://www.nuget.org/packages/NuGet.Protocol/4.4.0) (for resolving the service index) and [Newtonsoft.Json 9.0.1](https://www.nuget.org/packages/Newtonsoft.Json/9.0.1) (for JSON deserialization). -The main logic of the code is visible in the [Program.cs file](https://github.com/NuGet/Samples/blob/master/CatalogReaderExample/CatalogReaderExample/Program.cs). +The main logic of the code is visible in the [Program.cs file](https://github.com/NuGet/Samples/blob/main/CatalogReaderExample/CatalogReaderExample/Program.cs). #### Sample output diff --git a/docs/guides/create-packages-for-xamarin.md b/docs/guides/create-packages-for-xamarin.md deleted file mode 100644 index 9146c05b9..000000000 --- a/docs/guides/create-packages-for-xamarin.md +++ /dev/null @@ -1,267 +0,0 @@ ---- -title: Create NuGet Packages for Xamarin (for iOS, Android, and Windows) with Visual Studio 2015 -description: An end-to-end walkthrough of creating NuGet packages for Xamarin that use native APIs on iOS, Android, and Windows. -author: karann-msft -ms.author: karann -ms.date: 01/09/2017 -ms.topic: tutorial ---- - -# Create packages for Xamarin with Visual Studio 2015 - -A package for Xamarin contains code that uses native APIs on iOS, Android, and Windows, depending on the run-time operating system. Although this is straightforward to do, it's preferable to let developers consume the package from a PCL or .NET Standard libraries through a common API surface area. - -In this walkthrough you use Visual Studio 2015 create a cross-platform NuGet package that can be used in mobile projects on iOS, Android, and Windows. - -1. [Prerequisites](#prerequisites) -1. [Create the project structure and abstraction code](#create-the-project-structure-and-abstraction-code) -1. [Write your platform-specific code](#write-your-platform-specific-code) -1. [Create and update the .nuspec file](#create-and-update-the-nuspec-file) -1. [Package the component](#package-the-component) -1. [Related topics](#related-topics) - -## Prerequisites - -1. Visual Studio 2015 with Universal Windows Platform (UWP) and Xamarin. Install the Community edition for free from [visualstudio.com](https://www.visualstudio.com/); you can use the Professional and Enterprise editions as well, of course. To include UWP and Xamarin tools, select a Custom install and check the appropriate options. -1. NuGet CLI. Download the latest version of nuget.exe from [nuget.org/downloads](https://nuget.org/downloads), saving it to a location of your choice. Then add that location to your PATH environment variable if it isn't already. - -> [!Note] -> nuget.exe is the CLI tool itself, not an installer, so be sure to save the downloaded file from your browser instead of running it. - -## Create the project structure and abstraction code - -1. Download and run the [Plugin for Xamarin Templates extension](https://marketplace.visualstudio.com/items?itemName=vs-publisher-473885.PluginForXamarinTemplates) for Visual Studio. These templates will make it easy to create the necessary project structure for this walkthrough. -1. In Visual Studio, **File > New > Project**, search for `Plugin`, select the **Plugin for Xamarin** template, change the name to LoggingLibrary, and click OK. - - ![New Blank App (Xamarin.Forms Portable) project in Visual Studio](media/CrossPlatform-NewProject.png) - -The resulting solution contains two PCL projects, along with a variety of platform-specific projects: - -- The PCL named `Plugin.LoggingLibrary.Abstractions (Portable)`, defines the public interface (the API surface area) of the component, in this case the `ILoggingLibrary` interface contained in the ILoggingLibrary.cs file. This is where you define the interface to your library. -- The other PCL, `Plugin.LoggingLibrary (Portable)`, contains code in CrossLoggingLibrary.cs that will locate a platform-specific implementation of the abstract interface at run time. You typically don't need to modify this file. -- The platform-specific projects, such as `Plugin.LoggingLibrary.Android`, each contain contain a native implementation of the interface in their respective LoggingLibraryImplementation.cs files. This is where you build out your library's code. - -By default, the ILoggingLibrary.cs file of the Abstractions project contains an interface definition, but no methods. For the purposes of this walkthrough, add a `Log` method as follows: - -```cs -using System; - -namespace Plugin.LoggingLibrary.Abstractions -{ - /// - /// Interface for LoggingLibrary - /// - public interface ILoggingLibrary - { - /// - /// Log a message - /// - void Log(string text); - } -} -``` - -## Write your platform-specific code - -To implement a platform-specific implementation of the `ILoggingLibrary` interface and its methods, do the following: - -1. Open the `LoggingLibraryImplementation.cs` file of each platform project and add the necessary code. For example (using the `Plugin.LoggingLibrary.Android` project): - - ```cs - using Plugin.LoggingLibrary.Abstractions; - using System; - - namespace Plugin.LoggingLibrary - { - /// - /// Implementation for Feature - /// - public class LoggingLibraryImplementation : ILoggingLibrary - { - /// - /// Log a message - /// - public void Log(string text) - { - throw new NotImplementedException("Called Log on Android"); - } - } - } - ``` - -1. Repeat this implementation in the projects for each platform you want to support. -1. Right-click the iOS project, select **Properties**, click the **Build** tab, and remove "\iPhone" from the **Output path** and **XML documentation file** settings. This is just for later convenience in this walkthrough. Save the file when done. -1. Right-click the solution, select **Configuration Manager...**, and check the **Build** boxes for the PCLs and each platform you're supporting. -1. Right-click the solution and select **Build Solution** to check your work and produce the artifacts that you package next. If you get errors about missing references, right-click the solution, select **Restore NuGet Packages** to install dependencies, and rebuild. - -> [!Note] -> To build for iOS you need a networked Mac connected to Visual Studio as described on [Introduction to Xamarin.iOS for Visual Studio](https://developer.xamarin.com/guides/ios/getting_started/installation/windows/introduction_to_xamarin_ios_for_visual_studio/). If you don't have a Mac available, clear the iOS project in the configuration manager (step 3 above). - -## Create and update the .nuspec file - -1. Open a command prompt, navigate to the `LoggingLibrary` folder that's one level below where the `.sln` file is, and run the NuGet `spec` command to create the initial `Package.nuspec` file: - - ```cli - nuget spec - ``` - -1. Rename this file to `LoggingLibrary.nuspec` and open it in an editor. -1. Update the file to match the following, replacing YOUR_NAME with an appropriate value. The `` value, specifically, must be unique across nuget.org (see the naming conventions described in [Creating a package](../create-packages/creating-a-package.md#choose-a-unique-package-identifier-and-setting-the-version-number)). Also note that you must also update the author and description tags or you get an error during the packing step. - - ```xml - - - - LoggingLibrary.YOUR_NAME - 1.0.0 - LoggingLibrary - YOUR_NAME - YOUR_NAME - false - Awesome application logging utility - First release - Copyright 2016 - logger logging logs - - - ``` - -> [!Tip] -> You can suffix your package version with `-alpha`, `-beta` or `-rc` to mark your package as pre-release, check [Pre-release versions](../create-packages/prerelease-packages.md) for more information about pre-release versions. - -### Add reference assemblies - -To include platform-specific reference assemblies, add the following to the `` element of `LoggingLibrary.nuspec` as appropriate for your supported platforms: - -```xml - - - - - - - - - - - - - - - - - - - - -``` - -> [!Note] -> To shorten the names of the DLL and XML files, right-click on any given project, select the **Library** tab, and change the assembly names. - -### Add dependencies - -If you have specific dependencies for native implementations, use the `` element with `` elements to specify them, for example: - -```xml - - - - - - - - - - - - -``` - -For example, the following would set iTextSharp as a dependency for the UAP target: - -```xml - - - - - -``` - -### Final .nuspec - -Your final `.nuspec` file should now look like the following, where again YOUR_NAME should be replaced with an appropriate value: - -```xml - - - - LoggingLibrary.YOUR_NAME - 1.0.0 - LoggingLibrary - YOUR_NAME - YOUR_NAME - false - Awesome application logging utility - First release - Copyright 2016 - logger logging logs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -``` - -## Package the component - -With the completed `.nuspec` referencing all the files you need to include in the package, you're ready to run the `pack` command: - -```cli -nuget pack LoggingLibrary.nuspec -``` - -This will generate `LoggingLibrary.YOUR_NAME.1.0.0.nupkg`. Opening this file in a tool like the [NuGet Package Explorer](https://github.com/NuGetPackageExplorer/NuGetPackageExplorer) and expanding all the nodes, you see the following contents: - -![NuGet Package Explorer showing the LoggingLibrary package](media/Cross-Platform-PackageExplorer.png) - -> [!Tip] -> A `.nupkg` file is just a ZIP file with a different extension. You can also examine package contents, then, by changing `.nupkg` to `.zip`, but remember to restore the extension before uploading a package to nuget.org. - -To make your package available to other developers, follow the instructions on [Publish a package](../nuget-org/publish-a-package.md). - -## Related topics - -- [Nuspec Reference](../reference/nuspec.md) -- [Symbol packages](../create-packages/symbol-packages.md) -- [Package versioning](../reference/package-versioning.md) -- [Supporting Multiple .NET Framework Versions](../create-packages/supporting-multiple-target-frameworks.md) -- [Include MSBuild props and targets in a package](../create-packages/creating-a-package.md#include-msbuild-props-and-targets-in-a-package) -- [Creating Localized Packages](../create-packages/creating-localized-packages.md) \ No newline at end of file diff --git a/docs/guides/media/BetaChannel-ExtensionUpdate.png b/docs/guides/media/BetaChannel-ExtensionUpdate.png deleted file mode 100644 index af96fe2f9..000000000 Binary files a/docs/guides/media/BetaChannel-ExtensionUpdate.png and /dev/null differ diff --git a/docs/guides/media/BetaChannel-ToolsSettings.png b/docs/guides/media/BetaChannel-ToolsSettings.png deleted file mode 100644 index c5afdc858..000000000 Binary files a/docs/guides/media/BetaChannel-ToolsSettings.png and /dev/null differ diff --git a/docs/guides/media/CrossPlatform-NewProject.png b/docs/guides/media/CrossPlatform-NewProject.png deleted file mode 100644 index 449fa4d0c..000000000 Binary files a/docs/guides/media/CrossPlatform-NewProject.png and /dev/null differ diff --git a/docs/guides/media/NuGet4-01-Workload.png b/docs/guides/media/NuGet4-01-Workload.png deleted file mode 100644 index 67a102c9d..000000000 Binary files a/docs/guides/media/NuGet4-01-Workload.png and /dev/null differ diff --git a/docs/guides/media/NuGet4-02-NewProject.png b/docs/guides/media/NuGet4-02-NewProject.png deleted file mode 100644 index b4f082347..000000000 Binary files a/docs/guides/media/NuGet4-02-NewProject.png and /dev/null differ diff --git a/docs/guides/media/NuGet4-03-PackageExplorer.png b/docs/guides/media/NuGet4-03-PackageExplorer.png deleted file mode 100644 index 30d385833..000000000 Binary files a/docs/guides/media/NuGet4-03-PackageExplorer.png and /dev/null differ diff --git a/docs/guides/media/UWP-BatchBuild-CS.png b/docs/guides/media/UWP-BatchBuild-CS.png new file mode 100644 index 000000000..c0af0602c Binary files /dev/null and b/docs/guides/media/UWP-BatchBuild-CS.png differ diff --git a/docs/guides/media/UWP-GenerateXMLDocFiles-CS.png b/docs/guides/media/UWP-GenerateXMLDocFiles-CS.png new file mode 100644 index 000000000..aee1fe27c Binary files /dev/null and b/docs/guides/media/UWP-GenerateXMLDocFiles-CS.png differ diff --git a/docs/guides/media/UWP-NewProject-CS.png b/docs/guides/media/UWP-NewProject-CS.png new file mode 100644 index 000000000..f99e7c4e6 Binary files /dev/null and b/docs/guides/media/UWP-NewProject-CS.png differ diff --git a/docs/guides/media/UWP-NewXAMLControl-CS.png b/docs/guides/media/UWP-NewXAMLControl-CS.png new file mode 100644 index 000000000..9f580af74 Binary files /dev/null and b/docs/guides/media/UWP-NewXAMLControl-CS.png differ diff --git a/docs/hosting-packages/Local-Feeds.md b/docs/hosting-packages/Local-Feeds.md index 35fb0580b..de95954d3 100644 --- a/docs/hosting-packages/Local-Feeds.md +++ b/docs/hosting-packages/Local-Feeds.md @@ -1,8 +1,8 @@ --- title: Setting up Local NuGet Feeds description: How to create a local feed for NuGet packages using folders on your local network -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 12/06/2017 ms.topic: conceptual --- @@ -20,11 +20,13 @@ To enable the source, add its pathname (such as `\\myserver\packages`) to the li The hierarchical versioned folder tree has the following general structure: - \\myserver\packages - └─ - └─ - ├─..nupkg - └─ +``` +\\myserver\packages + └─ + └─ + ├─..nupkg + └─ +``` NuGet creates this structure automatically when you use the [`nuget add`](../reference/cli-reference/cli-ref-add.md) command to copy a package to the feed: diff --git a/docs/hosting-packages/NuGet-Server.md b/docs/hosting-packages/NuGet-Server.md index e901e89ff..3c237ab33 100644 --- a/docs/hosting-packages/NuGet-Server.md +++ b/docs/hosting-packages/NuGet-Server.md @@ -1,9 +1,9 @@ --- title: Using NuGet.Server to Host NuGet Feeds description: How to create and host a NuGet package feed on any server running IIS using NuGet.Server, making packages available through HTTP and OData. -author: karann-msft -ms.author: karann -ms.date: 03/13/2018 +author: JonDouglas +ms.author: jodou +ms.date: 07/11/2023 ms.topic: conceptual --- @@ -12,6 +12,7 @@ ms.topic: conceptual NuGet.Server is a package provided by the .NET Foundation that creates an ASP.NET application that can host a package feed on any server that runs IIS. Simply said, NuGet.Server makes a folder on the server available through HTTP(S) (specifically OData). It's easy to set up and is best for simple scenarios. 1. Create an empty ASP.NET Web application in Visual Studio and add the NuGet.Server package to it. + - If you are using Visual Studio 2022, you must add the .NET Framework development tools. You need this so that you can create a new **ASP.NET Web Application (.NET Framework)** project. 1. Configure the `Packages` folder in the application and add packages. 1. Deploy the application to a suitable server. @@ -21,54 +22,39 @@ If you have further questions about NuGet.Server, create an issue on [https://gi ## Create and deploy an ASP.NET Web application with NuGet.Server -1. In Visual Studio, select **File > New > Project**, search for "ASP.NET", select the **ASP.NET Web Application (.NET Framework)** template for C#, and set **Framework** to ".NET Framework 4.6": +1. In Visual Studio, select **File > New > Project**, search for "ASP.NET Web Application (.NET Framework)", select the matching template for **C#**. + + ![Select the .NET Framework web project template](media/Hosting_00-NuGet.Server-ProjectType.png) + +1. Set **Framework** to ".NET Framework 4.6". ![Setting the target framework for a new project](media/Hosting_01-NuGet.Server-Set4.6.png) 1. Give the application a suitable name *other* than NuGet.Server, select OK, and in the next dialog select the **Empty** template, then select **OK**. + ![Select the empty web project](media/Hosting_02-NuGet.Server-Empty.png) + 1. Right-click the project, select **Manage NuGet Packages**. 1. In the Package Manager UI, select the **Browse** tab, then search and install the latest version of the NuGet.Server package if you're targeting .NET Framework 4.6. (You can also install it from the Package Manager Console with `Install-Package NuGet.Server`.) Accept the license terms if prompted. - ![Installing the NuGet.Server package](media/Hosting_02-NuGet.Server-Package.png) + ![Installing the NuGet.Server package](media/Hosting_03-NuGet.Server-Package.png) 1. Installing NuGet.Server converts the empty Web application into a package source. It installs a variety of other packages, creates a `Packages` folder in the application, and modifies `web.config` to include additional settings (see the comments in that file for details). > [!Important] > Carefully inspect `web.config` after the NuGet.Server package has completed its modifications to that file. NuGet.Server may not overwrite existing elements but instead create duplicate elements. Those duplicates will cause an "Internal Server Error" when you later try to run the project. For example, if your `web.config` contains `` before installing NuGet.Server, the package doesn't overwrite it but inserts a second ``. In that case, delete the element with the older framework version. -1. To make packages available in the feed when you publish the application to a server, add each `.nupkg` files to the `Packages` folder in Visual Studio, then set each one's **Build Action** to **Content** and **Copy to Output Directory** to **Copy always**: - - ![Copying packages to the Packages folder in the project](media/Hosting_03-NuGet.Server-Package-Folder.png) - -1. Run the site locally in Visual Studio (using **Debug > Start Without Debugging** or Ctrl+F5). The home page provides the package feed URLs as shown below. If you see errors, carefully inspect your `web.config` for duplicate elements are noted earlier with step 5. +1. Run the site locally in Visual Studio (using **Debug > Start Without Debugging** or Ctrl+F5). The home page provides the package feed URLs as shown below. If you see errors, carefully inspect your `web.config` for duplicate elements as noted earlier. ![Default home page for an application with NuGet.Server](media/Hosting_04-NuGet.Server-FeedHomePage.png) -1. Click on **here** in the area outlined above to see the OData feed of packages. - -1. The first time you run the application, NuGet.Server restructures the `Packages` folder to contain a folder for each package. This matches the [local storage layout](http://blog.nuget.org/20151118/nuget-3.3.html#folder-based-repository-commands) introduced with NuGet 3.3 to improve performance. When adding more packages, continue to follow this structure. +1. The first time you run the application, NuGet.Server restructures the `Packages` folder to contain a folder for each package. This matches the [local storage layout](https://blog.nuget.org/20151118/nuget-3.3.html#folder-based-repository-commands) introduced with NuGet 3.3 to improve performance. When adding more packages, continue to follow this structure. 1. Once you've tested your local deployment, deploy the application to any other internal or external site as needed. 1. Once deployed to `http://`, the URL that you use for the package source will be `http:///nuget`. -## Configuring the Packages folder - -With `NuGet.Server` 1.5 and later, you can more specifically configure the package folder using the `appSetting/packagesPath` value in `web.config`: - -```xml - - - - -``` - -`packagesPath` can be an absolute or virtual path. - -When `packagesPath` is omitted or left blank, the packages folder is the default `~/Packages`. - ## Adding packages to the feed externally Once a NuGet.Server site is running, you can add packages using [nuget push](../reference/cli-reference/cli-ref-push.md) provided that you set an API key value in `web.config`. @@ -87,7 +73,7 @@ To enable this capability, set the `apiKey` to a value (ideally a strong passwor ```xml - + @@ -97,12 +83,45 @@ To enable this capability, set the `apiKey` to a value (ideally a strong passwor If your server is already secured or you do not otherwise require an API key (for example, when using a private server on a local team network), you can set `requireApiKey` to `false`. All users with access to the server can then push packages. +Starting with NuGet.Server 3.0.0, the URL for pushing packages was change to `http:///nuget`. Prior to the +3.0.0 release, the push URL was `http:///api/v2/package`. + +With NuGet 3.2.1 and newer, this legacy URL `/api/v2/package` is enabled in addition to `/nuget` by default via +`enableLegacyPushRoute: true` option in your startup config (`NuGetODataConfig.cs` by default). Note that this feature +does not work when multiple feeds are hosted in the same project. + ## Removing packages from the feed With NuGet.Server, the [nuget delete](../reference/cli-reference/cli-ref-delete.md) command removes a package from the repository provided that you include the API key with the comment. If you want to change the behavior to delist the package instead (leaving it available for package restore), change the `enableDelisting` key in `web.config` to true. +## Configuring the Packages folder + +With `NuGet.Server` 1.5 and later, you can customize the package folder using the `appSettings/packagesPath` value in `web.config`: + +```xml + + + + +``` + +`packagesPath` can be an absolute or virtual path. + +When `packagesPath` is omitted or left blank, the packages folder is the default `~/Packages`. + +## Making packages available when you publish the web app + +To make packages available in the feed when you publish the application to a server, add each `.nupkg` files to the `Packages` folder in Visual Studio, then set each one's **Build Action** to **Content** and **Copy to Output Directory** to **Copy always**: + +![Copying packages to the Packages folder in the project](media/Hosting_05-NuGet.Server-Package-Folder.png) + +## Release Notes + +Release notes for NuGet.Server are available on the [GitHub release page](https://github.com/NuGet/NuGet.Server/releases). +This includes details about bug fixes and new features that are added. + ## NuGet.Server support -For additional help using NuGet.Server, create an issue on [https://github.com/nuget/NuGetGallery/issues](https://github.com/nuget/NuGetGallery/issues). \ No newline at end of file +For additional help using NuGet.Server, create an issue on [https://github.com/nuget/NuGetGallery/issues](https://github.com/nuget/NuGetGallery/issues). diff --git a/docs/hosting-packages/Overview.md b/docs/hosting-packages/Overview.md index ed853ea3a..a7d8f686b 100644 --- a/docs/hosting-packages/Overview.md +++ b/docs/hosting-packages/Overview.md @@ -1,9 +1,9 @@ --- title: Overview of Hosting Your Own NuGet Feeds -description: An overview of opens for hosting your own NuGet package feeds or galleries either locally or remotely. -author: karann-msft -ms.author: karann -ms.date: 08/25/2017 +description: An overview of options for hosting your own NuGet package feeds or galleries either locally or remotely. +author: JonDouglas +ms.author: jodou +ms.date: 3/2/2022 ms.topic: conceptual ms.reviewer: anangaur --- @@ -18,19 +18,31 @@ For all such purposes, NuGet supports setting up private package sources in the - NuGet.Server: Packages are made available through a local HTTP server. For details, see [NuGet.Server](../hosting-packages/nuget-server.md). - NuGet Gallery: Packages are hosted on an Internet server using the [NuGet Gallery Project](https://github.com/NuGet/NuGetGallery#build-and-run-the-gallery-in-arbitrary-number-easy-steps) (github.com). NuGet Gallery provides user management and features such as an extensive web UI that allows searching and exploring packages from within the browser, similar to nuget.org. -There are also several other NuGet hosting products that support remote private feeds, including the following: +There are also several other NuGet hosting products such as [Azure Artifacts](https://www.visualstudio.com/docs/package/nuget/publish) and [GitHub package registry](https://help.github.com/articles/configuring-nuget-for-use-with-github-package-registry) that support remote private feeds. Below is a list of such products: +- [Artifactory](https://www.jfrog.com/artifactory/) from JFrog. - [Azure Artifacts](https://www.visualstudio.com/docs/package/nuget/publish), which is also available on Team Foundation Server 2017 and later. -- [MyGet](http://myget.org) -- [ProGet](http://inedo.com/proget) from Inedo +- [BaGet](https://github.com/loic-sharma/BaGet), an open-source implementation of NuGet V3 server built on ASP.NET Core +- [BaGetter](https://github.com/bagetter/BaGetter), an open-source and community driven fork of BaGet +- [Bytesafe](https://docs.bytesafe.dev/package-managers/nuget/) A fully managed package and supply chain security platform +- [Cloudsmith](https://cloudsmith.io/l/nuget-feed/), a fully managed package management SaaS +- [Feedz.io](https://feedz.io) a fully managed package management SaaS +- [Gitea](https://gitea.io), an open-source, self-hostable Git service supports NuGet as a [package registry](https://docs.gitea.io/en-us/usage/packages/nuget/) - [GitHub package registry](https://help.github.com/articles/configuring-nuget-for-use-with-github-package-registry) -- [NuGet Server](http://nugetserver.net/), a community project from Inedo -- [NuGet Server (Open Source)](http://nuget-server.net), an open-source implementation similar to Inedo's NuGet Server +- [GitLab Package Registry](https://docs.gitlab.com/ee/user/packages/nuget_repository/) +- [JetBrains Space](https://www.jetbrains.com/help/space/nuget-feed.html) - [LiGet](https://github.com/ai-traders/liget), an open-source implementation of NuGet V2 server that runs on kestrel in docker -- [BaGet](https://github.com/loic-sharma/BaGet), an open-source implementation of NuGet V3 server built on ASP.NET Core +- [MyGet](https://myget.org) +- [Nexus Repository OSS](https://www.sonatype.com/products/sonatype-nexus-oss-download) from Sonatype. +- [NuGet Server (Open Source)](https://github.com/svenkle/nuget-server), an open-source implementation similar to Inedo's NuGet Server +- [NuGet Server](http://nugetserver.net/), a community project from Inedo +- [ProGet](https://inedo.com/proget) from Inedo - [Sleet](https://github.com/emgarten/sleet), an open-source NuGet V3 static feed generator -- [Artifactory](https://www.jfrog.com/artifactory/) from JFrog. -- [Nexus](http://www.sonatype.org/nexus/) from Sonatype. - [TeamCity](https://www.jetbrains.com/teamcity/) from JetBrains. +- [RepoFlow](https://www.repoflow.io), a simple and easy-to-use package management platform. Regardless of how packages are hosted, you access them by adding them to the list of available sources in `NuGet.Config`. This can be done in Visual Studio as described in [Package Sources](../consume-packages/install-use-packages-visual-studio.md#package-sources), or from the command line using [`nuget sources`](../reference/cli-reference/cli-ref-sources.md). The path to a source can be a local folder pathname, a network name, or a URL. + +[NuGet's V3 protocol](../api/overview.md) uses a [service index](../api//service-index.md) that contains a list of URLs used by various NuGet operations. +All of the URLs in the service index must be accessible by developer and CI machines to avoid unexpected errors. +When installing any NuGet feed, it is important to validate that none of the service index resources are blocked by a company firewall, or if your network is disconnected from the Internet, that all service index resources are available on your private network. diff --git a/docs/hosting-packages/media/Hosting_00-NuGet.Server-ProjectType.png b/docs/hosting-packages/media/Hosting_00-NuGet.Server-ProjectType.png new file mode 100644 index 000000000..423722608 Binary files /dev/null and b/docs/hosting-packages/media/Hosting_00-NuGet.Server-ProjectType.png differ diff --git a/docs/hosting-packages/media/Hosting_01-NuGet.Server-Set4.6.png b/docs/hosting-packages/media/Hosting_01-NuGet.Server-Set4.6.png index 90592325e..cfab83a18 100644 Binary files a/docs/hosting-packages/media/Hosting_01-NuGet.Server-Set4.6.png and b/docs/hosting-packages/media/Hosting_01-NuGet.Server-Set4.6.png differ diff --git a/docs/hosting-packages/media/Hosting_02-NuGet.Server-Empty.png b/docs/hosting-packages/media/Hosting_02-NuGet.Server-Empty.png new file mode 100644 index 000000000..daf3094bf Binary files /dev/null and b/docs/hosting-packages/media/Hosting_02-NuGet.Server-Empty.png differ diff --git a/docs/hosting-packages/media/Hosting_02-NuGet.Server-Package.png b/docs/hosting-packages/media/Hosting_02-NuGet.Server-Package.png deleted file mode 100644 index 1ecc47dca..000000000 Binary files a/docs/hosting-packages/media/Hosting_02-NuGet.Server-Package.png and /dev/null differ diff --git a/docs/hosting-packages/media/Hosting_03-NuGet.Server-Package-Folder.png b/docs/hosting-packages/media/Hosting_03-NuGet.Server-Package-Folder.png deleted file mode 100644 index 97566ebfa..000000000 Binary files a/docs/hosting-packages/media/Hosting_03-NuGet.Server-Package-Folder.png and /dev/null differ diff --git a/docs/hosting-packages/media/Hosting_03-NuGet.Server-Package.png b/docs/hosting-packages/media/Hosting_03-NuGet.Server-Package.png new file mode 100644 index 000000000..ee3e8e95f Binary files /dev/null and b/docs/hosting-packages/media/Hosting_03-NuGet.Server-Package.png differ diff --git a/docs/hosting-packages/media/Hosting_04-NuGet.Server-FeedHomePage.png b/docs/hosting-packages/media/Hosting_04-NuGet.Server-FeedHomePage.png index b5eafb057..24e82a334 100644 Binary files a/docs/hosting-packages/media/Hosting_04-NuGet.Server-FeedHomePage.png and b/docs/hosting-packages/media/Hosting_04-NuGet.Server-FeedHomePage.png differ diff --git a/docs/hosting-packages/media/Hosting_05-NuGet.Server-Package-Folder.png b/docs/hosting-packages/media/Hosting_05-NuGet.Server-Package-Folder.png new file mode 100644 index 000000000..b3eb68d0c Binary files /dev/null and b/docs/hosting-packages/media/Hosting_05-NuGet.Server-Package-Folder.png differ diff --git a/docs/includes/install-cli.md b/docs/includes/install-cli.md index 6d6429b71..f8a68be7b 100644 --- a/docs/includes/install-cli.md +++ b/docs/includes/install-cli.md @@ -1,30 +1,53 @@ -#### Windows +--- +title: Include +description: Installation steps for the nuget.exe CLI tool on Windows, macOS, and Linux. +author: JonDouglas +ms.author: jodou +ms.date: 11/03/2023 +ms.topic: include +--- -> [!Note] -> NuGet.exe 5.0 and later require .NET Framework 4.7.2 or later to execute. +# [Windows](#tab/windows) -1. Visit [nuget.org/downloads](https://nuget.org/downloads) and select NuGet 3.3 or higher (2.8.6 is not compatible with Mono). The latest version is always recommended, and 4.1.0+ is required to publish packages to nuget.org. -1. Each download is the `nuget.exe` file directly. Instruct your browser to save the file to a folder of your choice. The file is *not* an installer; you won't see anything if you run it directly from the browser. -1. Add the folder where you placed `nuget.exe` to your PATH environment variable to use the CLI tool from anywhere. +Always install the **latest** version of the tool that supports your configuration. -#### macOS/Linux +- You can download the latest recommended version at `https://dist.nuget.org/win-x86-commandline/latest/nuget.exe`. +- If you already have the `nuget.exe` CLI tool installed, you can update the tool to the latest version with the command `nuget update -self`. +- For compatibility with older continuous integration systems, a previous URL, `https://nuget.org/nuget.exe` currently provides the [deprecated version 2.8.6](https://github.com/NuGet/NuGetGallery/issues/5381) of the CLI tool. -Behaviors may vary slightly by OS distribution. +1. Visit [nuget.org/downloads](https://nuget.org/downloads) and download NuGet version 3.3 or later. -1. Install [Mono 4.4.2 or later](http://www.mono-project.com/docs/getting-started/install/). + - Version 5.0 and later requires the .NET Framework version 4.7.2 or later. + - Version 4.1.0 and later is required to publish packages to `nuget.org`. + - Version 2.8.6 isn't compatible with [Mono](https://www.mono-project.com/docs/getting-started/install/). + +1. Each download is the `nuget.exe` file directly. Instruct your browser to save the file to a folder of your choice. The download file isn't an installer, so you don't see anything if you run the file directly from the browser. + +1. To use the CLI tool from anywhere, add the folder location for the `nuget.exe` file to your PATH environment variable. + +# [macOS / Linux](#tab/macos+linux) + +Behaviors can vary slightly based on your operating system distribution. + +> [!NOTE] +> Visual Studio for Mac is scheduled for retirement by August 31, 2024 in accordance with [Microsoft's Modern Lifecycle Policy](/lifecycle/policies/modern). For more information, see [What's happening to Visual Studio for Mac](/visualstudio/mac/what-happened-to-vs-for-mac). + +1. Install [Mono version 4.4.2 or later](https://www.mono-project.com/docs/getting-started/install/). 1. Execute the following command at a shell prompt: - ```bash - # Download the latest stable `nuget.exe` to `/usr/local/bin` - sudo curl -o /usr/local/bin/nuget.exe https://dist.nuget.org/win-x86-commandline/latest/nuget.exe - ``` + ```bash + # Download the latest stable `nuget.exe` to `/usr/local/bin` + sudo curl -o /usr/local/bin/nuget.exe https://dist.nuget.org/win-x86-commandline/latest/nuget.exe + ``` + +1. Create an alias by adding the following script to the appropriate file for your operating system (typically `~/.bash_aliases` or `~/.bash_profile`): -1. Create an alias by adding the following script to the appropriate file for your OS (typically `~/.bash_aliases` or `~/.bash_profile`): + ```bash + # Create as alias for nuget + alias nuget="mono /usr/local/bin/nuget.exe" + ``` - ```bash - # Create as alias for nuget - alias nuget="mono /usr/local/bin/nuget.exe" - ``` +1. Reload the shell. Test the installation by entering the command `nuget` with no parameters. NuGet CLI help should display. -1. Reload the shell. Test the installation by entering `nuget` with no parameters. NuGet CLI help should display. +--- \ No newline at end of file diff --git a/docs/includes/nugetsolver-tool.md b/docs/includes/nugetsolver-tool.md new file mode 100644 index 000000000..3b06bad0e --- /dev/null +++ b/docs/includes/nugetsolver-tool.md @@ -0,0 +1,12 @@ +--- +title: Include +description: Suggest NuGetSolver experimental tool. +author: ErickYondon +ms.author: eryondon +ms.date: 1/16/2024 +ms.topic: include +--- + +> [!Tip] +> **Alternative solution**: NuGetSolver is a Visual Studio Extension developed by Microsoft DevLabs, designed to assist in resolving dependency conflicts. It automates the process of identifying and addressing these issues. For further details, visit the [NuGetSolver](https://marketplace.visualstudio.com/items?itemName=vsext.NuGetSolver) page on the Visual Studio Marketplace and we'd love to hear your feedback about your experience. + diff --git a/docs/index.md b/docs/index.md deleted file mode 100644 index 4221df4cc..000000000 --- a/docs/index.md +++ /dev/null @@ -1,244 +0,0 @@ ---- -title: NuGet Documentation -description: NuGet is the package manager for Microsoft development platforms including .NET. The NuGet client tools provide the ability to create and consume packages. -author: karann-msft -ms.author: karann -ms.date: 02/12/2018 -ms.topic: overview -layout: HubPage -hide_bc: true ---- -
    -
    -

    NuGet Documentation

    - -
    diff --git a/docs/index.yml b/docs/index.yml new file mode 100644 index 000000000..602660403 --- /dev/null +++ b/docs/index.yml @@ -0,0 +1,148 @@ +### YamlMime:Hub +title: NuGet documentation +summary: NuGet is the package manager for .NET. It enables developers to create, share, and consume useful .NET libraries. NuGet client tools provide the ability to produce and consume these libraries as "packages". +brand: nuget +metadata: + title: NuGet documentation | Microsoft Docs + titleSuffix: "" + description: NuGet is the package manager for Microsoft development platforms including .NET. The NuGet client tools provide the ability to create and consume packages. + ms.topic: hub-page + author: JonDouglas + ms.author: jodou + ms.date: 03/03/2025 + +highlightedContent: + items: + - title: What is NuGet? + itemType: overview + url: ./what-is-nuget.md + - title: Install NuGet client tools + itemType: download + url: ./install-nuget-client-tools.md + - title: Learn NuGet + itemType: video + url: https://aka.ms/Nuget101 + - title: NuGet.org + itemType: overview + url: ./nuget-org/overview-nuget-org.md + + +conceptualContent: + title: Consume, create, and publish packages + items: + - title: Get started + links: + - text: Install NuGet client tools + itemType: download + url: ./install-nuget-client-tools.md + - text: Install and use a package - dotnet CLI + itemType: quickstart + url: ./quickstart/install-and-use-a-package-using-the-dotnet-cli.md + - text: Install and use a package - Visual Studio + itemType: quickstart + url: ./quickstart/install-and-use-a-package-in-visual-studio.md + - text: Create a package - dotnet CLI + itemType: quickstart + url: ./quickstart/create-and-publish-a-package-using-the-dotnet-cli.md + - text: Create a package - Visual Studio + itemType: quickstart + url: ./quickstart/create-and-publish-a-package-using-visual-studio.md + - text: Create a .NET Framework package - Visual Studio + itemType: quickstart + url: ./quickstart/create-and-publish-a-package-using-visual-studio-net-framework.md + - title: Consume packages + links: + - text: Workflow (overview) + itemType: overview + url: ./consume-packages/overview-and-workflow.md + - text: Find and choose packages + itemType: get-started + url: ./consume-packages/finding-and-choosing-packages.md + - text: Use Visual Studio + itemType: how-to-guide + url: ./consume-packages/install-use-packages-visual-studio.md + - text: Use dotnet CLI + itemType: how-to-guide + url: ./consume-packages/install-use-packages-dotnet-cli.md + - text: Use nuget.exe CLI + itemType: how-to-guide + url: ./consume-packages/install-use-packages-nuget-cli.md + - text: Use Package Manager Console + itemType: how-to-guide + url: ./consume-packages/install-use-packages-powershell.md + - title: Create packages + links: + - text: Workflow (overview) + itemType: overview + url: ./create-packages/overview-and-workflow.md + - text: Use Visual Studio + itemType: how-to-guide + url: ./quickstart/create-and-publish-a-package-using-visual-studio.md + - text: Use dotnet CLI + itemType: how-to-guide + url: ./create-packages/creating-a-package-dotnet-cli.md + - text: Use nuget.exe CLI + itemType: how-to-guide + url: ./create-packages/creating-a-package.md + - text: Use MSBuild + itemType: how-to-guide + url: ./create-packages/creating-a-package-msbuild.md + - text: Support multiple target frameworks + itemType: reference + url: ./create-packages/multiple-target-frameworks-project-file.md + - title: Publish packages + links: + - text: Publish to NuGet.org + itemType: overview + url: ./nuget-org/publish-a-package.md + - text: Publish to a private feed + itemType: overview + url: ./hosting-packages/overview.md + +additionalContent: + sections: + - title: Reference and resources + items: + - title: NuGet.org + links: + - text: Overview + url: ./nuget-org/overview-nuget-org.md + - text: Individual accounts + url: ./nuget-org/individual-accounts.md + - text: Organizations + url: ./nuget-org/organizations-on-nuget-org.md + - text: API keys + url: ./nuget-org/scoped-api-keys.md + - text: Publish a package + url: ./nuget-org/publish-a-package.md + - title: Reference + links: + - text: dotnet CLI + url: ./reference/dotnet-commands.md + - text: nuget.exe CLI + url: ./reference/nuget-exe-cli-reference.md + - text: Package references + url: ./consume-packages/package-references-in-project-files.md + - text: pack and restore as MSBuild targets + url: ./reference/msbuild-targets.md + - text: .nuspec + url: ./reference/nuspec.md + - text: nuget.config + url: ./reference/nuget-config-file.md + - text: NuGet API + url: ./api/overview.md + - title: Resources + links: + - text: Policies - NuGet + url: ./policies/governance.md + - text: Policies - NuGet.org + url: ./nuget-org/policies/data-requests.md + - text: Release notes + url: ./release-notes/known-issues.md + - text: FAQ - NuGet + url: ./resources/nuget-faq.yml + - text: FAQ - NuGet.org + url: ./nuget-org/nuget-org-faq.yml + + + footer: "[Blogs](https://devblogs.microsoft.com/nuget/) - [Twitter](https://twitter.com/nuget) - [Stack Overflow](https://stackoverflow.com/questions/tagged/nuget)" \ No newline at end of file diff --git a/docs/install-nuget-client-tools.md b/docs/install-nuget-client-tools.md index ac1f7e5b4..1a2915b63 100644 --- a/docs/install-nuget-client-tools.md +++ b/docs/install-nuget-client-tools.md @@ -1,9 +1,9 @@ --- -title: Installing NuGet client tools -description: Guidance on installing client tools, the dotnet and nuget command-line interfaces (CLI), and the Package Manager for Visual Studio. -author: karann-msft -ms.author: karann -ms.date: 06/20/2019 +title: Install NuGet client tools +description: Learn how to install and use the dotnet and NuGet client command-line interface (CLI) tools and the Package Manager tool for Visual Studio. +author: JonDouglas +ms.author: jodou +ms.date: 03/03/2025 ms.topic: quickstart --- @@ -11,98 +11,132 @@ ms.topic: quickstart > **Looking to install a package? See [Ways to install NuGet packages](consume-packages/overview-and-workflow.md#ways-to-install-a-nuget-package).** -To work with NuGet, as a package consumer or creator, you can use command-line interface (CLI) tools as well as NuGet features in Visual Studio. This article briefly outlines the capabilities of the different tools, how to install them, and their comparative [feature availability](#feature-availability). To get started using NuGet to consume packages, see [Install and use a package (dotnet CLI)](quickstart/install-and-use-a-package-using-the-dotnet-cli.md) and [Install and use a package (Visual Studio)](quickstart/install-and-use-a-package-in-visual-studio.md). To get started creating NuGet packages, see [Create and publish a NET Standard package (dotnet CLI)](quickstart/create-and-publish-a-package-using-the-dotnet-cli.md) and [Create and publish a NET Standard package (Visual Studio)](quickstart/create-and-publish-a-package-using-visual-studio.md). +To work with NuGet as a package consumer or creator, you can use command-line interface (CLI) tools and NuGet features in Visual Studio. This article briefly outlines the capabilities of the different tools, how to install them, and their comparative [feature availability](#feature-availability). -| Tool                | Description | Download          | -|:------------- |:-------------|:-----| -| [dotnet.exe](#dotnetexe-cli) | CLI tool for .NET Core and .NET Standard libraries, and for any [SDK-style project](resources/check-project-format.md) such as one that targets .NET Framework. Included with the .NET Core SDK and provides core NuGet features on all platforms. (Starting in Visual Studio 2017, the dotnet CLI is automatically installed with any .NET Core related workloads.)| [.NET Core SDK](https://www.microsoft.com/net/download/) | -| [nuget.exe](#nugetexe-cli) | CLI tool for .NET Framework libraries and for any [non-SDK-style project](resources/check-project-format.md) such as one that targets .NET Standard libraries. Provides all NuGet capabilities on Windows, provides most features on Mac and Linux when running under Mono. | [nuget.exe](https://dist.nuget.org/win-x86-commandline/latest/nuget.exe) | -| [Visual Studio](#visual-studio) | On Windows, provides NuGet capabilities through the Package Manager UI and Package Manager Console; included with .NET-related workloads. On Mac, provides certain features through the UI. In Visual Studio Code, NuGet features are provided through extensions. | [Visual Studio 2017](https://www.visualstudio.com/downloads/) | +To get started using NuGet to consume packages, see the following articles: -The [MSBuild CLI](reference/msbuild-targets.md) also provides the ability to restore and create packages, which is primarily useful on build servers. MSBuild is not a general-purpose tool for working with NuGet. +- [Install and use a package (dotnet CLI)](quickstart/install-and-use-a-package-using-the-dotnet-cli.md) +- [Install and use a package (Visual Studio on Windows)](quickstart/install-and-use-a-package-in-visual-studio.md) -## CLI tools +To get started creating NuGet packages, see these articles: -The two NuGet CLI tools are `dotnet.exe` and `nuget.exe`. See [feature availability](#feature-availability) for a comparison. +- [Create and publish a NET Standard package (dotnet CLI)](quickstart/create-and-publish-a-package-using-the-dotnet-cli.md) +- [Create and publish a NET Standard package (Visual Studio on Windows)](quickstart/create-and-publish-a-package-using-visual-studio.md) -* To target .NET Core or .NET Standard, use the dotnet CLI. The `dotnet` CLI is required for the SDK-style project format, which uses the [SDK attribute](/dotnet/core/tools/csproj#additions). -* To target .NET Framework (non-SDK-style project only), use the `nuget.exe` CLI. If the project is migrated from `packages.config` to PackageReference, use the dotnet CLI. +| Tool | Description | Download | +|---|---|---| +| [dotnet SDK](#dotnet-sdk) | The CLI tool for .NET Core and .NET Standard libraries, and for any [SDK-style project](resources/check-project-format.md) such as one that targets the .NET Framework. This CLI tool is included with the .NET Core SDK and provides core NuGet features on all platforms. In Visual Studio 2017 and later, the dotnet CLI is automatically installed with any .NET Core related workloads. | [.NET Core SDK](https://www.microsoft.com/net/download/) | +| [nuget.exe](#nugetexe-cli) | The CLI tool for .NET Framework libraries and for any [**non**-SDK-style project](resources/check-project-format.md) such as one that targets .NET Standard libraries. This CLI tool provides all NuGet capabilities on Windows and most features on Mac and Linux when running under [Mono](https://www.mono-project.com/docs/getting-started/install/). | [nuget.exe](https://dist.nuget.org/win-x86-commandline/latest/nuget.exe) | +| [Visual Studio](#visual-studio) | On Windows, the **NuGet Package Manager** is included with Visual Studio 2012 and later. Visual Studio provides the [Package Manager UI](consume-packages/install-use-packages-visual-studio.md) and the [Package Manager Console (PowerShell on Windows)](consume-packages/install-use-packages-powershell.md). You can use these tools to run most NuGet operations. | [Visual Studio](https://www.visualstudio.com/downloads/) | +| [Visual Studio for Mac](/visualstudio/mac/nuget-walkthrough) | On Mac, certain NuGet capabilities are built in directly. Package Manager Console isn't currently available. For other capabilities, use the dotnet SDK or `nuget.exe` CLI tools. | [Visual Studio for Mac](https://visualstudio.microsoft.com/vs/mac/) | +| [Visual Studio Code](https://code.visualstudio.com/docs) | On Windows, Mac, and Linux, NuGet capabilities are available through marketplace extensions, or use the dotnet SDK or `nuget.exe` CLI tools. | [Visual Studio Code](https://code.visualstudio.com/Download/) | -### dotnet.exe CLI +> [!NOTE] +> Visual Studio for Mac is scheduled for retirement by August 31, 2024 in accordance with [Microsoft's Modern Lifecycle Policy](/lifecycle/policies/modern). For more information, see [What's happening to Visual Studio for Mac](/visualstudio/mac/what-happened-to-vs-for-mac). -The .NET Core 2.0 CLI, `dotnet.exe`, works on all platforms (Windows, Mac, and Linux) and provides core NuGet features such as installing, restoring, and publishing packages. `dotnet` provides direct integration with .NET Core project files (such as `.csproj`), which is helpful in most scenarios. `dotnet` is also built directly for each platform and does not require you to install Mono. +The [MSBuild CLI](reference/msbuild-targets.md) also restores and creates packages. MSBuild isn't a general-purpose tool for working with NuGet. This CLI tool is primarily useful on build servers. -Installation: +Package Manager Console commands work only within Visual Studio on Windows and don't work within other PowerShell environments. -- On developer computers, install the [.NET Core SDK](https://aka.ms/dotnetcoregs). Starting in Visual Studio 2017, the dotnet CLI is automatically installed with any .NET Core related workloads. -- For build servers, follow the instructions on [Using .NET Core SDK and tools in Continuous Integration](/dotnet/core/tools/using-ci-with-cli). +## Support policy -To learn how to use basic commands with the dotnet CLI, see [Install and use packages using the dotnet CLI](consume-packages/install-use-packages-dotnet-cli.md). +The Visual Studio for Windows support policy can be found at [Visual Studio Product Lifecycle and Servicing](/visualstudio/productinfo/vs-servicing). -### nuget.exe CLI -The `nuget.exe` CLI, `nuget.exe`, is the command-line utility for Windows that provides all NuGet capabilities; it can also be run on Mac OSX and Linux using [Mono](http://www.mono-project.com/docs/getting-started/install/) with some limitations. +The most recent version of NuGet.exe is fully supported and can be relied on for bug fixes, updates, and enhancements. +For more information on NuGet.exe's support policy, see the [Microsoft Modern Lifecycle Policy](https://aka.ms/lifecycle). -To learn how to use basic commands with the `nuget.exe` CLI, see [Install and use packages using the nuget.exe CLI](consume-packages/install-use-packages-nuget-cli.md). -Installation: +The .NET SDK support policy can be found at [.NET and .NET Core Support Policy](https://dotnet.microsoft.com/platform/support/policy/dotnet-core). -[!INCLUDE [install-cli](includes/install-cli.md)] +### Patch Releases -> [!Tip] -> Use `nuget update -self` on Windows to update an existing nuget.exe to the latest version. +Patched versions of NuGet.exe will be released exclusively when critical security fixes are required for a long-term support (LTS) version of Visual Studio or .NET SDK. -> [!Note] -> The latest recommended NuGet CLI is always available at `https://dist.nuget.org/win-x86-commandline/latest/nuget.exe`. For compatibility purposes with older continuous integration systems, a previous URL, `https://nuget.org/nuget.exe` currently provides the [deprecated 2.8.6 CLI tool](https://github.com/NuGet/NuGetGallery/issues/5381). +All security bugs should be reported to the Microsoft Security Response Center (MSRC) at [MSRC's report page](https://aka.ms/opensource/security/create-report). +Also, see the [security policy in the NuGet.Client repo](https://github.com/NuGet/NuGet.Client/blob/dev/SECURITY.md). + +### NuGet.exe unlisting + +Out-of-support, deprecated, or vulnerable NuGet.exe versions will be removed from [tools.json](./api/tools-json.md). ## Visual Studio -- Visual Studio Code: NuGet capabilities are available through marketplace extensions, or use the `dotnet.exe` or `nuget.exe` CLI tools. +In Visual Studio 2017 and later, the Visual Studio installer includes the NuGet Package Manager with any workload that employs .NET. + +You can also install the Package Manager separately or verify your installation. Run the Visual Studio installer and check the option setting under **Individual Components > Code tools > NuGet package manager**. For more information, see [Install and manage packages in Visual Studio by using the NuGet Package Manager](consume-packages/install-use-packages-visual-studio.md). + +> [!NOTE] +> For earlier versions of Visual Studio, you can download NuGet extensions at [https://dist.nuget.org/index.html](https://dist.nuget.org/index.html). + +## CLI tools + +You can use either the dotnet CLI or the `nuget.exe` CLI to support NuGet features in the Visual Studio IDE. The dotnet CLI is installed with some Visual Studio workloads, such as .NET Core. The `nuget.exe` CLI must be installed separately as described earlier. For a feature comparison of the tools, see the [feature availability](#feature-availability) section. + +- To target .NET Core or .NET Standard, use the dotnet SDK CLI tool. This CLI is required for the SDK-style project format, which uses the [SDK attribute](/dotnet/core/tools/csproj#additions). + +- To target the .NET Framework (non-SDK-style project only), use the `nuget.exe` CLI tool. If the project is migrated from `packages.config` to PackageReference, use the dotnet SDK CLI tool instead. -- Visual Studio for Mac: certain NuGet capabilities are built in directly. See [Including a NuGet package in your project](/visualstudio/mac/nuget-walkthrough) for a walkthrough. For other capabilities, use the `dotnet.exe` or `nuget.exe` CLI tools. +### dotnet SDK -- Visual Studio on Windows: The **NuGet Package Manager** is included with Visual Studio 2012 and later. Visual Studio provides the [Package Manager UI](consume-packages/install-use-packages-visual-studio.md) and the [Package Manager Console](consume-packages/install-use-packages-powershell.md), through which you can run most NuGet operations. - - Starting in Visual Studio 2017, the installer includes the NuGet Package Manager with any workload that employs .NET. To install separately, or to verify that the Package Manager is installed, run the Visual Studio installer and check the option under **Individual Components > Code tools > NuGet package manager**. - - The Package Manager UI and Console are unique to Visual Studio on Windows. They are not presently available on Visual Studio for Mac. - - A CLI tool is required to support NuGet features in the IDE. You can use either the `dotnet` CLI or the the `nuget.exe` CLI. The `dotnet` CLI is installed with some Visual Studio workloads, such as .NET Core. The `nuget.exe` CLI must be installed separately as described earlier. - - Package Manager Console commands work only within Visual Studio on Windows and do not work within other PowerShell environments. - - For Visual Studio 2010 and earlier, install the "NuGet Package Manager for Visual Studio" extension. - - NuGet Extensions for Visual Studio 2013 and 2015 can also be downloaded from [https://dist.nuget.org/index.html](https://dist.nuget.org/index.html). - - If you'd like to preview upcoming NuGet features, install the [Visual Studio 2017 Preview](https://www.visualstudio.com/vs/preview/), which works side-by-side with stable releases of Visual Studio. To report problems or share ideas for previews, open an issue on the [NuGet GitHub repository](https://github.com/Nuget/Home/issues). +The dotnet SDK is the .NET Core 2.0 CLI tool, which works on all platforms (Windows, Mac, and Linux) and provides core NuGet features such as installing, restoring, and publishing packages. The dotnet CLI provides direct integration with .NET Core project files (such as `.csproj`), which is helpful in most scenarios. This CLI is also built directly for each platform and doesn't require installation of [Mono](https://www.mono-project.com/docs/getting-started/install/). + +#### Install the dotnet SDK + +- On developer computers, install the [.NET Core SDK](https://aka.ms/dotnetcoregs). In Visual Studio 2017 and later, the dotnet CLI is automatically installed with any .NET Core related workloads. + +- For build servers, follow the instructions to [Use the .NET Core SDK and tools in continuous integration](/dotnet/core/tools/using-ci-with-cli). + +To learn how to use basic commands with the dotnet SDK CLI tool, see [Install and manage NuGet packages with the dotnet CLI](consume-packages/install-use-packages-dotnet-cli.md). + +### nuget.exe CLI + +The NuGet CLI, `nuget.exe`, is the command-line utility for Windows that provides all NuGet capabilities. This CLI can also run on Mac OSX and Linux by using [Mono](https://www.mono-project.com/docs/getting-started/install/) with some limitations. + +To learn how to use basic commands with the `nuget.exe` CLI tool, see [Manage NuGet packages with the nuget.exe CLI](consume-packages/install-use-packages-nuget-cli.md). + +#### Install nuget.exe + +[!INCLUDE [install-cli](includes/install-cli.md)] ## Feature availability +The following table compares the available features for the dotnet and `nuget.exe` CLI tools for supported platforms. + | Feature | dotnet CLI | nuget CLI (Windows) | nuget CLI (Mono) | Visual Studio (Windows) | Visual Studio for Mac | | --- | --- | --- | --- | --- | --- | -| Search packages | | ✔ | ✔ | ✔ | ✔ | -| Install/uninstall packages | ✔ | ✔(1) | ✔ | ✔ | ✔ | +| Search packages | ✔ | ✔ | ✔ | ✔ | ✔ | +| Install/uninstall packages | ✔ | ✔ (1) | ✔ | ✔ | ✔ | | Update packages | ✔ | ✔ | | ✔ | ✔ | -| Restore packages | ✔ | ✔ | ✔(2) | ✔ | ✔ | -| Manage package feeds (sources) | | ✔ | ✔ | ✔ | ✔ | +| Restore packages | ✔ | ✔ | ✔ (2) | ✔ | ✔ | +| Manage package feeds (sources) | ✔ | ✔ | ✔ | ✔ | ✔ | | Manage packages on a feed | ✔ | ✔ | ✔ | | | | Set API keys for feeds | | ✔ | ✔ | | | -| Create packages(3) | ✔ | ✔ | ✔(4) | ✔ | | +| Create packages (3) | ✔ | ✔ | ✔ (4) | ✔ | | | Publish packages | ✔ | ✔ | ✔ | ✔ | | -| Replicate packages | | ✔ | ✔ | | | +| Replicate packages | | ✔ | ✔ | | | | Manage *global-package* and cache folders | ✔ | ✔ | ✔ | | | -| Manage NuGet configuration | | ✔ | ✔ | | | +| Manage NuGet configuration | ✔ | ✔ | ✔ | | | -(1) Does not affect project files; use `dotnet.exe` instead. +**Feature notes** -(2) Works only with `packages.config` file and not with solution (`.sln`) files. +- (1) Doesn't affect project files. Use the dotnet SDK CLI tool instead. +- (2) Works only with `packages.config` file and not with solution (`.sln`) files. +- (3) Various advanced package features are available through the CLI only as they aren't represented in the Visual Studio UI tools. +- (4) Works with `.nuspec` files but not with project files. -(3) Various advanced package features are available through the CLI only as they aren't represented in the Visual Studio UI tools. +## Upcoming features -(4) Works with `.nuspec` files but not with project files. +If you want to preview upcoming NuGet features, install a [Visual Studio Preview](https://www.visualstudio.com/vs/preview/), which works side-by-side with stable releases of Visual Studio. To report problems or share ideas for previews, open an issue on the [NuGet GitHub repository](https://github.com/Nuget/Home/issues). -### Related topics +## Related articles -- [Install and manage packages using Visual Studio](consume-packages/install-use-packages-visual-studio.md) -- [Install and manage packages using PowerShell](consume-packages/install-use-packages-powershell.md) -- [Install and manage packages using dotnet CLI](consume-packages/install-use-packages-dotnet-cli.md) -- [Install and manage packages using nuget.exe CLI](consume-packages/install-use-packages-nuget-cli.md) +- [Install and manage packages by using Visual Studio](consume-packages/install-use-packages-visual-studio.md) +- [Install and manage packages by using the dotnet CLI](consume-packages/install-use-packages-dotnet-cli.md) +- [Install and manage packages by using the nuget.exe CLI](consume-packages/install-use-packages-nuget-cli.md) +- [Install and manage packages by using PowerShell](consume-packages/install-use-packages-powershell.md) +- [Create a package by using the nuget.exe CLI](create-packages/creating-a-package.md) +- [Publish NuGet packages](nuget-org/publish-a-package.md) - [Package Manager Console PowerShell reference](reference/powershell-reference.md) -- [Creating a package](create-packages/creating-a-package.md) -- [Publishing a Package](nuget-org/publish-a-package.md) -Developers working on Windows can also explore the [NuGet Package Explorer](https://github.com/NuGetPackageExplorer/NuGetPackageExplorer), an open-source, stand-alone tool to visually explore, create, and edit NuGet packages. It's very helpful, for example, to make experimental changes to a package structure without rebuilding the package. +Developers working on Windows can also explore the [NuGet Package Explorer](https://github.com/NuGetPackageExplorer/NuGetPackageExplorer). This application is an open-source standalone tool that lets you visually explore, create, and edit NuGet packages. It's helpful for many scenarios, such as making experimental changes to a package structure without rebuilding the package. diff --git a/docs/media/hub/nuget-get-started-consume-packages.svg b/docs/media/hub/nuget-get-started-consume-packages.svg deleted file mode 100644 index 5fa3f7e11..000000000 --- a/docs/media/hub/nuget-get-started-consume-packages.svg +++ /dev/null @@ -1,118 +0,0 @@ - - - - - nuget-get-started-consume-packages - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/docs/media/hub/nuget-get-started-create-packages.svg b/docs/media/hub/nuget-get-started-create-packages.svg deleted file mode 100644 index 2312f695e..000000000 --- a/docs/media/hub/nuget-get-started-create-packages.svg +++ /dev/null @@ -1,144 +0,0 @@ - - - - - nuget-get-started-create-packages - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/media/hub/nuget-get-started-guides.svg b/docs/media/hub/nuget-get-started-guides.svg deleted file mode 100644 index e5df6c263..000000000 --- a/docs/media/hub/nuget-get-started-guides.svg +++ /dev/null @@ -1,149 +0,0 @@ - - - - - nuget-get-started-guides - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/media/hub/nuget-get-started-host-packages.svg b/docs/media/hub/nuget-get-started-host-packages.svg deleted file mode 100644 index 36acde6a4..000000000 --- a/docs/media/hub/nuget-get-started-host-packages.svg +++ /dev/null @@ -1,88 +0,0 @@ - - - - - nuget-get-started-host-packages - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/media/hub/nuget-get-started-quickstarts.svg b/docs/media/hub/nuget-get-started-quickstarts.svg deleted file mode 100644 index 8a79d7c4d..000000000 --- a/docs/media/hub/nuget-get-started-quickstarts.svg +++ /dev/null @@ -1,82 +0,0 @@ - - - - - nuget-get-started-quickstarts - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/media/hub/nuget-get-started-what-is-nuget.svg b/docs/media/hub/nuget-get-started-what-is-nuget.svg deleted file mode 100644 index 7fdc205e4..000000000 --- a/docs/media/hub/nuget-get-started-what-is-nuget.svg +++ /dev/null @@ -1,77 +0,0 @@ - - - - - nuget-get-started-what-is-nuget - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/media/hub/nuget-tools-api.svg b/docs/media/hub/nuget-tools-api.svg deleted file mode 100644 index 85c58eb16..000000000 --- a/docs/media/hub/nuget-tools-api.svg +++ /dev/null @@ -1,73 +0,0 @@ - - - - - nuget-tools-api - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/media/hub/nuget-tools-policies.svg b/docs/media/hub/nuget-tools-policies.svg deleted file mode 100644 index 46503b2da..000000000 --- a/docs/media/hub/nuget-tools-policies.svg +++ /dev/null @@ -1,105 +0,0 @@ - - - - - nuget-tools-policies - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/media/hub/nuget-tools-reference.svg b/docs/media/hub/nuget-tools-reference.svg deleted file mode 100644 index b1935c8e3..000000000 --- a/docs/media/hub/nuget-tools-reference.svg +++ /dev/null @@ -1,94 +0,0 @@ - - - - - nuget-tools-reference - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/media/hub/nuget-tools-tools.svg b/docs/media/hub/nuget-tools-tools.svg deleted file mode 100644 index d45a6b273..000000000 --- a/docs/media/hub/nuget-tools-tools.svg +++ /dev/null @@ -1,95 +0,0 @@ - - - - - nuget-tools-tools - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/media/hub/nuget-tools-vs-extensibility.svg b/docs/media/hub/nuget-tools-vs-extensibility.svg deleted file mode 100644 index 76f787687..000000000 --- a/docs/media/hub/nuget-tools-vs-extensibility.svg +++ /dev/null @@ -1,65 +0,0 @@ - - - - - nuget-tools-vs-extensibility - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/nuget-org/Deprecate-packages.md b/docs/nuget-org/Deprecate-packages.md new file mode 100644 index 000000000..c9189ce99 --- /dev/null +++ b/docs/nuget-org/Deprecate-packages.md @@ -0,0 +1,141 @@ +--- +title: Deprecating packages on nuget.org +description: Detailed description on the process of deprecating packages and how the clients shows this information +author: anangaur +ms.author: anangaur +ms.date: 09/23/2019 +ms.topic: conceptual +ms.reviewer: karann-msft +--- + +# Deprecating packages + +You can deprecate a package if you no longer maintain a package or if would like to encourage your package's consumers to move to another package. + +Package deprecation is different than **unlisting** your package as explained below: +* **Unlisting** a package prevents its discovery because it is hidden in search results. +* **Deprecating** a package lets your package's existing consumers find out if they have it installed or used in their projects. It also lets them know the reason for deprecation and an alternate recommended package as specified by you (the package publisher). Deprecating a package does not unlist the package. + +As a publisher, you may choose to both unlist as well as deprecate packages. + +## Deprecation workflow +1. To deprecate a package, go to **Manage packages** and select **Deprecation**: + + ![Go to deprecate package option](media/deprecation-select-option.png) + +2. Select the version you would like to deprecate. If you want to deprecate all version, choose **Select all versions** option. + + ![Select package versions to deprecate](media/deprecation-select-version.png) + +3. Choose a reason for deprecation. If the package is no longer maintained, choose the **Legacy** option. If the specific version has a critical bug, choose the **has critical bugs** option. For any other reason, select **Other**. You can always specify an alternate recommended package (and version) and a custom message to the owners. + + ![Select reasons alternate package recommendation and custom message](media/deprecation-save.png) + +> [!Note] +> Custom message is only shown on nuget.org but not from the clients. Currently, clients such as `dotnet.exe` and the NuGet Package Manager do not show the custom message. + +## Client experience for deprecated packages +Once a package has been deprecated, its consumers are notified about it in the following ways (depending upon the client used). + +### Visual Studio +*Available starting in Visual Studio 2019 version 16.3* + +Visual Studio warns about a deprecated package's usage on the `Installed` tab. It will show a warning for the package and its deprecation information (including the reason it was deprecated and the alternate package to use instead, if present). + + ![Deprecated packages on Visual Studio installed tab of package manager](media/deprecation-vs.png) + +### dotnet.exe +*Available starting with .NET SDK 3.0* + +If you use dotnet.exe, you can run the command `dotnet list package --deprecated` on the solution or project folder to get a list of deprecated packages along with the deprecation information: + +``` +> dotnet list package --deprecated + +The following sources were used: + https://api.nuget.org/v3/index.json + +Project `My.Test.Project` has the following deprecated packages + [netcoreapp3.0]: + Top-level Package Resolved Reason(s) Alternative + > My.Sample.Lib 6.0.0 Legacy My.Awesome.Package + +``` + +## Transfer popularity to a newer package + +Package authors who have deprecated a legacy package can choose to transfer its "popularity" to a newer package to boost the newer package's search ranking. This helps customers discover the newer package instead of the deprecated package. + +For example, let's say I have two packages: + +* My deprecated legacy package, `Contoso.Legacy` with 3 million downloads +* My latest package, `Contoso.Latest` with 5 downloads + +NuGet.org prefers search results with higher downloads/popularity. Given the search query "Contoso", my deprecated package `Contoso.Legacy` would likely rank above my latest package `Contoso.Latest` in search results. + +To solve this problem, I can apply to transfer the popularity of my deprecated legacy package to my latest package. This would cause `Contoso.Latest` to rank higher in search results, while `Contoso.Legacy` would rank lower. Only the internal popularity scores for the packages is impacted, the actual download count for each package will not be affected. + +> [!Note] +> Popularity transfers can make it significantly harder for consumers to find the legacy package. + +See the table below to get a concrete idea of how a popularity transfer may impact search rankings for the query "Contoso": + +| Search ranking | Before popularity transfer | After popularity transfer | +|---------------- |-------------------------------- |-------------------------------- | +| 1 | *Contoso.Legacy, 3M downloads* | *Contoso.Latest, 5 downloads* | +| 2 | Contoso.Scanner, 2M downloads | Contoso.Scanner, 2M downloads | +| 3 | Contoso.Core, 1.5M downloads | Contoso.Core, 1.5M downloads | +| 4 | Contoso.UI, 1M downloads | Contoso.UI, 1M downloads | +| ... | ... | ... | +| 20 | *Contoso.Latest, 5 downloads* | *Contoso.Legacy, 3M downloads* | + +### Popularity transfer application process + +1. Review the [popularity transfer requirements](#popularity-transfer-requirements). +2. Email [account@nuget.org](mailto:account@nuget.org) with the deprecated package whose popularity should be transferred, and, the list of stable package(s) that should receive the popularity transfer. + +After the application is submitted, we will notify you of your application's acceptance or rejection (with the criteria that caused rejection). We may need to ask additional identifying questions to confirm owner identity. + +#### Popularity transfer requirements + +* The legacy packages and new packages must share all owners. +* The new packages must be clearly related to the legacy packages in naming and function (i.e. an evolution or next generation). +* All versions of the legacy packages must be deprecated and point to the new packages receiving the transfer. +* The popularity transfer must not cause confusion for NuGet users or worsen the NuGet search experience. +* The new packages must have a stable version. +* The legacy package must not receive popularity transfers from another deprecated package. + +### Advanced popularity transfer scenarios + +#### Package consolidations + +I can transfer the popularity of multiple deprecated packages in favor of a single new package. For example, let's say I have 3 packages: + +* My first deprecated legacy package, `Contoso.Legacy1` +* My second deprecated legacy package, `Contoso.Legacy2` +* My new consolidated package, `Contoso.Latest` + +After I deprecate `Contoso.Legacy1` and `Contoso.Legacy2`, I can apply to transfer their popularity to `Contoso.Latest`. + +#### Package splits + +A deprecated package's popularity can be transferred to, and divided among, up to 5 newer packages. This is useful if the functionality of a deprecated package has been split among multiple new packages. For example, let's say I have 3 packages: + +* My deprecated legacy package, `Contoso.Legacy` +* My first new package, `Contoso.Web` +* My second new package, `Contoso.Cloud` + +`Contoso.Legacy` includes both web and cloud functionality, but I decided to separate that functionality into different packages for the next generation. After I deprecate `Contoso.Legacy`, I can apply to transfer its popularity to both `Contoso.Web` and `Contoso.Cloud`. + +> [!Warning] +> The transferred popularity will be split evenly between all new packages. As a result, we recommend transferring your deprecated package's popularity to as few packages as possible. + +#### Popularity transfer chains + +A deprecated package cannot transfer its popularity if it is already receiving popularity from another deprecated package. For example, say I have 3 packages: + +* My deprecated legacy package, `Contoso.First` +* My deprecated legacy package, `Contoso.Second` +* My new package, `Contoso.Latest` + +If `Contoso.First` transfers its popularity to `Contoso.Second,` then `Contoso.Second` cannot transfer its popularity to `Contoso.Latest`. Instead, we recommend transferring the popularity of both `Contoso.First` and `Contoso.Second` to `Contoso.Latest`, as per the [Package consolidations](#package-consolidations) scenario. diff --git a/docs/nuget-org/Publish-a-package.md b/docs/nuget-org/Publish-a-package.md index a8ff524af..36ce9f614 100644 --- a/docs/nuget-org/Publish-a-package.md +++ b/docs/nuget-org/Publish-a-package.md @@ -1,119 +1,140 @@ --- -title: How to Publish a NuGet Package -description: Detailed instructions for how to publish a NuGet package to nuget.org or private feeds, and how to manage package ownership on nuget.org. -author: karann-msft -ms.author: karann -ms.date: 05/18/2018 +title: How to publish NuGet packages +description: See detailed instructions about how to publish a NuGet package and manage package ownership on nuget.org. +author: JonDouglas +ms.author: jodou +ms.date: 8/29/2022 ms.topic: conceptual ms.reviewer: anangaur --- -# Publishing packages +# Publish NuGet packages -Once you have created a package and have your `.nupkg` file in hand, it's a simple process to make it available to other developers, either publicly or privately: +Once you create a NuGet package and have a *.nupkg* file, you can make the package available to other developers either publicly or privately. This article describes how to share public packages globally through [nuget.org](https://www.nuget.org/packages/manage/upload). -- Public packages are made available to all developers globally through [nuget.org](https://www.nuget.org/packages/manage/upload) as described in this article (requires NuGet 4.1.0+). -- Private packages are available to only a team or organization, by hosting them either a file share, a private NuGet server, [Azure Artifacts](https://www.visualstudio.com/docs/package/nuget/publish), or a third-party repository such as myget, ProGet, Nexus Repository, and Artifactory. For additional details, see [Hosting Packages Overview](../hosting-packages/overview.md). - -This article covers publishing to nuget.org; for publishing to Azure Artifacts, see [Package Management](https://www.visualstudio.com/docs/package/nuget/publish). +You can also make private packages available to only a team or organization by hosting them on a file share, a private NuGet server, or a third-party repository such as myget, ProGet, Nexus Repository, or Artifactory. For more information, see [Host your own NuGet feeds](../hosting-packages/overview.md). For publishing with [Azure Artifacts](https://www.visualstudio.com/docs/package/nuget/publish), see [Publish packages to NuGet.org](/azure/devops/artifacts/nuget/publish-to-nuget-org). ## Publish to nuget.org -For nuget.org, you must sign in with a Microsoft account, with which you'll be asked to register the account with nuget.org. You can also sign in with a nuget.org account created using older versions of the portal. +To publish on nuget.org, sign in to nuget.org with a Microsoft account, and use it to create a free nuget.org account. Follow the instructions at [Add a new individual account](individual-accounts.md#add-a-new-individual-account). + +![Screenshot that shows the NuGet sign in link.](media/publish-nuget-signin.png) + +Once you have an account, you can publish a package to nuget.org by using the nuget.org web portal, the dotnet CLI, or the NuGet CLI version 4.1.0 or above. You can also publish packages through Azure Pipelines. -![NuGet sign in location](media/publish_NuGetSignIn.png) +### Upload to the nuget.org web portal -Next, you can either upload the package through the nuget.org web portal, push to nuget.org from the command line (requires `nuget.exe` 4.1.0+) , or publish as part of a CI/CD process through Azure DevOps Services, as described in the following sections. +To upload a package to the nuget.org website: -### Web portal: use the Upload Package tab on nuget.org +1. Select **Upload** on the top menu at nuget.org, browse to the package on your computer, and select **Open**. -1. Select **Upload** on the top menu of nuget.org and browse to the package location. + ![Screenshot that shows the Upload dialog on nuget.org](media/publish-upload-package.png) - ![Upload a package on nuget.org](media/publish_UploadYourPackage.PNG) + If the package ID already exists on nuget.org, you get an error. Change the package identifier in your project, repack, and try the upload again. -1. nuget.org tells you if the package name is available. If it isn't, change the package identifier in your project, rebuild, and try the upload again. +1. If the package name is available, the **Verify** section opens so you can review the metadata from the package manifest. If you included a [readme file](../nuget-org/package-readme-on-nuget-org.md) in your package, select **Preview** to make sure all content renders properly. -1. If the package name is available, nuget.org opens a **Verify** section in which you can review the metadata from the package manifest. To change any of the metadata, edit your project (project file or `.nuspec` file), rebuild, recreate the package, and upload again. + To change any of the metadata, edit your project file or *.nuspec* file, rebuild, repack, and upload again. -1. Under **Import Documentation** you can paste Markdown, point to your docs with a URL, or upload a documentation file. +1. When all the information is ready, select **Submit**. -1. When all the information is ready, select the **Submit** button +### Push by using a command line -### Command line +To push packages to nuget.org with a command line, you can use either `dotnet.exe` or `nuget.exe` v4.1.0 or above, which implement the required NuGet protocols. For more information, see [NuGet protocols](../api/nuget-protocols.md). -To push packages to nuget.org you must use [nuget.exe v4.1.0 or above](https://www.nuget.org/downloads), which implements the required [NuGet protocols](../api/nuget-protocols.md). You also need an API key, which is created on nuget.org. +To use either command line, you first need to get an API key from nuget.org. -#### Create API keys +#### Create an API key -[!INCLUDE [publish-api-key](../quickstart/includes/publish-api-key.md)] +[!INCLUDE [publish-api-key](../quickstart/includes/publish-api-key-with-link.md)] -#### Publish with dotnet nuget push +#### Use the dotnet CLI [!INCLUDE [publish-dotnet](../quickstart/includes/publish-dotnet.md)] -#### Publish with nuget push +#### Use the NuGet CLI -1. At a command prompt, run the following command, replacing `` with the key obtained from nuget.org: +1. At a command prompt, run the following command, replacing `` with the key you got from nuget.org: ```cli nuget setApiKey ``` - This command stores your API key in your NuGet configuration so that you need repeat this step again on the same computer. + This command stores your API key in your NuGet configuration so you don't need to enter the API key again on the same computer. -1. Push your package to NuGet Gallery using the following command: + > [!NOTE] + > This API key isn't used to authenticate with private feeds. To manage credentials for authenticating with these sources, see the [nuget sources command](../reference/cli-reference/cli-ref-sources.md). + +1. Push the package by using the following command: ```cli nuget push YourPackage.nupkg -Source https://api.nuget.org/v3/index.json ``` -#### Publish signed packages +### Publish with Azure Pipelines + +You can push packages to nuget.org with Azure Pipelines as part of your continuous integration/continuous deployment (CI/CD) process. For more information, see [Publish NuGet packages with Azure Pipelines](/azure/devops/pipelines/artifacts/nuget). + +### Publish a signed package + +To submit a signed package, you must first [register the certificate](../create-packages/Sign-a-Package.md#register-the-certificate-on-nugetorg) you used to sign the package. If you don't meet the [signed package requirements](../reference/Signed-Packages-Reference.md#signature-requirements-on-nugetorg), nuget.org rejects the package. + +### Package size limits + +Nuget.org has a package size limit of about 250 MB. When a package exceeding that limit is uploaded the following error is displayed: -To submit signed packages, you must first [register the certificate](../create-packages/Sign-a-Package.md#register-the-certificate-on-nugetorg) used for signing the packages. +> The package file exceeds the size limit. Please try again. -> [!Warning] -> nuget.org rejects packages that don't satisfy the [signed package requirements](../reference/Signed-Packages-Reference.md#signature-requirements-on-nugetorg). +If such package is pushed from the command line, the following output is produced: -### Package validation and indexing +```text + RequestEntityTooLarge https://www.nuget.org/api/v2/package/ 13903ms +error: Response status code does not indicate success: 413 (The package file exceeds the size limit. Please try again.). +``` -Packages pushed to nuget.org undergo several validations, such as virus checks. (All packages on nuget.org are periodically scanned.) +If you are getting this errors consider revising the package content to reduce its size. If you are packing debug symbols into your package consider publishing them [separately](../create-packages/Symbol-Packages-snupkg.md). Other assets can be published separately as one or more dependency packages to spread them into smaller chunks. -When the package has passed all validation checks, it might take a while for it to be indexed and appear in search results. Once indexing is complete, you receive an email confirming that the package was successfully published. If the package fails a validation check, the package details page will update to display the associated error and you also receive an email notifying you about it. +## Package validation and indexing -Package validation and indexing usually takes under 15 minutes. If the package publishing is taking longer than expected, visit [status.nuget.org](https://status.nuget.org/) to check if nuget.org is experiencing any interruptions. If all systems are operational and the package hasn't been successfully published within an hour, please login to nuget.org and contact us using the Contact Support link on the package page. +Packages pushed to nuget.org undergo several validations, such as virus checks, and existing packages are periodically scanned. When the package passes all validation checks, it might take awhile to be indexed and appear in search results. While the package is being indexed, it appears under **Unlisted Packages**, and you see the following message on the package page: -To see the status of a package, select **Manage packages** under your account name on nuget.org. You receive a confirmation email when validation is complete. +![Screenshot of a message indicating that a package isn't yet published.](media/publish_NotYetIndexed.png) -Note that it might take a while for your package to be indexed and appear in search results where others can find it, during which time you see the following message on your package page: +Once validation and indexing are complete, you receive an email that the package was successfully published. If the package fails a validation check, the package page updates to display the associated error, and you receive a notification email. -![Message indicating a package is not yet published](media/publish_NotYetIndexed.png) +Package validation and indexing usually take less than 15 minutes. If package publishing is taking longer than expected, check nuget.org status at [status.nuget.org](https://status.nuget.org/). If all systems are operational and the package isn't successfully published within an hour, contact nuget.org by using the **Contact support** link on the package page. -### Azure DevOps Services (CI/CD) +To see package status, select **Manage packages** under your account name at upper right on nuget.org, and select the package from **Published Packages** or **Unlisted Packages**. -If you push packages to nuget.org using Azure DevOps Services as part of your Continuous Integration/Deployment process, you must use `nuget.exe` 4.1 or above in the NuGet tasks. Details can be found on [Using the latest NuGet in your build](https://blogs.msdn.microsoft.com/devops/2017/09/29/using-the-latest-nuget-in-your-build/) (Microsoft DevOps blog). + +## Manage package owners on nuget.org -## Managing package owners on nuget.org +Package owners have full permissions for the package, including adding and removing other owners and publishing updates. -Although each NuGet package's `.nuspec` file defines the package's authors, the nuget.org gallery does not use that metadata to define ownership. Instead, nuget.org assigns initial ownership to the person who publishes the package. This is either the logged-in user who uploaded the package through the nuget.org UI, or the users whose API key was used with `nuget SetApiKey` or `nuget push`. +Although the NuGet package's *.nuspec* file defines the package's authors, nuget.org doesn't use that metadata to define ownership. Instead, nuget.org assigns ownership to the person who publishes the package, either the signed-in user who uploaded the package, or the user whose API key was used with `dotnet push`, `nuget SetApiKey`, or `nuget push`. -All package owners have full permissions for the package, including adding and removing other owners, and publishing updates. +To change ownership of a package: -To change ownership of a package, do the following: +1. Sign in to nuget.org with the account that currently owns the package. +1. Select your account name at upper right, select **Manage packages**, and expand **Published Packages**. +1. Select the package you want to manage, and on the right side of the package page, select **Manage package**. +1. On the package management page, select **Owners**. +1. Take one of the following actions: -1. Sign in to nuget.org with the account that is the current owner of the package. -1. Select your account name, select **Manage packages**, and expand **Published Packages**. -1. Select on the package you want to manage, then on the right side select **Manage owners**. + - Select **Remove** to remove the current owner. + - Add an owner under **Add owner** by entering their user name and a message, and selecting **Add**. -From here you have several options: + This action sends an email to the new co-owner with a confirmation link. Once confirmed, that person has full permissions to add and remove owners. Until confirmed, the **Current owners** section shows pending approval for that person. -1. Remove any owner listed under **Current Owners**. -1. Add an owner under **Add Owner** by entering their user name, a message, and selecting **Add**. This action sends an email to that new co-owner with a confirmation link. Once confirmed, that person has full permissions to add and remove owners. (Until confirmed, the **Current Owners** section indicates pending approval for that person.) -1. To transfer ownership (as when ownership changes or a package was published under the wrong account), add the new owner, and once they've confirmed ownership they can remove you from the list. +To transfer ownership, as when ownership changes or a package publishes under the wrong account, add the new owner. Once they confirm ownership, they can remove the old owner from the list. -To assign ownership to a company or group, create a nuget.org account using an email alias that is forwarded to the appropriate team members. For example, various Microsoft ASP.NET packages are co-owned by the [microsoft](http://nuget.org/profiles/microsoft) and [aspnet](http://nuget.org/profiles/aspnet) accounts, which simply such aliases. +To assign ownership to a company or group, create a nuget.org account with an email alias that forwards to the appropriate team members. For example, various Microsoft ASP.NET packages are co-owned by the [microsoft](https://nuget.org/profiles/microsoft) and [aspnet](https://nuget.org/profiles/aspnet) accounts. -### Recovering package ownership +Occasionally, a package might not have an active owner. For example, the original owner might have left the company that produced the package. If you're the rightful owner of a package and need to regain ownership, use the [contact form](https://www.nuget.org/policies/Contact) on nuget.org to explain your situation to the NuGet team. The team follows a process to verify your ownership, including trying to locate the existing owner, and can send you a new invitation to become the package owner. -Occasionally, a package may not have an active owner. For example, the original owner may have left the company that produces the package, nuget.org credentials are lost, or earlier bugs in the gallery left a package ownerless. +## Next steps -If you are the rightful owner of a package and need to regain ownership, use the [contact form](https://www.nuget.org/policies/Contact) on nuget.org to explain your situation to the NuGet team. We then follow a process to verify your ownership of the package, including trying to locate the existing owner through the package's Project URL, Twitter, email, or other means. But if all else fails, we can send you a new invite to become an owner. +- [Package readme on NuGet.org](package-readme-on-nuget-org.md) +- [Package ID prefix reservation](id-prefix-reservation.md) +- [Deprecate packages](deprecate-packages.md) +- [Host your own NuGet feeds](../hosting-packages/overview.md) diff --git a/docs/nuget-org/TOC.md b/docs/nuget-org/TOC.md index cbae7d0ff..b102dd1e7 100644 --- a/docs/nuget-org/TOC.md +++ b/docs/nuget-org/TOC.md @@ -5,7 +5,9 @@ ## [API keys](scoped-api-keys.md) # Manage packages on NuGet.org ## [Publish a package](publish-a-package.md) -## [Packaging ID prefix reservation](id-prefix-reservation.md) +## [Package ID prefix reservation](id-prefix-reservation.md) +## [Package deprecation](deprecate-packages.md) +## [Package readme](package-readme-on-nuget-org.md) # Policies ## [Data Requests](policies/Data-requests.md) ## [Dispute resolution](policies/dispute-resolution.md) @@ -15,4 +17,4 @@ ## [NuGet API](../api/overview.md) ## [licenses.nuget.org](licenses.nuget.org.md) # Resources -## [FAQ](nuget-org-faq.md) +## [FAQ](nuget-org-faq.yml) diff --git a/docs/nuget-org/id-prefix-reservation.md b/docs/nuget-org/id-prefix-reservation.md index 5336e7fb8..3715dcf3c 100644 --- a/docs/nuget-org/id-prefix-reservation.md +++ b/docs/nuget-org/id-prefix-reservation.md @@ -1,16 +1,16 @@ --- title: ID Prefix Reservation description: Package ID Prefix Reservation feature description and author guide. -author: diverdan92 -ms.author: diverdan92 -ms.date: 10/09/2017 +author: JonDouglas +ms.author: jodou +ms.date: 09/07/2019 ms.topic: reference -ms.reviewer: ananguar +ms.reviewer: karann --- # Package ID prefix reservation -Package owners can reserve and protect their identity by reserving ID prefixes. Package consumers are provided with additional information when consuming packages that the package they are consuming are not deceptive in their identifying properties. +Package owners can reserve and protect their identity by reserving ID prefixes. Package consumers are provided with additional information when the packages that they are consuming are not deceptive in their identifying properties. [nuget.org](https://www.nuget.org/) and Visual Studio 2017 version 15.4 or later show a visual indicator for packages that are submitted by owners with a reserved package ID prefix, as long as the package matches the reserved ID prefix naming pattern. The below reference explains what the ID prefix reservation entails, and how an owner can apply for an ID prefix. @@ -68,23 +68,27 @@ After the application is submitted, you are notified of acceptance or rejection ### ID prefix reservation criteria -When reviewing any application for ID prefix reservation, the [nuget.org](https://www.nuget.org/) team will evaluate the application against the below criteria. Not all criteria needs to be met for a prefix to be reserved, but the application may be denied if there is not substantial evidence of the criteria being met (with an explanation given): +When reviewing any application for ID prefix reservation, the [NuGet.org](https://www.nuget.org) team will evaluate the application against the below criteria. Please note that not all criteria need to be met for a prefix to be reserved, but the application may be denied if there is not substantial evidence of the criteria being met (with an explanation given): -1. Does the package ID prefix properly and clearly identify the package owner? +1. Does the package ID prefix properly and clearly identify the reservation owner? -1. Are a significant number of the packages that have already been submitted by the owner under the package ID prefix? +1. Is the package ID prefix something common that should not belong to any individual owner or organization? Avoid ID prefix reservations that are shorter than four characters and avoid common or generic words. -1. Is the package ID prefix something common that should not belong to any individual owner or organization? +1. Would *not* reserving the package ID prefix cause ambiguity, confusion, or other harm to the community? -1. Would *not* reserving the package ID prefix cause ambiguity and confusion for the community? +When publishing packages to NuGet.org within your ID prefix reservation, the following best practices must be considered: 1. Are the identifying properties of the packages that match the package ID prefix clear and consistent (especially the package author)? 1. Do the packages have a license (using the [license](../reference/nuspec.md#license) metadata element and NOT licenseUrl which is being deprecated)? +1. If the packages have an icon (using the iconUrl metadata element), are they also using the [icon](../reference/nuspec.md#icon) metadata element? It is not a requirement to remove the iconUrl but embedded icons must be used. + +Consider reviewing the full [package authoring best practices guide](../create-packages/package-authoring-best-practices.md) in addition to the points above. + ## Third party feed provider scenarios -If a third party feed provider is interested in implementing their own service to provide prefix reservations, you can do so by modifying the search service in the NuGet V3 feed providers. The addition in the feed search service is to add the *verified* property, with examples for the V3 feeds below. The NuGet client will not support the added property in the V2 feed. +If a third party feed provider is interested in implementing their own service to provide prefix reservations, they can do so by modifying the search service in the NuGet V3 feed providers. The change in the feed search service is to add the `verified` property. The NuGet client will not support the added property in the V2 feed. For more information, see the [documentation about the API's search service](../api/search-query-service-resource.md). diff --git a/docs/nuget-org/individual-accounts.md b/docs/nuget-org/individual-accounts.md index 8dc63b932..50b94940e 100644 --- a/docs/nuget-org/individual-accounts.md +++ b/docs/nuget-org/individual-accounts.md @@ -1,13 +1,14 @@ --- -title: Individual accounts +title: Individual accounts - NuGet.org description: Individual acccounts on NuGet.org are required to publish packages author: mikejo5000 ms.author: mikejo ms.date: 06/05/2019 ms.topic: conceptual +ms.custom: sfi-image-nochange --- -# Individual accounts +# Individual accounts on NuGet.org You must create an individual account to publish and manage packages on NuGet.org. @@ -19,7 +20,12 @@ An organization account has one or more individual accounts as its members. Thes ## Add a new individual account -To create a NuGet.org account, you need to have a personal Microsoft account (MSA) or an Azure Active Directory (AAD) account. If you do not have one, you can [create](https://signup.live.com) one. Follow the following steps if you have an MSA or AAD account. +To create a NuGet.org account, you need to have a personal Microsoft account (MSA) or an Azure Active Directory (AAD) account. If you do not have one, you can [create](https://signup.live.com) one. NuGet.org requires all accounts to have two-factor authentication (2FA) enabled on your MSA or AAD account. You can update your settings in advance using the following links: + +* Microsoft Account (MSA): [Turning two-step verification on or off for your Microsoft account](https://support.microsoft.com/account-billing/turning-two-step-verification-on-or-off-for-your-microsoft-account-b1a56fc2-caf3-a5a1-f7e3-4309e99987ca). +* Work or school Account (AAD): [Set up Security info from a sign-in page](https://support.microsoft.com/account-billing/set-up-security-info-from-a-sign-in-page-28180870-c256-4ebf-8bd7-5335571bf9a8). + +Follow the following steps if you have an MSA or AAD account. 1. Go to the [NuGet.org login page](https://www.nuget.org/users/account/LogOn). @@ -31,6 +37,8 @@ To create a NuGet.org account, you need to have a personal Microsoft account (MS ![Giving permissions to NuGet.org](media/nuget-org-permissions.png) +1. Follow two-factor authentication (2FA) setup steps if you do not have it already enabled. + 1. You will be redirected to *nuget.org*, and asked to register a username. 1. Specify the username in the input box. Please note that the username **is** case sensitive and cannot be changed or renamed later. @@ -41,26 +49,12 @@ To create a NuGet.org account, you need to have a personal Microsoft account (MS You now have a NuGet.org account. You can perform account management on the [account settings](https://www.nuget.org/account) page. -## Enable two-factor authentication (2FA) - -To better protect your account, enable two-factor authentication (recommended). - -1. When logged into your account, open your profile and choose **Enable** under **Login Account**. - - ![Enable 2FA](media/nuget-org-register-2fa.png) - - You will see a message that tells you that the next time you sign in to *nuget.org*, you will be asked for additional credentials. - -2. To complete the authentication at this time, sign out and then sign in again. - -3. When you sign in, choose either text or e-mail as a second form of authentication. - - Verify the phone number or e-mail that is already associated with your Microsoft account. You may need to enter a new phone number or e-mail for your account. If so, enter the required information as instructed, and click **Next**. - - ![Enable 2FA](media/nuget-org-sign-in-2fa.png) +> [!Note] +> Two-factor authentication, or 2FA, is an extra layer of security used when logging into websites or apps. With 2FA, you have to log in with your Microsoft Account (MSA) and provide another form of authentication that only you know or have access to. -4. Check your device or e-mail account, and enter the code that you were just sent. +> [!Note] +> 2FA for your NuGet.org account does not impact authentication settings for other accounts or services that may be linked to the Microsoft account you use to login to NuGet.org. - ![Enable 2FA](media/nuget-org-enter-code-2fa.png) +## Delete a NuGet.org account -5. Follow any additional instructions to complete Two-factor authentication. +For help with additional account-related tasks, such as deleting a NuGet.org account, see [NuGet.org account management](/nuget/nuget-org/nuget-org-faq#nuget.org-account-management). diff --git a/docs/nuget-org/licenses.nuget.org.md b/docs/nuget-org/licenses.nuget.org.md index 735955e00..9f82c2b95 100644 --- a/docs/nuget-org/licenses.nuget.org.md +++ b/docs/nuget-org/licenses.nuget.org.md @@ -1,7 +1,9 @@ --- title: licenses.nuget.org +description: Protocol and display information for licenses.nuget.org. Describes the SPDX data source and rationale. author: agr -ms.date: 02/22/2019 +ms.author: angrigor +ms.date: 03/02/2023 --- # licenses.nuget.org @@ -18,6 +20,18 @@ specify their license using a license expression. `nuget pack` or packing with o the [`licenseUrl`](../reference/nuspec.md#licenseurl) element to point to licenses.nuget.org to provide backwards compatibility with older clients that don't support the `license` element. +## License and exception text + +The license and license exception information displayed on licenses.nuget.org is copied from the SPDX project's [license list data repository](https://github.com/spdx/license-list-data). The format that the information is displayed closely mimics the format used by the SPDX website itself, e.g. see [MIT on licenses.nuget.org](https://licenses.nuget.org/MIT) and [MIT on SPDX.org](https://spdx.org/licenses/MIT.html). + +Licenses that are not approved by Open Source Initiative or the Free Software Foundation are not hosted on licenses.nuget.org and are excluded. + +Several styles in addition to plain text are used in the display of the license. According to the [SPDX license list data FAQ](https://github.com/spdx/license-list-XML/blob/main/DOCS/faq.md#what-does-the-blue-text-and-red-text-mean-in-the-license-list-entry), red text is considered replaceable and blue text is considered omitable. For more generally information about the SPDX license list data, see their [FAQ](https://github.com/spdx/license-list-XML/blob/main/DOCS/faq.md) and the [SPDX license template specification](https://spdx.github.io/spdx-spec/v2.3/license-matching-guidelines-and-templates/). + +Note that the data is copied from SPDX to licenses.nuget.org by the nuget.org on an ad hoc basis. If a license identifier is approved by the Open Source Initiative or the Free Software Foundation but does not appear on licenses.nuget.org, please [report an issue](https://github.com/NuGet/NuGetGallery/issues/new/choose), and the nuget.org team work to update licenses.nuget.org and nuget.org package upload validation with the latest data from SPDX. + +If you, as a package author, are not satisfied with the shared license text available on licenses.nuget.org, you can consider using [embedded license text](../reference/nuspec.md#license) (``) instead of a license expression for your NuGet package. This allows you to fully customize your licensing terms and include the customized text within the package. + ## Protocol Licenses.nuget.org is intended to be viewed by people in their browsers, no machine-readable responses are provided. @@ -40,7 +54,7 @@ licenses.nuget.org. | (LGPL-2.0-only WITH FLTK-exception OR Apache-2.0+) | | The service supports only license identifiers and license exception identifiers that are accepted by -nuget.org. All license expressions that contain unsupported license identifiers +nuget.org. Notably, this means only license identifiers that are approved by the Open Source Initiative or the Free Software Foundation will be accepted. All license expressions that contain unsupported license identifiers or license exception identifiers or that does not conform to license expression syntax are considered invalid. diff --git a/docs/nuget-org/media/deprecation-save.png b/docs/nuget-org/media/deprecation-save.png new file mode 100644 index 000000000..08b58e4a8 Binary files /dev/null and b/docs/nuget-org/media/deprecation-save.png differ diff --git a/docs/nuget-org/media/deprecation-select-option.png b/docs/nuget-org/media/deprecation-select-option.png new file mode 100644 index 000000000..5425fd36b Binary files /dev/null and b/docs/nuget-org/media/deprecation-select-option.png differ diff --git a/docs/nuget-org/media/deprecation-select-version.png b/docs/nuget-org/media/deprecation-select-version.png new file mode 100644 index 000000000..4c16b76e2 Binary files /dev/null and b/docs/nuget-org/media/deprecation-select-version.png differ diff --git a/docs/nuget-org/media/deprecation-vs.png b/docs/nuget-org/media/deprecation-vs.png new file mode 100644 index 000000000..3ea68d429 Binary files /dev/null and b/docs/nuget-org/media/deprecation-vs.png differ diff --git a/docs/nuget-org/media/nuget-org-enter-code-2fa.png b/docs/nuget-org/media/nuget-org-enter-code-2fa.png deleted file mode 100644 index 76c5614ee..000000000 Binary files a/docs/nuget-org/media/nuget-org-enter-code-2fa.png and /dev/null differ diff --git a/docs/nuget-org/media/nuget-org-permissions.png b/docs/nuget-org/media/nuget-org-permissions.png index 024b5ecce..6ab466f4d 100644 Binary files a/docs/nuget-org/media/nuget-org-permissions.png and b/docs/nuget-org/media/nuget-org-permissions.png differ diff --git a/docs/nuget-org/media/nuget-org-register-2fa.png b/docs/nuget-org/media/nuget-org-register-2fa.png deleted file mode 100644 index eadbdcb64..000000000 Binary files a/docs/nuget-org/media/nuget-org-register-2fa.png and /dev/null differ diff --git a/docs/nuget-org/media/nuget-org-register.png b/docs/nuget-org/media/nuget-org-register.png index b159da110..bed06b459 100644 Binary files a/docs/nuget-org/media/nuget-org-register.png and b/docs/nuget-org/media/nuget-org-register.png differ diff --git a/docs/nuget-org/media/nuget-org-sign-in-2fa.png b/docs/nuget-org/media/nuget-org-sign-in-2fa.png deleted file mode 100644 index 589fda9e8..000000000 Binary files a/docs/nuget-org/media/nuget-org-sign-in-2fa.png and /dev/null differ diff --git a/docs/nuget-org/media/publish-nuget-signin.png b/docs/nuget-org/media/publish-nuget-signin.png new file mode 100644 index 000000000..3d302e056 Binary files /dev/null and b/docs/nuget-org/media/publish-nuget-signin.png differ diff --git a/docs/nuget-org/media/publish-upload-package.png b/docs/nuget-org/media/publish-upload-package.png new file mode 100644 index 000000000..735e7da6e Binary files /dev/null and b/docs/nuget-org/media/publish-upload-package.png differ diff --git a/docs/nuget-org/media/publish_NuGetSignIn.PNG b/docs/nuget-org/media/publish_NuGetSignIn.PNG deleted file mode 100644 index cb0ae27cc..000000000 Binary files a/docs/nuget-org/media/publish_NuGetSignIn.PNG and /dev/null differ diff --git a/docs/nuget-org/media/publish_UploadYourPackage.PNG b/docs/nuget-org/media/publish_UploadYourPackage.PNG deleted file mode 100644 index 1a75d990b..000000000 Binary files a/docs/nuget-org/media/publish_UploadYourPackage.PNG and /dev/null differ diff --git a/docs/nuget-org/media/readme-upload-preview.PNG b/docs/nuget-org/media/readme-upload-preview.PNG new file mode 100644 index 000000000..6c280ce8f Binary files /dev/null and b/docs/nuget-org/media/readme-upload-preview.PNG differ diff --git a/docs/nuget-org/media/trusted-publishing.png b/docs/nuget-org/media/trusted-publishing.png new file mode 100644 index 000000000..8cd0ecfbf Binary files /dev/null and b/docs/nuget-org/media/trusted-publishing.png differ diff --git a/docs/nuget-org/media/unmanaged-aad-tenant.png b/docs/nuget-org/media/unmanaged-aad-tenant.png index 03e74d160..166896024 100644 Binary files a/docs/nuget-org/media/unmanaged-aad-tenant.png and b/docs/nuget-org/media/unmanaged-aad-tenant.png differ diff --git a/docs/nuget-org/nuget-org-faq.md b/docs/nuget-org/nuget-org-faq.md deleted file mode 100644 index 697e0a6d3..000000000 --- a/docs/nuget-org/nuget-org-faq.md +++ /dev/null @@ -1,264 +0,0 @@ ---- -title: NuGet.org Frequently-Asked Questions -description: Common questions and answers for working with the NuGet gallery. -author: shishirx34 -ms.author: shishirh -ms.date: 06/05/2019 -ms.topic: conceptual ---- - -# NuGet.org frequently-asked questions - -## License terms - -**What are the default license terms if a package doesn't provide specific license information?** - -Each package is governed by the terms that are included with the package. You should review the applicable terms before accessing, downloading, or acquiring any packages. On nuget.org, use the **License Info** link on the package page. - -If a package does not specify the licensing terms, contact the package owner directly using the **Contact owners** link on the nuget.org package page. Microsoft does not license any intellectual property to you from third party package providers and is not responsible for information provided by third parties. - -## Managing packages on NuGet.org - -**Can I edit package metadata after it's been uploaded?** - -NuGet recommends all packages to be signed. A design principle of package signing is that signed package content must be immutable, which includes the nuspec. Editing the package metadata results in changes to the nuspec, invalidating existing signatures. We recommend modifying existing workflows to not require editing the package metadata after the package has been created. - -Note that dependencies listed for your package are generated automatically from the package itself and cannot be edited. - -In addition, uploading packages to [int.nugettest.org](https://int.nugettest.org) is a great way to test and validate your package without making a package available in the public gallery. API Endpoint: https://apiint.nugettest.org/v3/index.json - -**Can I delete a package published to NuGet.org?** - -In general, we do not support deleting a package published to NuGet.org. Read more about our [policy on deleting packages](policies/deleting-packages.md). - -**Is it possible to reserve names for packages that will be published in future?** - -Yes. You can reserve IDs for packages on [nuget.org](https://www.nuget.org/) by requesting a package ID prefix for your account. In order to request a package ID prefix, follow the instructions in the [documentation](id-prefix-reservation.md). - -**How do I claim ownership for packages ?** - -See [Managing package owners on nuget.org](../nuget-org/publish-a-package.md#managing-package-owners-on-nugetorg). - -**How do I deal with a package owner who is violating my software license?** - -We encourage the NuGet community to work together to resolve any disputes that may arise between package owners and the owners of other software. We have crafted a [dispute resolution process](policies/dispute-resolution.md) to follow before asking nuget.org administrators to intercede. - -**Is it recommended to upload my test packages to nuget.org?** - -For test purposes, you can use [int.nugettest.org](https://int.nugettest.org), or alternative public NuGet servers like [myget.org](https://myget.org) or [Azure DevOps](https://blogs.msdn.microsoft.com/visualstudioalm/2015/08/27/announcing-package-management-support-for-vsotfs/). - -Note that packages uploaded to int.nugettest.org may not be preserved. - -**What is the maximum size of packages I can upload to nuget.org?** - -nuget.org allows packages up to 250MB, but we recommend keeping packages under 1MB if possible and using dependencies to link packages together. As a rule of thumb, packages contain only one assembly to avoid collisions. - -NuGet uses HTTP to download packages, so larger packages have a higher likelihood of failed installs than smaller ones. - -It is possible to share dependencies between multiple packages, making the total download size for consumers of your NuGet packages smaller. - -Dependencies are mostly static and never change. When fixing a bug in code, the dependencies may not need to be updated. If you bundle dependencies, you end up reshipping larger packages every time. By splitting NuGet packages into related dependencies, upgrades are much more fine-grained for consumers of your package. - -## nuget.org not accessible - -**Why can't I download packages from or upload packages to nuget.org?** - -First, make sure you're using the latest versions of NuGet. If that version continues to fail, [contact support](https://www.nuget.org/policies/Contact) and provide additional connection troubleshooting information including: - -- The version of NuGet you're using -- The package sources you're using -- A restore log with detailed verbosity -- MTR or a Fiddler traces (see below) -- Your geographical area -- Whether your machine is behind a proxy or firewall? -- Is your machine located on a cloud providers' data center (Azure, AWS etc)? If yes, please provide the name of the provider and the region. - -*To capture MTR:* - -- Download WinMTR from [http://winmtr.net/download/](http://winmtr.net/) -- Enter `api.nuget.org` as the hostname and click **Start**. -- Wait until the **Sent** column is >= 100. - - ![Capturing MTR](media/mtr.png) - -- Copy text to clipboard. - -*To capture Fiddler:* - -- Install the latest version of [Fiddler](http://www.telerik.com/download/fiddler). -- Start Fiddler and disable capturing traffic using the **File > Capture Traffic** menu. -- Remove all sessions (select all items in the list, press the **Delete** key). -- Configure Fiddler to capture HTTPS traffic by checking **Decrypt HTTPS traffic** in the **HTTPS** tab of the **Tools > Fiddler Options...** menu. -- Close Visual Studio. -- Enable the **File > Capture Traffic** menu. -- Start Visual Studio or nuget.exe .exe and perform the actions that are not working. The traffic generated by these actions should show up in Fiddler. -- Once the actions have run, use **File > Save > All Sessions** to store the captured sessions. - -Note: it may be required to set the `HTTP_PROXY` environment variable to `http://127.0.0.1:8888` for routing NuGet traffic through Fiddler. - -If that fails, try the [tips mentioned in this StackOverflow post](http://stackoverflow.com/questions/21049908/using-fiddler-to-sniff-visual-studio-2013-requests-proxy-firewall). - -## nuget.org account management - -### How to recover nuget.org password login? - -Please note that the [nuget.org Password login has been discontinued](https://blog.nuget.org/20180515/NuGet.org-will-only-support-MSA-AAD-starting-June.html) and the only way to log in to nuget.org is with a personal Microsoft account (MSA) or Azure Active Directory (AAD) account. However, in case you are unable to access your associated MSA/AAD accounts you might need to use password login for recovering your nuget.org account. In this situation follow the steps below. -- **Requirement:** You will need to have access to the email that is associated with the account for which you need to recover the password. -- Go to the [Forgot password page](https://www.nuget.org/account/ForgotPassword) -- Enter the **email** address that is associated with the nuget.org account you wish to recover. -- Click the **Send** button. -- You will get an email to the specified email address account with a link to reset your password. Click on this link and set the new password. If you can't find the mail check your "junk" folder. -- Once done, you can now login with username/password on NuGet. -- To login with username/password, use the **Sign in using Nuget.org account** link on the [nuget.org login page](https://www.nuget.org/users/account/LogOn). - -### Which Microsoft account is linked to my nuget.org account? - -If you have forgotten which Microsoft account is associated with your nuget.org account, please follow the steps below to get assistance. -1. Go to [nuget.org login page](https://www.nuget.org/users/account/LogOn) and click on **Need assistance signing in?** link. -1. This will show you the pop-up dialog box for assistance. Follow the steps in this dialog box to understand the associated Microsoft account(s) for your nuget.org account. - -### How to change the Microsoft account I use for nuget.org login? -If you wish to change the Microsoft account for nuget.org user, follow the steps below. Lets say your Microsoft account with email `account1@outlook.com` is associated with your nuget.org account with username `MyNuGetAccount`. You wish to change the login to another Microsoft account with email `account2@outlook.com` -1. Please sign in using **currently associated Microsoft account** i.e. `account1@outlook.com` on the [login page](https://www.nuget.org/users/account/LogOn) after clicking **Sign in with Microsoft**. -1. Once logged in, go to your [account settings](https://www.nuget.org/account) page. -1. Expand the section for **Login Account**. Click on the **Change Account** button. -1. You will now be redirected to the microsoft login page. Please sign in with the account that you wish to change the association to i.e. `account2@outlook.com`. **Note**: you might need to click on **Sign out and sign in with different account** during the sign in flow to be able to login with a different Microsoft account. -1. If you see an error like below, see [Microsoft account is linked with another nuget.org account](#microsoft-account-is-linked-with-another-nugetorg-account) for more details. - >_Failed to update the Microsoft account with 'account2 '. This could happen if it is already linked to another NuGet account. Contact support for more information._ - -1. Once you have successfully signed in with your second account, you will be redirected back to your nuget.org account settings page and you should now see the new Microsoft account associated as the login account. Going forward you should use this account when signing into nuget.org. - -### Microsoft account is linked with another nuget.org account. - -If you tried changing your Microsoft login and saw the error below: -> _Failed to update the Microsoft account with 'account2 '. This could happen if it is already linked to another NuGet account. Contact support for more information._ - -Lets say you were trying to change Microsoft account login from `account1@outlook.com` for nuget.org user with username `MyNuGetAccount1` to another Microsoft account with email `account2@outlook.com`. And you see the error above. - -**What does the error above mean?** - -It means that there is another nuget.org account which is associated with the Microsoft account that you are trying to change it to i.e. in above example the Microsoft account with email `` is associated with another nuget.org account with, say, username `MyNuGetAccount2`. - -You cannot change the associated login with a Microsoft account that is linked to a different nuget.org account. - -**I forgot I had another nuget.org account, how do I find out which nuget.org account it is?** - -Login with the second Microsoft account on the [login page](https://www.nuget.org/users/account/LogOn?returnUrl=%2F# "login page"). This will log you into the nuget.org account that is currently associated with the second Microsoft account. You can then view the uploaded packages and perform account management on this account. - -**I do not care about this second nuget.org account, I want to change my login for first nuget.org account with the second Microsoft account. What do I do?** - -If you wish to not care about the second nuget.org account and still want to re-use the associated Microsoft account with email `account2@outlook.com`. - -You can release the association between the Microsoft account and nuget.org account by deleting the nuget.org account. -1. Follow the steps to [delete user](#how-to-delete-my-nugetorg-account) for the second nuget.org account `MyNuGetAccount2`. -1. Once this account is deleted, you can retry the steps to [change Microsoft account login](#how-to-change-the-microsoft-account-i-use-for-nugetorg-login). - -**Wait, I care about this second account too. I do not want to lose this account but change my associated account logins for first account.** - -You will need to create/use a third Microsoft account, say, with email `account3@outlook.com`. -1. First you should login with your second Microsoft account, `account2@outlook.com` on nuget.org. Follow the steps above to change associated logins and associate the third Microsoft account with this nuget.org account. -1. Once done, your second Microsoft account with email `account2@outlook.com` is free to be associated to your first nuget.org account, `MyNuGetAccount1`. Follow the same steps above to change microsoft logins to the second Microsoft account. - -### Signing in with Microsoft account shows me my email is linked to another Microsoft account - -If you tried to sign in with your Microsoft account, say, with email `account1@outlook.com` and you see an error like below: -> _The account with email 'account1@outlook.com' is linked with another microsoft account._ -> -> _If you would like to update the linked Microsoft account you can do so from the account settings page._ - -**What does the error above mean?** - -When an account is created on nuget.org, there is a communication email address associated with that account. This is usually same as the email address that is used for associated Microsoft account. However, you could choose to specify a different email address for communication. So, technically, you could have a different Microsoft account, say with `account2@outlook.com` that is linked to nuget.org account with communication email address as `account1@outlook.com`. - -So the error above means that there already exists nuget.org account with communication email address `account1@outlook.com` but is associated with another Microsoft account with email **that is not** `account1@outlook.com`. - -**How do I find which Microsoft account is linked to this nuget.org account?** - -You should use the [sign in assistance](#which-microsoft-account-is-linked-to-my-nugetorg-account) flow to figure out which Microsoft account is linked to the nuget.org account with the email address `account1@outlook.com`. - -**I want to override that account with my Microsoft account** - -Follow the steps in [Unable to use microsoft login, how do I recover my nuget.org account](#unable-to-use-microsoft-login-how-do-i-recover-my-nugetorg-account) section to associate your Microsoft account with the existing nuget.org account. - -### Unable to use microsoft login, how do I recover my nuget.org account? - -If you tried using the [sign in assistance](#which-microsoft-account-is-linked-to-my-nugetorg-account) and you do not have access to the Microsoft account that is associated with your nuget.org account, please follow the steps below to link a new Microsoft account to your nuget.org account. -1. **Requirement**: You will need access to a Microsoft account which is not associated with any existing nuget.org accounts. If you do not have one, you can [create](https://signup.live.com) one. -2. If you've forgotten your username and password for your nuget.org account, follow the [steps to recover your password login](#how-to-recover-nugetorg-password-login). -3. [Login to nuget.org](https://www.nuget.org/users/account/LogOnNuGetAccount) using the username/password login. -4. Once logged in, you will see the popup dialog show up like below. This is the password discontinuation dialog box. -5. **NOTE**: Please ignore the instruction to login with the specified Microsoft account. You can now link your nuget.org account to any other Microsoft login. -6. Click on the button **Sign in with Microsoft** and login with the Microsoft account that you have an access to, as mentioned in step 1. -7. Your account will now be linked to the new Microsoft account, which you can use to log into nuget.org going forward. - - ![Link MSA Dialog](media/link-msa-dialog.png) - -### How to transform my nuget.org account to an organization? - -If you want to transform your account to an organization, and this account is already associated with a Microsoft account login, please follow the steps given in the documentation for [organizations on nuget org](organizations-on-nuget-org.md). - -If, however, your nuget.org account is not associated/linked with a Microsoft account, you can follow the steps below to transform this account to an organization. -1. **Requirement**: You need to have an individual account first created on nuget.org to be used as an admin on the org account. If you do not have one, please [create a new nuget.org account](individual-accounts.md) -2. Follow the [steps to recover your password login](#how-to-recover-nugetorg-password-login) for your nuget.org account if you do not have password login for it, if you do, skip this step. -3. [Login to nuget.org](https://www.nuget.org/users/account/LogOnNuGetAccount) using the username/password login. -4. Once logged in, you will see the popup dialog show up like below. This is the password discontinuation dialog box. - > [!Important] - > Ignore this dialog box, **do not** click on the **Sign in with microsoft** button. - -5. Go to [https://www.nuget.org/account/transform](https://www.nuget.org/account/transform). This will allow you to convert the nuget.org account to an org without linking to a Microsoft account. -6. Specify the admin username for your personal nuget.org account/the account you created in Step 1. -7. Follow the instructions to complete transformation of this account to an organization. - - ![Link MSA Dialog](media/link-msa-dialog.png) - -### nuget.org login issues for AAD accounts with unmanaged tenant? - -If you see an error like below during your login flow with your email account domain(@yourdomain.com), see the steps below to recover your nuget.org account. - -

    - -

    - -**What is this unmanaged state thing during login? And why is this happening now?** - -Your account seems to be previously registered as a personal Microsoft account and it worked fine, however, now it seems like your account has been registered as an "Unmanaged" tenant in the Azure Active Directory (the identity service which we use to authenticate Microsoft accounts). - -This could have happened if you or someone from your organization(with @yourdomain.com email address) registered with one of the AAD integrated services or did a [self-service signup for Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-self-service-signup), which creates such an "Unmanaged" tenant for the used Microsoft account domain(@yourdomain.com in your case). - -**What can I do to recover my account?** - -At this moment there is not a way for us (nuget.org) to authenticate accounts with such "Unmanaged" tenant accounts in Azure Active directory. We are looking in to a better way to authenticate such accounts. - -If you want to login to nuget.org with your Microsoft account(@yourdomain.com), you(or an administrator at your company) will need to claim the ownership of the AAD by doing a DNS validation to authenticate users with email address "@yourdomain.com". Please follow the steps for [domains admin takeover](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/domains-admin-takeover) documented by the Azure Active directory. Once this is done, your normal login should start working. - -**I don’t want to do all that, what is the other way to recover my account?** - -You can [create](https://www.microsoft.com/en-us/account) a new Microsoft account (with an email **not** associated with @yourdomain.com). Follow steps given in [recover your nuget.org account](#unable-to-use-microsoft-login-how-do-i-recover-my-nugetorg-account) section. - -### How do I change my nuget.org account username? - -You cannot. As a matter of policy we do not allow the change of usernames as of yet. The only way to change your username is to create a new account with the desired username. We recommend you delete your existing account before you create a new one, otherwise you will not be able to reuse your registered Microsoft account. -> [!Important] -> Deleting the user will still **reserve** the `username`. You will not be able to reuse the same username again and **this includes the change of casings**. As an example if you created a user with username `mycoolname` and you want to change this to `MyCoolName`(casing changes), it will not be possible after deleting the user. - -Follow the steps given in [delete your nuget.org account](#how-to-delete-my-nugetorg-account) section and to [register a new account](individual-accounts.md) with correct username. - -### How to delete my nuget.org account? - -To delete your account, please note that we recommend that you transfer the ownership of any packages where you are the sole owner. You can read more about [managing package owners](https://docs.microsoft.com/en-us/nuget/create-packages/publish-a-package#managing-package-owners-on-nugetorg) on how to do it. This will also help us expedite your request. - -If you are looking to transform your account to an organization, follow the steps given in [transform my nuget.org account to an organization](#how-to-transform-my-nugetorg-account-to-an-organization). - -> [!Important] -> Deleting the user will result in following: -> 1. Your username will be reserved and no one will be able to re-use it to create an individual account or an organization account -> 1. Revoke associated API key(s). -> 1. Remove the account as an owner for any child packages. -> 1. Dissociate all previously existent ID prefix reservations with this account. -> 1. Remove the account as a member of any organizations. - -Follow the following steps to proceed with account deletion. -1. [Login to nuget.org](https://www.nuget.org/users/account/LogOn) with the account you wish to delete. -2. Click on this url: [https://www.nuget.org/account/delete](https://www.nuget.org/account/delete) and follow the steps to submit the request for deleting the account. - -Our customer support will process this request and perform the account deletion. diff --git a/docs/nuget-org/nuget-org-faq.yml b/docs/nuget-org/nuget-org-faq.yml new file mode 100644 index 000000000..748ec0eea --- /dev/null +++ b/docs/nuget-org/nuget-org-faq.yml @@ -0,0 +1,271 @@ +### YamlMime:FAQ +metadata: + title: NuGet.org Frequently-Asked Questions + description: Common questions and answers for working with the NuGet gallery. + author: shishirx34 + ms.author: shishirh + ms.date: 06/05/2019 + ms.topic: conceptual + ms.custom: sfi-image-nochange + +title: NuGet.org frequently-asked questions +summary: | + +sections: + - name: License terms + questions: + - question: What are the default license terms if a package doesn't provide specific license information? + answer: | + Each package is governed by the terms that are included with the package. You should review the applicable terms before accessing, downloading, or acquiring any packages. On NuGet.org, use the **License Info** link on the package page. + + If a package does not specify the licensing terms, contact the package owner directly using the **Contact owners** link on the NuGet.org package page. Microsoft does not license any intellectual property to you from third party package providers and is not responsible for information provided by third parties. + + - name: Managing packages on NuGet.org + questions: + - question: Can I edit package metadata after it's been uploaded? + answer: | + NuGet recommends all packages to be signed. A design principle of package signing is that signed package content must be immutable, which includes the nuspec. Editing the package metadata results in changes to the nuspec, invalidating existing signatures. We recommend modifying existing workflows to not require editing the package metadata after the package has been created. + + Note that dependencies listed for your package are generated automatically from the package itself and cannot be edited. + + In addition, uploading packages to [int.nugettest.org](https://int.nugettest.org) is a great way to test and validate your package without making a package available in the public gallery. API Endpoint: https://apiint.nugettest.org/v3/index.json + + - question: Can I delete a package published to NuGet.org? + answer: | + In general, we do not support deleting a package published to NuGet.org. Read more about our [policy on deleting packages](policies/deleting-packages.md). + + - question: Is it possible to reserve names for packages that will be published in future? + answer: | + Yes. You can reserve IDs for packages on [NuGet.org](https://www.nuget.org/) by requesting a package ID prefix for your account. In order to request a package ID prefix, follow the instructions in the [documentation](id-prefix-reservation.md). + + - question: How do I claim ownership for packages ? + answer: | + See [Managing package owners on NuGet.org](../nuget-org/publish-a-package.md#managing-package-owners-on-nugetorg). + + - question: How do I deal with a package owner who is violating my software license? + answer: | + We encourage the NuGet community to work together to resolve any disputes that may arise between package owners and the owners of other software. We have crafted a [dispute resolution process](policies/dispute-resolution.md) to follow before asking NuGet.org administrators to intercede. + + - question: Is it recommended to upload my test packages to NuGet.org? + answer: | + For test purposes, you can use [int.nugettest.org](https://int.nugettest.org), or alternative public NuGet servers like [myget.org](https://myget.org) or [Azure DevOps](https://blogs.msdn.microsoft.com/visualstudioalm/2015/08/27/announcing-package-management-support-for-vsotfs/). + + Note that packages uploaded to int.nugettest.org may not be preserved. + + - question: What is the maximum size of packages I can upload to NuGet.org? + answer: | + NuGet.org allows packages up to 250MB, but we recommend keeping packages under 1MB if possible and using dependencies to link packages together. As a rule of thumb, packages contain only one assembly to avoid collisions. + + NuGet uses HTTP to download packages, so larger packages have a higher likelihood of failed installs than smaller ones. + + It is possible to share dependencies between multiple packages, making the total download size for consumers of your NuGet packages smaller. + + Dependencies are mostly static and never change. When fixing a bug in code, the dependencies may not need to be updated. If you bundle dependencies, you end up reshipping larger packages every time. By splitting NuGet packages into related dependencies, upgrades are much more fine-grained for consumers of your package. + + - name: NuGet.org not accessible + questions: + - question: What SSL/TLS version and cipher suites does NuGet.org support? + answer: | + NuGet.org supports TLS 1.2 and the following cipher suites: + - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 + - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 + - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 + + - question: Why can't I restore packages from NuGet.org? + answer: | + If you meet transient failures when restoring packages from NuGet.org, we suggest you: + - use the latest versions of NuGet clients with a better resilience support. + - use environment variables of NuGet clients to enhance the retry policy on CI machines. + + | Environment Variable | Description | Remarks | + | --- | --- | --- | + | NUGET_ENHANCED_MAX_NETWORK_TRY_COUNT | Configures the maximum number of times an HTTP connection should be retried when enhanced retries are enabled. | A number representing how many retries to perform, the default value is `6`. | + | NUGET_ENHANCED_NETWORK_RETRY_DELAY_MILLISECONDS | Configures the amount of time to wait in milliseconds before retrying an HTTP connection when enhanced retries are enabled. | Number of milliseconds to wait, the default value is `1000`. | + + > [!Note] + > These environment variables are available since [.NET CLI](https://learn.microsoft.com/nuget/reference/dotnet-commands) (.NET SDK) 6.0.100, [NuGet CLI](https://learn.microsoft.com/nuget/reference/nuget-exe-cli-reference) 6.0, Visual Studio 2022 version 17.0 and corresponding MSBuild version. See [NuGet Release Notes](https://learn.microsoft.com/nuget/release-notes/). + + > [!Important] + > NuGet.org recommends Alpine Linux users to upgrade to Alpine Linux 3.18.0 or newer. These versions support TCP fallback in the DNS resolver. If you use older versions of Alpine Linux that only support DNS over UDP, you may encounter DNS failures when accessing the [V3 API](https://learn.microsoft.com/nuget/nuget-org/overview-nuget-org#api-endpoint-for-nugetorg). + + If that version of NuGet client continues to fail, [contact support](https://www.nuget.org/policies/Contact) and provide additional connection troubleshooting information including: + - !!! Your geographical area + - The package sources you're using + - The version of NuGet client you're using + - A restore log with detailed verbosity + - MTR or a Fiddler traces (see below) + - Whether your machine is behind a proxy or firewall? + - Is your machine located on a cloud providers' data center (Azure, AWS etc)? If yes, please provide the name of the provider and the region. + + *To capture MTR:* + + - Download [WinMTR](https://sourceforge.net/projects/winmtr/files/WinMTR-v092.zip/download). + - Enter `api.nuget.org` as the hostname and click **Start**. + - Wait until the **Sent** column is >= 100. + + ![Capturing MTR](media/mtr.png) + + - Copy text to clipboard. + + *To capture Fiddler:* + + - Install the latest version of [Fiddler](https://www.telerik.com/download/fiddler). + - Start Fiddler and disable capturing traffic using the **File > Capture Traffic** menu. + - Remove all sessions (select all items in the list, press the **Delete** key). + - Configure Fiddler to capture HTTPS traffic by checking **Decrypt HTTPS traffic** in the **HTTPS** tab of the **Tools > Fiddler Options...** menu. + - Close Visual Studio. + - Enable the **File > Capture Traffic** menu. + - Start Visual Studio or nuget.exe .exe and perform the actions that are not working. The traffic generated by these actions should show up in Fiddler. + - Once the actions have run, use **File > Save > All Sessions** to store the captured sessions. + + Note: it may be required to set the `HTTP_PROXY` environment variable to `http://127.0.0.1:8888` for routing NuGet traffic through Fiddler. + + If that fails, try the [tips mentioned in this StackOverflow post](https://stackoverflow.com/questions/21049908/using-fiddler-to-sniff-visual-studio-2013-requests-proxy-firewall). + + - name: NuGet.org account management + questions: + - question: How to recover NuGet.org password login? + answer: | + Please note that the [NuGet.org Password login has been discontinued](https://blog.nuget.org/20180515/NuGet.org-will-only-support-MSA-AAD-starting-June.html). Unfortunately, NuGet.org has no way to recover password accounts, you can only log in to NuGet.org with a personal Microsoft account (MSA) or Azure Active Directory (AAD) account. + + If you are unable to use Microsoft login, [please follow the steps to recover your NuGet.org account](#unable-to-use-microsoft-login--how-do-i-recover-my-nuget-org-account). + + Please let us know if you need assistance in transferring ownership of your packages to a different account by sending an email to [support@nuget.org](mailto:support@nuget.org). + + - question: Which Microsoft account is linked to my NuGet.org account? + answer: | + If you have forgotten which Microsoft account is associated with your NuGet.org account, please follow the steps below to get assistance. + 1. Go to [NuGet.org login page](https://www.nuget.org/users/account/LogOn) and click on **Need assistance signing in?** link. + 1. This will show you the pop-up dialog box for assistance. Follow the steps in this dialog box to understand the associated Microsoft account(s) for your NuGet.org account. + + - question: How to change the Microsoft account I use for NuGet.org login? + answer: | + If you wish to change the Microsoft account for NuGet.org user, follow the steps below. Lets say your Microsoft account with email `account1@outlook.com` is associated with your NuGet.org account with username `MyNuGetAccount`. You wish to change the login to another Microsoft account with email `account2@outlook.com` + 1. Please sign in using **currently associated Microsoft account** i.e. `account1@outlook.com` on the [login page](https://www.nuget.org/users/account/LogOn) after clicking **Sign in with Microsoft**. + 1. Once logged in, go to your [account settings](https://www.nuget.org/account) page. + 1. Expand the section for **Login Account**. Click on the **Change Account** button. + 1. You will now be redirected to the microsoft login page. Please sign in with the account that you wish to change the association to i.e. `account2@outlook.com`. **Note**: you might need to click on **Sign out and sign in with different account** during the sign in flow to be able to login with a different Microsoft account. + 1. If you see an error like below, see [Microsoft account is linked with another NuGet.org account](#microsoft-account-is-linked-with-another-nuget-org-account) for more details. + >_Failed to update the Microsoft account with 'account2 '. This could happen if it is already linked to another NuGet account. Contact support for more information._ + + 1. Once you have successfully signed in with your second account, you will be redirected back to your NuGet.org account settings page and you should now see the new Microsoft account associated as the login account. Going forward you should use this account when signing into NuGet.org. + + - question: Microsoft account is linked with another NuGet.org account. + answer: | + If you tried changing your Microsoft login and saw the error below: + > _Failed to update the Microsoft account with 'account2 '. This could happen if it is already linked to another NuGet account. Contact support for more information._ + + Lets say you were trying to change Microsoft account login from `account1@outlook.com` for NuGet.org user with username `MyNuGetAccount1` to another Microsoft account with email `account2@outlook.com`. And you see the error above. + + **What does the error above mean? + + It means that there is another NuGet.org account which is associated with the Microsoft account that you are trying to change it to i.e. in above example the Microsoft account with email `` is associated with another NuGet.org account with, say, username `MyNuGetAccount2`. + + You cannot change the associated login with a Microsoft account that is linked to a different NuGet.org account. + + - question: I forgot I had another NuGet.org account, how do I find out which NuGet.org account it is? + answer: | + Login with the second Microsoft account on the [login page](https://www.nuget.org/users/account/LogOn?returnUrl=%2F# "login page"). This will log you into the NuGet.org account that is currently associated with the second Microsoft account. You can then view the uploaded packages and perform account management on this account. + + - question: I do not care about this second NuGet.org account, I want to change my login for first NuGet.org account with the second Microsoft account. What do I do? + answer: | + If you wish to not care about the second NuGet.org account and still want to re-use the associated Microsoft account with email `account2@outlook.com`. + + You can release the association between the Microsoft account and NuGet.org account by deleting the NuGet.org account. + 1. Follow the steps to [delete user](#how-to-delete-my-nuget-org-account) for the second NuGet.org account `MyNuGetAccount2`. + 1. Once this account is deleted, you can retry the steps to [change Microsoft account login](#how-to-change-the-microsoft-account-i-use-for-nuget-org-login). + + - question: Wait, I care about this second account too. I do not want to lose this account but change my associated account logins for first account. + answer: | + You will need to create/use a third Microsoft account, say, with email `account3@outlook.com`. + 1. First you should login with your second Microsoft account, `account2@outlook.com` on NuGet.org. Follow the steps above to change associated logins and associate the third Microsoft account with this NuGet.org account. + 1. Once done, your second Microsoft account with email `account2@outlook.com` is free to be associated to your first NuGet.org account, `MyNuGetAccount1`. Follow the same steps above to change microsoft logins to the second Microsoft account. + + - question: Signing in with Microsoft account shows me my email is linked to another Microsoft account + answer: | + If you tried to sign in with your Microsoft account, say, with email `account1@outlook.com` and you see an error like below: + > _The account with email 'account1@outlook.com' is linked with another microsoft account._ + > + > _If you would like to update the linked Microsoft account you can do so from the account settings page._ + + - question: What does the error above mean? + answer: | + When an account is created on NuGet.org, there is a communication email address associated with that account. This is usually same as the email address that is used for associated Microsoft account. However, you could choose to specify a different email address for communication. So, technically, you could have a different Microsoft account, say with `account2@outlook.com` that is linked to NuGet.org account with communication email address as `account1@outlook.com`. + + So the error above means that there already exists NuGet.org account with communication email address `account1@outlook.com` but is associated with another Microsoft account with email **that is not** `account1@outlook.com`. + + - question: How do I find which Microsoft account is linked to this NuGet.org account? + answer: | + You should use the [sign in assistance](#which-microsoft-account-is-linked-to-my-nuget-org-account) flow to figure out which Microsoft account is linked to the NuGet.org account with the email address `account1@outlook.com`. + + - question: Unable to use Microsoft login, how do I recover my NuGet.org account? + answer: | + If you tried using the [sign in assistance](#which-microsoft-account-is-linked-to-my-nuget-org-account) and you do not have access to the Microsoft account that is associated with your NuGet.org account, please contact your Microsoft account support: + + - Microsoft Account (MSA): [Get help with your Microsoft account](https://support.microsoft.com/account-billing/get-help-with-your-microsoft-account-ace6f3b3-e2d3-aeb1-6b96-d2e9e7e52133) + - Work or school account (AAD): [Work or school account help](https://support.microsoft.com/account-billing/work-or-school-account-help-718b3d92-a8a7-4656-8a05-c0228d346b7d) or contact your admin tenant. + + - question: How to transform my NuGet.org account to an organization? + answer: | + If you want to transform your account to an organization, please follow the steps given in the documentation for [organizations on nuget.org](organizations-on-nuget-org.md). + + - question: NuGet.org login issues for AAD accounts with unmanaged tenant? + answer: | + If you see an error like below during your login flow with your email account domain(@yourdomain.com), see the steps below to recover your NuGet.org account. + + ![Error during login for AAD accounts](media/unmanaged-aad-tenant.png) + + - question: What is this unmanaged state thing during login? And why is this happening now? + answer: | + Your account seems to be previously registered as a personal Microsoft account and it worked fine, however, now it seems like your account has been registered as an "Unmanaged" tenant in the Azure Active Directory (the identity service which we use to authenticate Microsoft accounts). + + This could have happened if you or someone from your organization(with @yourdomain.com email address) registered with one of the AAD integrated services or did a [self-service signup for Azure Active Directory](/azure/active-directory/users-groups-roles/directory-self-service-signup), which creates such an "Unmanaged" tenant for the used Microsoft account domain(@yourdomain.com in your case). + + - question: What can I do to recover my account? + answer: | + At this moment there is not a way for us (NuGet.org) to authenticate accounts with such "Unmanaged" tenant accounts in Azure Active directory. We are looking in to a better way to authenticate such accounts. + + If you want to login to NuGet.org with your Microsoft account(@yourdomain.com), you(or an administrator at your company) will need to claim the ownership of the AAD by doing a DNS validation to authenticate users with email address "@yourdomain.com". Please follow the steps for [domains admin takeover](/azure/active-directory/users-groups-roles/domains-admin-takeover) documented by the Azure Active directory. Once this is done, your normal login should start working. + + - question: How do I change my NuGet.org account username? + answer: | + You can request a username change by sending an email to [support@nuget.org](mailto:support@nuget.org) from the email address that is attached to the account you want to update. + Be sure to include the old username and the new username you would like to change to. + We will then review your request and, upon approval, get confirmation from you that we are about to take the correct action and that you understand the consequences. + Once you have confirmed, we will change your username. + + > [!Important] + > - The old username will still be **reserved**. You will not be able to reuse the old username again and **this includes the change of casings**. + > - As a consequence of the above, we will not be able to revert this change either. + > - Any links to your old username profile page (e.g. ```https://www.nuget.org/profiles/OldUsername```) will not be redirected to your new profile. + > - Package versions currently owned by your account will still contain the old username in the repository signature. New package versions will contain the new username. + > - Any author-provided metadata in the existing package versions referring to the old username or other identifying information will not be changed. + > - NuGet client policies asserting trust of your old username will not implicitly trust packages published by your new username. Package consumers with these client policies configured will need to manual update them to trust your new username when they attempt to update to a newly published package version. + + - question: How to delete my NuGet.org account? + answer: | + To delete your account, please note that we recommend that you transfer the ownership of any packages where you are the sole owner. You can read more about [managing package owners](../nuget-org/publish-a-package.md#managing-package-owners-on-nugetorg) on how to do it. This will also help us expedite your request. + + If you are looking to transform your account to an organization, follow the steps given in [transform my NuGet.org account to an organization](#how-to-transform-my-nuget-org-account-to-an-organization). + + > [!Important] + > Deleting the user will result in following: + > 1. Your username will be reserved and no one will be able to re-use it to create an individual account or an organization account + > 1. Revoke associated API key(s). + > 1. Remove the account as an owner for any child packages. + > 1. Dissociate all previously existent ID prefix reservations with this account. + > 1. Remove the account as a member of any organizations. + + Follow the following steps to proceed with account deletion. + 1. [Login to NuGet.org](https://www.nuget.org/users/account/LogOn) with the account you wish to delete. + 2. Click on this url: [https://www.nuget.org/account/delete](https://www.nuget.org/account/delete) and follow the steps to submit the request for deleting the account. + + Our customer support will process this request and perform the account deletion. + + - question: What happens to my NuGet.org account when my Microsoft account gets deleted? + answer: | + When the Microsoft or Azure Active Directory account you use to sign in to your nuget.org account is deleted, your nuget.org account will be deleted as well. The account delete action is completed by the nuget.org customer support within 30 days from the date of the Microsoft account deletion. + + If you have packages associated with your account, we will notify you 3 business days before proceeding with deletion and offer assistance to transfer the packages to a different nuget.org account. + diff --git a/docs/nuget-org/organizations-on-nuget-org.md b/docs/nuget-org/organizations-on-nuget-org.md index 4129a65e9..4c6b52990 100644 --- a/docs/nuget-org/organizations-on-nuget-org.md +++ b/docs/nuget-org/organizations-on-nuget-org.md @@ -8,6 +8,7 @@ ms.topic: conceptual ms.reviewer: - kraigb - camsoper +ms.custom: sfi-image-nochange --- # Your organization on NuGet.org @@ -101,4 +102,4 @@ You can delete an organization account by clicking the **Delete** button shown i ![Deleting an organization](media/org-delete-option.png) -To delete the organizaiton, you must confirm it by clicking the **Delete organization** confirmation button. +To delete the organization, you must confirm it by clicking the **Delete organization** confirmation button. diff --git a/docs/nuget-org/overview-nuget-org.md b/docs/nuget-org/overview-nuget-org.md index 43a0376c4..7dd9d8b6c 100644 --- a/docs/nuget-org/overview-nuget-org.md +++ b/docs/nuget-org/overview-nuget-org.md @@ -33,6 +33,10 @@ Once you have a NuGet package (*.nupkg* file) to publish, you publish it to NuGe When you [publish a package](../create-packages/creating-a-package.md), you include the API key value in the CLI command. +## Trusted publishing + +NuGet.org supports [Trusted Publishing](trusted-publishing.md), which is a secure and streamlined way to publish NuGet packages. + ## ID prefixes When you publish packages, you can reserve and protect your identity by [reserving ID prefixes](id-prefix-reservation.md). When installing a package, package consumers are provided with additional information indicating that the package they are consuming is not deceptive in its identifying properties. @@ -45,4 +49,4 @@ To use NuGet.org as a package repository with NuGet clients, you should use the Older clients can still use the V2 protocol to reach NuGet.org. However, please note, NuGet clients 3.0 or later will have slower and less reliable service using the V2 protocol: -`https://www.nuget.org/api/v2` (**The V2 prototcol is deprecated!**) +`https://www.nuget.org/api/v2` (**The V2 protocol is deprecated!**) diff --git a/docs/nuget-org/package-readme-on-nuget-org.md b/docs/nuget-org/package-readme-on-nuget-org.md new file mode 100644 index 000000000..b647d4dcf --- /dev/null +++ b/docs/nuget-org/package-readme-on-nuget-org.md @@ -0,0 +1,137 @@ +--- +title: Package readme on NuGet.org +description: Detailed explanation of how readme files on NuGet.org are rendered and what to do when you run into issues. +author: nkolev92 +ms.author: nikolev +ms.date: 08/31/2022 +ms.topic: conceptual +ms.reviewer: anangaur +--- + +# Package readme on NuGet.org + +[Include a readme file in your NuGet package](/nuget/reference/msbuild-targets#packagereadmefile) to make your package details richer and more informative for your users! + +This is likely one of the first elements users will see when they view your package details page on NuGet.org and is essential to making a good impression! + +> [!IMPORTANT] +> NuGet.org only supports readme files in [Markdown](https://daringfireball.net/projects/markdown/) and images from a limited set of domains. See our [allowed domains for images](#allowed-domains-for-images-and-badges) and [supported Markdown features](#supported-markdown-features) to ensure your readme renders correctly on NuGet.org. + +## What should my readme include? + +Consider including the following items in your readme: +* An introduction to what your package is and does - what problems does it solve? +* How to get started with your package - are there any specific requirements? +* Links to more comprehensive documentation if not included in the readme itself. +* At least a few code snippets/samples or example images. +* Where and how to leave feedback such as link to the project issues, Twitter, bug tracker, or other platform. +* How to contribute, if applicable. + +For example, you can start with this package README template: + +```text +# Package readme title, e.g., display name or title of the package (optional) + +Start with a clear and concise description: A brief overview of what your package is and does, also what problem it solves. + +## Getting started + +Explain how to use your package, provide clear and concise getting started instructions, including any necessary steps. + +### Prerequisites + +What are specific minimum requirements to use your packages? Consider excluding this section if your package works without any additional setup beyond simple package installation. + +## Usage + +Examples about how to use your package by providing code snippets/example images, or samples links on GitHub if applicable. + +- Provide sample code using code snippets +- Include screenshots, diagrams, or other visual help users better understand how to use your package + +## Additional documentation + +Provide links to more resources: List links such as detailed documentation, tutorial videos, blog posts, or any other relevant documentation to help users get the most out of your package. + +## Feedback + +Where and how users can leave feedback? + +- Links to a GitHub repository where could open issues, Twitter, a Discord channel, bug tracker, or other platforms where a package consumer can connect with the package author. +``` + +Keep in mind, high quality readmes can come in a wide variety of formats, shapes, and sizes! If you already have a package available on NuGet.org, chances are that you already have a `readme.md` or other documentation file in your repository that would be a great addition to your NuGet.org details page. + +> [!Note] +> Read through our [blog on writing a high-quality README](https://devblogs.microsoft.com/nuget/write-a-high-quality-readme-for-nuget-packages/) for some best practices. + +## Preview your readme + +To preview your readme file before it's live on NuGet.org, upload your package using the [Upload Package web portal on NuGet.org](/nuget/nuget-org/publish-a-package#web-portal-use-the-upload-package-tab-on-nugetorg) and scroll down to the "Readme File" section of the metadata preview. It should look something like this: + +![Readme File preview](media\readme-upload-preview.PNG) + +Consider taking time to review and preview your readme file for [image compliance](#allowed-domains-for-images-and-badges) and [supported formatting](#supported-markdown-features) to make sure it gives a great first impression to potential users! To correct mistakes on your package readme once it's published to NuGet.org, you will need to push an updated package version with the fix. Making sure everything looks good in advance may save you headache down the road. +## Allowed domains for images and badges + +Due to security and privacy concerns, NuGet.org restricts the domains from which images and badges can be rendered to trusted hosts. + +NuGet.org allows all images, including badges, from the following trusted domains to be rendered: +* api.codacy.com +* api.codeclimate.com +* api.dependabot.com +* api.reuse.software +* api.travis-ci.com +* app.codacy.com +* app.deepsource.com +* avatars.githubusercontent.com +* badgen.net +* badges.gitter.im +* camo.githubusercontent.com +* caniuse.bitsofco.de +* cdn.jsdelivr.net +* cdn.syncfusion.com +* ci.appveyor.com +* circleci.com +* cloudback.it +* codecov.io +* codefactor.io +* coveralls.io +* dev.azure.com +* flat.badgen.net +* github.com/.../workflows/.../badge.svg +* gitlab.com +* i.imgur.com +* img.shields.io +* infragistics.com +* isitmaintained.com +* media.githubusercontent.com +* opencollective.com +* raw.github.com +* raw.githubusercontent.com +* snyk.io +* sonarcloud.io +* travis-ci.com +* travis-ci.org +* user-images.githubusercontent.com + +If you feel that another domain should be added to the allow-list, please feel free to [file an issue](https://github.com/NuGet/NuGetGallery/issues) and it will be reviewed by our engineering team for privacy and security compliance. Images with relative local paths and images hosted from unsupported domains will not be rendered and will produce a warning on the readme file preview and package details page that is only visible to the package owners. + +## Supported Markdown features +[Markdown](https://daringfireball.net/projects/markdown/) is a lightweight markup language with plain text formatting syntax. NuGet.org readmes support [CommonMark](https://commonmark.org/) compliant Markdown through the [Markdig](https://github.com/lunet-io/markdig) parsing engine. + +NuGet.org currently supports the following Markdown features: +* [Headers](https://spec.commonmark.org/0.29/#atx-headings) +* [Images](https://spec.commonmark.org/0.29/#images) +* [Extra emphasis](https://github.com/xoofx/markdig/blob/master/src/Markdig.Tests/Specs/EmphasisExtraSpecs.md) +* [Lists](https://spec.commonmark.org/0.29/#lists) +* [Links](https://spec.commonmark.org/0.29/#links) +* [Block quotes](https://spec.commonmark.org/0.29/#block-quotes) +* [Backslash escapes](https://spec.commonmark.org/0.29/#backslash-escapes) +* [Code spans](https://spec.commonmark.org/0.29/#code-spans) +* [Task lists](https://github.com/xoofx/markdig/blob/master/src/Markdig.Tests/Specs/TaskListSpecs.md) +* [Tables](https://github.com/xoofx/markdig/blob/master/src/Markdig.Tests/Specs/PipeTableSpecs.md) +* [Emojis](https://github.com/xoofx/markdig/blob/master/src/Markdig.Tests/Specs/EmojiSpecs.md) +* [Auto-links](https://github.com/xoofx/markdig/blob/master/src/Markdig.Tests/Specs/AutoLinks.md) + +We also support syntax highlighting, You can add an language identifier to enable syntax highlighting in your code spans. diff --git a/docs/nuget-org/policies/data-requests.md b/docs/nuget-org/policies/data-requests.md index 61166e32d..57cab4356 100644 --- a/docs/nuget-org/policies/data-requests.md +++ b/docs/nuget-org/policies/data-requests.md @@ -1,8 +1,8 @@ --- title: User Data Requests description: Policies for requesting user data export and delete -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 05/01/2018 ms.topic: conceptual --- diff --git a/docs/nuget-org/policies/deleting-packages.md b/docs/nuget-org/policies/deleting-packages.md index 6d1221197..89fbd5a3b 100644 --- a/docs/nuget-org/policies/deleting-packages.md +++ b/docs/nuget-org/policies/deleting-packages.md @@ -1,8 +1,8 @@ --- title: Deleting NuGet Packages from nuget.org description: Policies for unlisting packages from nuget.org; permanent deletion is not supported except when packages violate other policies. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 01/18/2018 ms.topic: conceptual --- @@ -11,7 +11,7 @@ ms.topic: conceptual nuget.org does not support permanent deletion of packages. Doing so would break every project depending on the availability of the package, especially with build workflows that involve package restore. -nuget.org does supports *unlisting* a package, which can be done in the package management page on the web site. Unlisted packages don't appear on nuget.org or in the Visual Studio UI, and do not appear in search results. Unlisted packages, however, can still be downloaded and installed by using an exact version number, which supports package restore. In addition, unlisted packages may still be discovered in the following specific scenarios: +nuget.org does support [unlisting a package](#unlisting-a-package), which can be done in the package management page on the web site. Unlisted packages don't appear on nuget.org or in the Visual Studio UI, and do not appear in search results. Unlisted packages, however, can still be downloaded and installed by using an exact version number, which supports package restore. In addition, unlisted packages may still be discovered in the following specific scenarios: - Package restore using floating versions (for example, `1.0.0-*`), if the latest available package matching the version or dependency constraints is an unlisted package. - Replication of packages through the catalog (as the catalog also contains unlisted packages). @@ -30,7 +30,22 @@ Packages that meet any of the following criteria are not allowed on the public N - Contains illegal content. - Are being used to squat on package identifiers, including packages that have zero productive content. Packages must contain code or the owners must concede the identifier to someone who actually has a product to ship. - Attempt to make the gallery do something that it's not explicitly designed to do. +- Violates the [nuget.org Terms of Use or Code of Conduct](https://www.nuget.org/policies/Terms) in any way. Terms such as "unexpected", "discriminatory", "hateful", and "abusive" are evaluated and decided at the sole discretion of the NuGet team. If you find a package that is in violation of any of these items, click the **Report Abuse** link on the package details page and submit a report. Note that the NuGet team and the .NET Foundation reserves the right to change these criteria at any time. + +## Unlisting a package +Unlisting a package version hides it from search and from nuget.org package details page. This allows existing users of the package to continue using it but reduces new adoption since the package is not visible in search. + +Steps to unlist a package: + +1. Select `Your account name` (at the top right corner) >`Manage packages` > `Published packages` +1. Select the "Manage package" icon +1. Expand the "Listing" section and select the package version +1. Uncheck “List in search results” and select "Save" + +The specific package version has now been unlisted. In order to verify this, logout of your account and navigate to the package page (without the version part) e.g.: ```https://www.nuget.org/packages/YOUR-PACKAGE-NAME/```. You will see all versions of that package that have **not** been unlisted. However, the package owner, when logged in, can see all versions and their listing status. + +It's also possible to deprecate a package version (in case you can't delete a package version). For more information about deprecating package versions, see [Deprecating packages](../deprecate-packages.md). diff --git a/docs/nuget-org/policies/dispute-resolution.md b/docs/nuget-org/policies/dispute-resolution.md index a0812ca5c..94a1aea40 100644 --- a/docs/nuget-org/policies/dispute-resolution.md +++ b/docs/nuget-org/policies/dispute-resolution.md @@ -1,8 +1,8 @@ --- title: "NuGet Package Name Dispute Resolution" description: The process for resolving disputes between NuGet package publishers related to branding, trademarks, and other conflict situations. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 01/18/2018 ms.topic: conceptual --- @@ -15,7 +15,7 @@ For example, suppose that Northwind Traders makes a CRM system for which they pr In this scenario, Nancy does not appear to be acting with bad intentions, but is rather supporting Northwind's tools and customers by contributing her own time and code. At the same time, Northwind is the legitimate owner of the Northwind name. -By following the process below, Northwind and Nancy can work together to a suitable resolution, because both are interested in serving the developer community. It's typically not necessary for the NuGet team to become involved; collaboration usually works out best. In fact, every dispute brought to the NuGet team's attention to date has been worked out without the team needing to pass judgment. +By following the process below, Northwind and Nancy can work together to a suitable resolution, because both are interested in serving the developer community. It's typically not necessary for the NuGet team to become involved; collaboration usually works out best. ## Process diff --git a/docs/nuget-org/policies/export-control.md b/docs/nuget-org/policies/export-control.md index 2a79589f3..a0ce51d75 100644 --- a/docs/nuget-org/policies/export-control.md +++ b/docs/nuget-org/policies/export-control.md @@ -1,8 +1,8 @@ --- title: Export Control Policy description: Policies governing export control laws -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 06/27/2019 ms.topic: conceptual --- @@ -23,4 +23,4 @@ As specified in the EAR (Part 742.15(b) & 734.3(b)(3)), the person or entity pro Release of publicly available source code from export control jurisdiction through the notification process described above *does not apply* to commercial software incorporating or derived from such items. You are solely responsible for compliance with Export Laws as applied to any commercial software incorporating or derived from source or object code hosted via NuGet.org. -For further information on export and geographic export restrictions, please visit https://www.microsoft.com/en-us/exporting. +For further information on export and geographic export restrictions, please visit [Microsoft Exporting](https://www.microsoft.com/exporting). diff --git a/docs/nuget-org/scoped-api-keys.md b/docs/nuget-org/scoped-api-keys.md index 66f2d4462..6730218cf 100644 --- a/docs/nuget-org/scoped-api-keys.md +++ b/docs/nuget-org/scoped-api-keys.md @@ -44,7 +44,7 @@ In the following example, you have an API key named `Contoso service CI` that ca If you are working on multiple packages and have a large list of packages to manage, you can choose to use globbing patterns to select multiple packages together. For example, if you wish to grant specific scopes to a key for all packages whose ID starts with `Fabrikam.Service`, you could do this by specifying `fabrikam.service.*` in the **Glob pattern** text box. -![Create API keys](media/scoped-api-keys-glob-pattern.png) +![Create API keys - 2](media/scoped-api-keys-glob-pattern.png) Using glob patterns to determine API key permissions also applies to new packages matching the glob pattern. For example, if you try to push a new package named `Fabrikam.Service.Framework`, you can do that with the key created previously, since the package matches the glob pattern `fabrikam.service.*`. @@ -52,19 +52,19 @@ Using glob patterns to determine API key permissions also applies to new package For security, a newly created key is never shown on the screen and is only available using the **Copy** button. Similarly, the key is not accessible after the page is refreshed. -![Create API keys](media/scoped-api-keys-obtain-keys.png) +![Create API keys - 3](media/scoped-api-keys-obtain-keys.png) ## Edit existing API keys You may also want to update the key permissions and scopes without changing the key itself. If you have a key with specific scope(s) for a single package, you can choose to apply the same scope(s) on one or many other packages. -![Create API keys](media/scoped-api-keys-edit.png) +![Create API keys - 4](media/scoped-api-keys-edit.png) ## Refresh or delete existing API keys The account owner can choose to refresh the key, in which case the permission (on packages), scope, and expiry remain the same, but a new key is issued making the old key unusable. This is helpful in managing stale keys or where there is any potential for an API key leakage. -![Create API keys](media/scoped-api-keys-refresh.png) +![Create API keys - 5](media/scoped-api-keys-refresh.png) You may also choose to delete these keys if they are not needed anymore. Deleting a key removes the key and makes it unusable. diff --git a/docs/nuget-org/trusted-publishing.md b/docs/nuget-org/trusted-publishing.md new file mode 100644 index 000000000..f5c5ed529 --- /dev/null +++ b/docs/nuget-org/trusted-publishing.md @@ -0,0 +1,121 @@ +--- +title: Trusted Publishing +description: Trusted Publishing on nuget.org +author: etvorun +ms.author: evgenyt +ms.date: 07/01/2025 +ms.topic: conceptual +--- + +# Trusted Publishing on nuget.org + +Trusted Publishing is a better way to publish NuGet packages. You don’t need to manage long-lived API keys anymore. Instead, you use short-lived credentials issued by your CI/CD system, like GitHub Actions. + +This makes your publishing process safer by reducing the risk of leaked credentials. It also makes automation easier because you don’t need to rotate or store secrets. This approach is part of a broader industry shift toward secure, keyless publishing. If you're curious, check out the OpenSSF initiative: https://repos.openssf.org/trusted-publishers-for-all-package-repositories. + +> ⚠️ **Heads up:** If you don’t see the **Trusted Publishing** option in your nuget.org account, it might not be available to you yet. We’re rolling it out gradually. + +## How it works + +When your GitHub Actions workflow runs, it requests an encrypted OIDC token from github.com. This token +includes information about your repository and workflow, and is cryptographically signed by GitHub Actions to prevent +tampering. The workflow forwards this token to nuget.org, which securely validates the token’s +authenticity with github.com using industry-standard cryptographic methods. A token exchange endpoint on nuget.org then checks +that the token’s details match a trusted publishing policy you’ve configured. If everything matches, +nuget.org issues a short-lived API key for your workflow to use when publishing your package. + +**Here’s the basic flow** + +1. Your CI/CD system (like GitHub Actions) runs a workflow. +2. It issues a short-lived token. +3. That token is sent to nuget.org. +4. NuGet verifies it and returns a temporary API key. +5. Your workflow uses that key to push the package. + +![Screenshot that shows Trusted Publishing page.](media/trusted-publishing.png) + +NuGet’s temporary API keys are valid for **1 hour**, so your workflow should request the key shortly before publishing. +If you request it too early, it might expire before the push happens. + +Each short-lived token can only be used once to obtain a single temporary API key—one token, one API key. + +This setup gives you a secure and automated way to publish packages, without the risks that come with long-lived secrets. + + +## GitHub Actions Setup + +To get started: + +1. Log into **nuget.org**. +2. Click your username and choose **Trusted Publishing**. +3. Add a new trusted publishing policy. For a GitHub repository `https://github.com/contoso/contoso-sdk` + with a workflow file `.github/workflows/build.yml` enter the following trusted policy details (case‑insensitive): + - **Repository Owner:** `contoso` + - **Repository:** `contoso-sdk` + - **Workflow File:** `build.yml` + > This corresponds to your workflow at `.github/workflows/build.yml`. Enter the **file name only** (`build.yml`)—do not include the `.github/workflows/` path. + - **Environment (optional):** `release` + > Enter environment if your workflow uses e.g. `environment: release` and you want to restrict this policy to that environment. Leave this empty if you do not use GitHub Actions environments. +4. In your **GitHub repo**, update your workflow to request a short‑lived API key and push your package. +Here’s a basic example: + +```yaml +jobs: + build-and-publish: + permissions: + id-token: write # enable GitHub OIDC token issuance for this job + + steps: + # Build your artifacts/my-sdk.nupkg package here + + # Get a short-lived NuGet API key + - name: NuGet login (OIDC → temp API key) + uses: NuGet/login@v1 + id: login + with: + user: contoso-bot # Recommended: use a secret like ${{ secrets.NUGET_USER }} for your nuget.org username (profile name), NOT your email address + + # Push the package + - name: NuGet push + run: dotnet nuget push artifacts/my-sdk.nupkg --api-key ${{steps.login.outputs.NUGET_API_KEY}} --source https://api.nuget.org/v3/index.json +``` + + +## Policy Ownership + +When you create a Trusted Publishing policy, you need to choose who owns it. The owner can be either: + +- **You (an individual user)** +- **An organization you belong to** + +The policy will apply to all packages owned by the selected owner. That means it controls who can publish or modify those packages using Trusted Publishing. + +If you choose an organization, make sure you're an active member. If you leave the org later, the policy may become inactive until you're added back. + +Choosing the right owner helps ensure your publishing setup stays secure and aligned with your team’s structure. + + +## Policies Pending Full Activation + +Sometimes when you create a Trusted Publishing policy, it starts out as temporarily active for 7 days. This usually happens with private GitHub repos. You’ll see this status in the UI. During that time, it behaves like a regular policy. But if no publish happens within those 7 days, the policy automatically becomes inactive. You can restart the 7-day window at any time—even after it expires. + +Why is this temporary period necessary? Because NuGet needs GitHub repository and owner IDs to lock the policy to the original repo and owner. That helps prevent resurrection attacks. Without those IDs, someone could delete a repo, recreate it with the same name, and try to publish as if nothing changed. + +Once a successful publish provides the IDs (as part of GitHub’s short-lived token), the policy becomes permanently active. + + +## Policy Ownership Warnings + +Trusted Publishing policies are tied to a specific owner—either an individual user or an organization. +If something changes with that ownership, the policy might become inactive. When that happens, you'll see a warning in the UI. + +### Common cases + +- **User removed from organization** + If a policy is owned by an organization and the user who created it is later removed from that org, the policy becomes inactive. + If the user is added back to the organization, the policy will be active again automatically. + +- **Organization is no longer active** + If the organization that owns the policy is locked or deleted, the policy becomes inactive. + +These warnings help make sure that only active, secure policies are used when publishing packages. diff --git a/docs/policies/Ecosystem.md b/docs/policies/Ecosystem.md index cbe1f8b02..4a4c52c4c 100644 --- a/docs/policies/Ecosystem.md +++ b/docs/policies/Ecosystem.md @@ -1,8 +1,8 @@ --- title: Overview of the NuGet Ecosystem description: Comprehensive resources in the NuGet ecosystem including NuGet sources, non-Microsoft NuGet projects, utilities, and training materials. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 01/18/2018 ms.topic: conceptual --- @@ -17,7 +17,7 @@ All of these projects are able to innovate because of developer contributions. J ## .NET Foundation projects -NuGet provides a free, open source package management system for the Microsoft development platform. It consists of a few client tools as well as the set of services that comprise the [official NuGet Gallery](http://www.nuget.org). Combined, these form the NuGet project which is governed by the [.NET Foundation](http://www.dotnetfoundation.org/). +NuGet provides a free, open source package management system for the Microsoft development platform. It consists of a few client tools as well as the set of services that comprise the [official NuGet Gallery](https://www.nuget.org). Combined, these form the NuGet project which is governed by the [.NET Foundation](https://www.dotnetfoundation.org/). The NuGet Organization contains various repositories on GitHub. [https://github.com/Nuget/Home](https://github.com/Nuget/Home) gives an overview of all the repositories and where to find the various NuGet components. @@ -33,14 +33,16 @@ Many other individuals and companies have made significant contributions to the - [Artifactory](https://www.jfrog.com/artifactory/) - [BoxStarter](http://boxstarter.org/) - [Chocolatey](https://chocolatey.org/) -- [CoApp](http://coapp.org/) +- [CoApp](https://github.com/coapp/coapp.org) - [JetBrains ReSharper](https://resharper-plugins.jetbrains.com/) +- [JetBrains Space](https://www.jetbrains.com/space/) - [JetBrains TeamCity](https://www.jetbrains.com/teamcity/) - [Klondike](https://github.com/themotleyfool/Klondike) - [MinimalNugetServer](https://github.com/TanukiSharp/MinimalNugetServer) - [MyGet (or NuGet-as-a-service)](http://www.myget.org/) - [NuGet Package Explorer](https://github.com/NuGetPackageExplorer/NuGetPackageExplorer) - [NuGet Server](http://nugetserver.net/) +- [NuGetizer](https://github.com/devlooped/nugetizer) - [OctopusDeploy](https://octopus.com/) - [Paket](https://fsprojects.github.io/Paket/) - [ProGet (Inedo)](http://inedo.com/proget) @@ -54,24 +56,24 @@ Many other individuals and companies have made significant contributions to the These are tools and utilities built on NuGet: -- [Glimpse Extensions](http://getglimpse.com/Packages) (plug-ins are packages) +- [Glimpse Extensions](https://meetglimpse.com/) - [NuGetMustHaves.com](http://nugetmusthaves.com/) - [Orchard](http://www.orchardproject.net/) (CMS modules are fetched from a v1 NuGet feed hosted in the Orchard Gallery) - [Java implementation of NuGet Server](http://jonnyzzz.com/blog/2012/03/07/nuget-server-in-pure-java/) - [NuGetLatest](https://twitter.com/NuGetLatest) (Twitter bot tweeting new package publications) -- [DefinitelyTyped](http://definitelytyped.org/) ([Automatic](https://github.com/DefinitelyTyped/NugetAutomation/) TypeScript Type [Definitions published to NuGet](http://www.nuget.org/packages?q=DefinitelyTyped)) +- [DefinitelyTyped](http://definitelytyped.org/) ([Automatic](https://github.com/DefinitelyTyped/NugetAutomation/) TypeScript Type [Definitions published to NuGet](https://www.nuget.org/packages?q=DefinitelyTyped)) ## Training materials and references -Using a new tool or technology usually comes with a learning curve. Luckily for you, NuGet has no steep learning curve it all! In fact, anyone can [get started consuming packages](../quickstart/use-a-package.md) quickly. +Using a new tool or technology usually comes with a learning curve. Luckily for you, NuGet has no steep learning curve it all! In fact, anyone can [get started consuming packages](../quickstart/install-and-use-a-package-in-visual-studio.md) quickly. That said, authoring packages–and especially good packages–along with embracing NuGet in automated build and deployment processes, requires spending a little more time with the following resources: -- [NuGet Blog](http://blog.nuget.org/) -- [NuGet team on Twitter, @nuget](http://twitter.com/nuget) +- [NuGet Blog](https://devblogs.microsoft.com/nuget/) +- [NuGet team on Twitter, @nuget](https://twitter.com/nuget) - Books: - [Apress Pro NuGet](http://bit.ly/ProNuGet) - - [NuGet 2 Essentials](http://www.amazon.com/NuGet-2-Essentials-Damir-Arh-ebook/dp/B00GTQD5M4) + - [NuGet 2 Essentials](https://www.amazon.com/NuGet-2-Essentials-Damir-Arh/dp/178216586X) ## Documentation for individual packages diff --git a/docs/policies/Governance.md b/docs/policies/Governance.md index 885b91d84..fce9b9a5e 100644 --- a/docs/policies/Governance.md +++ b/docs/policies/Governance.md @@ -1,8 +1,8 @@ --- title: NuGet Project Governance description: The governance model for NuGet, including roles and responsibilities for committers, contributors, and users. -author: karann-msft -ms.author: karann +author: JonDouglas +ms.author: jodou ms.date: 01/18/2018 ms.topic: conceptual --- diff --git a/docs/quickstart/create-and-publish-a-package-using-the-dotnet-cli.md b/docs/quickstart/create-and-publish-a-package-using-the-dotnet-cli.md index fee81ffa8..1c662c94d 100644 --- a/docs/quickstart/create-and-publish-a-package-using-the-dotnet-cli.md +++ b/docs/quickstart/create-and-publish-a-package-using-the-dotnet-cli.md @@ -1,88 +1,88 @@ --- -title: Create and publish a NuGet package using the dotnet CLI -description: A walkthrough tutorial on creating and publishing a NuGet package using the .NET Core CLI, dotnet. -author: karann-msft -ms.author: karann -ms.date: 05/24/2019 +title: Create and publish a NuGet package with the dotnet CLI +description: Walk through quickly creating and publishing a NuGet package by using the dotnet CLI. +author: JonDouglas +ms.author: jodou +ms.date: 03/03/2025 ms.topic: quickstart --- -# Quickstart: Create and publish a package (dotnet CLI) +# Quickstart: Create and publish a package with the dotnet CLI -It's a simple process to create a NuGet package from a .NET Class Library and publish it to nuget.org using the `dotnet` command-line interface (CLI). +This quickstart shows you how to quickly create a NuGet package from a .NET class library and publish it to nuget.org by using the .NET command-line interface, or [dotnet CLI](/dotnet/core/tools). ## Prerequisites -1. Install the [.NET Core SDK](https://www.microsoft.com/net/download/), which includes the `dotnet` CLI. Starting in Visual Studio 2017, the dotnet CLI is automatically installed with any .NET Core related workloads. +- The [.NET SDK](https://www.microsoft.com/net/download), which provides the dotnet command-line tool. Starting in Visual Studio 2017, the dotnet CLI automatically installs with any .NET or .NET Core related workloads. -1. [Register for a free account on nuget.org](https://www.nuget.org/users/account/LogOn?returnUrl=%2F) if you don't have one already. Creating a new account sends a confirmation email. You must confirm the account before you can upload a package. +- A free account on nuget.org. Follow the instructions at [Add a new individual account](../nuget-org/individual-accounts.md#add-a-new-individual-account). ## Create a class library project -You can use an existing .NET Class Library project for the code you want to package, or create a simple one as follows: +You can use an existing .NET Class Library project for the code you want to package, or create a simple project as follows: -1. Create a folder called `AppLogger` and change into it. +1. Create a folder named *AppLogger*. +1. Open a command prompt and switch to the *AppLogger* folder. All the dotnet CLI commands in this quickstart run on the current folder by default. +1. Enter `dotnet new classlib`, which creates a project with the current folder name. -1. Create the project using `dotnet new classlib`, which uses the name of the current folder for the project. +For more information, see [dotnet new](/dotnet/core/tools/dotnet-new). ## Add package metadata to the project file -Every NuGet package needs a manifest that describes the package's contents and dependencies. In a final package, the manifest is a `.nuspec` file that is generated from the NuGet metadata properties that you include in the project file. +Every NuGet package has a manifest that describes the package's contents and dependencies. In the final package, the manifest is a *.nuspec* file, which uses the NuGet metadata properties you include in the project file. -1. Open your project file (`.csproj`) and add the following minimal properties inside the existing `` tag, changing the values as appropriate: +Open the *.csproj*, *.fsproj*, or *.vbproj* project file, and add the following properties inside the existing `` tag. Use your own values for name and company, and replace the package identifier with a unique value. - ```xml - AppLogger - 1.0.0 - your_name - your_company - ``` +```xml +Contoso.08.28.22.001.Test +1.0.0 +your_name +your_company +``` - > [!Important] - > Give the package an identifier that's unique across nuget.org or whatever host you're using. For this walkthrough we recommend including "Sample" or "Test" in the name as the later publishing step does make the package publicly visible (though it's unlikely anyone will actually use it). +> [!Important] +> The package identifier must be unique across nuget.org and other package sources. Publishing makes the package publicly visible, so if you use the example AppLogger library or other test library, use a unique name that includes `Sample` or `Test`. -1. Add any optional properties described on [NuGet metadata properties](/dotnet/core/tools/csproj#nuget-metadata-properties). +You can add any optional properties described in [NuGet metadata properties](../reference/msbuild-targets.md#pack-target). - > [!Note] - > For packages built for public consumption, pay special attention to the **PackageTags** property, as tags help others find your package and understand what it does. +> [!Note] +> For packages you build for public consumption, pay special attention to the `PackageTags` property. Tags help others find your package and understand what it does. ## Run the pack command -To build a NuGet package (a `.nupkg` file) from the project, run the `dotnet pack` command, which also builds the project automatically: +To build a NuGet package or *.nupkg* file from the project, run the [dotnet pack](/dotnet/core/tools/dotnet-pack) command, which also builds the project automatically. -```cli -# Uses the project file in the current folder by default +```dotnetcli dotnet pack ``` -The output shows the path to the `.nupkg` file: +The output shows the path to the *.nupkg* file: ```output -Microsoft (R) Build Engine version 15.5.180.51428 for .NET Core -Copyright (C) Microsoft Corporation. All rights reserved. - - Restore completed in 29.91 ms for D:\proj\AppLoggerNet\AppLogger\AppLogger.csproj. - AppLogger -> D:\proj\AppLoggerNet\AppLogger\bin\Debug\netstandard2.0\AppLogger.dll - Successfully created package 'D:\proj\AppLoggerNet\AppLogger\bin\Debug\AppLogger.1.0.0.nupkg'. -``` +MSBuild version 17.3.0+92e077650 for .NET + Determining projects to restore... + Restored C:\Users\myname\source\repos\AppLogger\AppLogger.csproj (in 64 ms). + AppLogger -> C:\Users\myname\source\repos\AppLogger\bin\Debug\net6.0\AppLogger.dll + Successfully created package 'C:\Users\myname\source\repos\AppLogger\bin\Debug\Contoso.08.28.22.001.Test.1.0.0.nupkg'. + ``` ### Automatically generate package on build -To automatically run `dotnet pack` when you run `dotnet build`, add the following line to your project file within ``: +To automatically run `dotnet pack` whenever you run `dotnet build`, add the following line to your project file within ``: ```xml -true + true ``` ## Publish the package -Once you have a `.nupkg` file, you publish it to nuget.org using the `dotnet nuget push` command along with an API key acquired from nuget.org. +Publish your *.nupkg* file to nuget.org by using the [dotnet nuget push](/dotnet/core/tools/dotnet-nuget-push) command with an API key you get from nuget.org. [!INCLUDE [publish-notes](includes/publish-notes.md)] -### Acquire your API key +### Get your API key -[!INCLUDE [publish-api-key](includes/publish-api-key.md)] +[!INCLUDE [publish-api-key](includes/publish-api-key-with-link.md)] ### Publish with dotnet nuget push @@ -96,19 +96,29 @@ Once you have a `.nupkg` file, you publish it to nuget.org using the `dotnet nug [!INCLUDE [publish-manage](includes/publish-manage.md)] +Congratulations on creating and publishing your first NuGet package! + +## Related video + +> [!VIDEO https://learn-video.azurefd.net/vod/player?show=dotnet-package-management-with-nuget-for-beginners&ep=creating-and-publishing-a-nuget-package-nuget-for-beginners] + +Find more NuGet videos on [Channel 9](/shows/NuGet-101/) and [YouTube](https://www.youtube.com/playlist?list=PLdo4fOcmZ0oVLvfkFk8O9h6v2Dcdh2bh_). + ## Next steps -Congratulations on creating your first NuGet package! + +See more details about how to create packages with the dotnet CLI: > [!div class="nextstepaction"] -> [Create a Package](../create-packages/creating-a-package-dotnet-cli.md) +> [Create a NuGet package with the dotnet CLI](../create-packages/creating-a-package-dotnet-cli.md) -To explore more that NuGet has to offer, select the links below. +Get more information about creating and publishing NuGet packages: -- [Publish a Package](../nuget-org/publish-a-package.md) -- [Pre-release Packages](../create-packages/Prerelease-Packages.md) +- [Publish a package](../nuget-org/publish-a-package.md) +- [Prerelease packages](../create-packages/Prerelease-Packages.md) - [Support multiple target frameworks](../create-packages/multiple-target-frameworks-project-file.md) -- [Package versioning](../reference/package-versioning.md) -- [Creating localized packages](../create-packages/creating-localized-packages.md) -- [Creating symbol packages](../create-packages/symbol-packages-snupkg.md) -- [Signing packages](../create-packages/Sign-a-package.md) +- [Package versioning](../concepts/package-versioning.md) +- [Add a license expression or file](../reference/msbuild-targets.md#packing-a-license-expression-or-a-license-file) +- [Create localized packages](../create-packages/creating-localized-packages.md) +- [Create symbol packages](../create-packages/symbol-packages-snupkg.md) +- [Sign packages](../create-packages/Sign-a-package.md) diff --git a/docs/quickstart/create-and-publish-a-package-using-visual-studio-net-framework.md b/docs/quickstart/create-and-publish-a-package-using-visual-studio-net-framework.md index b230b3988..694fbab75 100644 --- a/docs/quickstart/create-and-publish-a-package-using-visual-studio-net-framework.md +++ b/docs/quickstart/create-and-publish-a-package-using-visual-studio-net-framework.md @@ -1,106 +1,111 @@ --- -title: Create and publish a .NET Framework NuGet package using Visual Studio on Windows -description: A walkthrough tutorial on creating and publishing a .NET Framework NuGet package using Visual Studio on Windows. -author: karann-msft -ms.author: karann -ms.date: 05/13/2018 +title: "Quickstart: Create and publish a package using Visual Studio (.NET Framework, Windows)" +description: A quickstart that shows how to create and publish a .NET Framework NuGet package using Visual Studio on Windows. +author: JonDouglas +ms.author: jodou +ms.date: 03/03/2025 ms.topic: quickstart --- # Quickstart: Create and publish a package using Visual Studio (.NET Framework, Windows) -Creating a NuGet package from a .NET Framework Class Library involves creating the DLL in Visual Studio on Windows, then using the nuget.exe command line tool to create and publish the package. +With Microsoft Visual Studio, you can create a NuGet package from a .NET Framework class library, and then publish it to nuget.org using the NuGet CLI tool. -> [!Note] -> This Quickstart applies to Visual Studio 2017 for Windows only. Visual Studio for Mac does not include the capabilities described here. Use the [dotnet CLI tools](create-and-publish-a-package-using-the-dotnet-cli.md) instead. +The quickstart is for Windows users only. If you're using Visual Studio for Mac, see [dotnet CLI tools](create-and-publish-a-package-using-the-dotnet-cli.md) instead. ## Prerequisites -1. Install any edition of Visual Studio 2017 from [visualstudio.com](https://www.visualstudio.com/) with any .NET-related workload. Visual Studio 2017 automatically includes NuGet capabilities when a .NET workload is installed. +- Install Visual Studio 2022 for Windows with any .NET-related workload. -1. Install the `nuget.exe` CLI by downloading it from [nuget.org](https://dist.nuget.org/win-x86-commandline/latest/nuget.exe), saving that `.exe` file to a suitable folder, and adding that folder to your PATH environment variable. + You can install the 2022 Community edition for free from [visualstudio.microsoft.com](https://visualstudio.microsoft.com/), or use the Professional or Enterprise edition. -1. [Register for a free account on nuget.org](https://www.nuget.org/users/account/LogOn?returnUrl=%2F) if you don't have one already. Creating a new account sends a confirmation email. You must confirm the account before you can upload a package. + Visual Studio 2017 and higher automatically includes NuGet capabilities when a .NET workload is installed. + +- [Register for a free account on nuget.org](../nuget-org/individual-accounts.md#add-a-new-individual-account) if you don't have one already. You must register and confirm the account before you can upload a NuGet package. + +- Install the NuGet CLI by downloading it from [nuget.org](https://dist.nuget.org/win-x86-commandline/latest/nuget.exe). Add the *nuget.exe* file to a suitable folder, and add that folder to your PATH environment variable. ## Create a class library project -You can use an existing .NET Framework Class Library project for the code you want to package, or create a simple one as follows: +To create a class library project, follow these steps: + +1. In Visual Studio, select **File** > **New** > **Project**. -1. In Visual Studio, choose **File > New > Project**, select the **Visual C#** node, select the "Class Library (.NET Framework)" template, name the project AppLogger, and click **OK**. +1. In the **Create a new project** window, select **C#**, **Windows**, and **Library** in the dropdown lists. -1. Right-click on the resulting project file and select **Build** to make sure the project was created properly. The DLL is found within the Debug folder (or Release if you build that configuration instead). +1. In the resulting list of project templates, select **Class Library (.NET Framework)**, and then select **Next**. -Within a real NuGet package, of course, you implement many useful features with which others can build applications. You can also set the target frameworks however you like. For example, see the guides for [UWP](../guides/create-uwp-packages.md) and [Xamarin](../guides/create-packages-for-xamarin.md). +1. In the **Configure your new project** window, enter *AppLogger* for the **Project name**, and then select **Create**. -For this walkthrough, however, you won't write any additional code because a class library from the template is sufficient to create a package. Still, if you'd like some functional code for the package, use the following: +1. To ensure the project was created properly, select **Build** > **Build Solution**. The DLL is found within the Debug folder (or Release if you build that configuration instead). -```cs -using System; +1. (Optional) For this quickstart, you don't need to write any additional code for the NuGet package because the template class library is sufficient to create a package. However, if you'd like some functional code for this sample package, include the following code: -namespace AppLogger -{ - public class Logger - { - public void Log(string text) - { - Console.WriteLine(text); - } - } -} -``` + ```csharp + namespace AppLogger + { + public class Logger + { + public void Log(string text) + { + Console.WriteLine(text); + } + } + } + ``` -> [!Tip] -> Unless you have a reason to choose otherwise, .NET Standard is the preferred target for NuGet packages, as it provides compatibility with the widest range of consuming projects. See [Create and publish a package using Visual Studio (.NET Standard)](create-and-publish-a-package-using-visual-studio.md). + Within a real-world NuGet package, you'd likely implement many useful features with which others can build applications. You can also set the target frameworks. For an example, see [UWP](../guides/create-uwp-packages.md). ## Configure project properties for the package -A NuGet package contains a manifest (a `.nuspec` file), that contains relevant metadata such as the package identifier, version number, description, and more. Some of these can be drawn from the project properties directly, which avoids having to separately update them in both the project and the manifest. This section describes where to set the applicable properties. +A NuGet package includes a manifest (a `.nuspec` file), that contains relevant metadata such as the package identifier, version number, description, and more. Some of this metadata can be drawn from the project properties directly, which avoids having to separately update them in both the project and the manifest. The following steps describe how to set the applicable properties: -1. Select the **Project > Properties** menu command, then select the **Application** tab. +1. Select **Project > Properties**, and then select the **Application** tab. -1. In the **Assembly name** field, give your package a unique identifier. +1. For **Assembly name**, give your package a unique identifier. If you attempt to publish a package with a name that already exists, you see an error. - > [!Important] - > You must give the package an identifier that's unique across nuget.org or whatever host you're using. For this walkthrough we recommend including "Sample" or "Test" in the name as the later publishing step does make the package publicly visible (though it's unlikely anyone will actually use it). - > - > If you attempt to publish a package with a name that already exists, you see an error. + > [!IMPORTANT] + > You must give the package an identifier that's unique across nuget.org or whatever host you're using. Otherwise, an error occurs. For this quickstart we recommend including *Sample* or *Test* in the name because the publishing step makes the package publicly visible. -1. Select the **Assembly Information...** button, which brings up a dialog box in which you can enter other properties that carry into the manifest (see [.nuspec file reference - replacement tokens](../reference/nuspec.md#replacement-tokens)). The most commonly used fields are **Title**, **Description**, **Company**, **Copyright**, and **Assembly version**. These properties ultimately appear with your package on a host like nuget.org, so make sure they're fully descriptive. +1. Select **Assembly Information**, which displays a dialog box in which you can enter other properties that carry into the manifest (see [Replacement tokens](../reference/nuspec.md#replacement-tokens)). The most commonly used fields are **Title**, **Description**, **Company**, **Copyright**, and **Assembly version**. Because these properties appear with your package on a host like nuget.org after you publish it, make sure they're fully descriptive. - ![Assembly information in a .NET Framework project in Visual Studio](media/qs_create-vs-01b-project-properties.png) + :::image type="content" source="media/qs-create-vs-assembly-information.png" alt-text="Screenshot showing the Assembly Information page in a .NET Framework project in Visual Studio."::: -1. Optional: to see and edit the properties directly, open the `Properties/AssemblyInfo.cs` file in the project. +1. (Optional) To see and edit the properties directly, open the *Properties/AssemblyInfo.cs* file in the project by selecting select **Project** > **Edit Project File**. -1. When the properties are set, set the project configuration to **Release** and rebuild the project to generate the updated DLL. +1. After you've set these properties, set the **Active solution configuration** in **Build** > **Configuration Manager** to **Release** and rebuild the project to generate the updated DLL. ## Generate the initial manifest -With a DLL in hand and project properties set, you now use the `nuget spec` command to generate an initial `.nuspec` file from the project. This step includes the relevant replacement tokens to draw information from the project file. +After you've set the project properties and created the DLL, you can now generate an initial *.nuspec* file from the project. This step includes the relevant replacement tokens to draw information from the project file. + +Run `nuget spec` only once to generate the initial manifest. If you update the package, either change values in your project, or edit the manifest directly: + +1. With your project open in **Solution Explorer**, open a command prompt by selecting **Tools** > **Command Line** > **Developer Command Prompt**. -You run `nuget spec` only once to generate the initial manifest. When updating the package, you either change values in your project or edit the manifest directly. + The command prompt opens in your project directory where the `AppLogger.csproj` file is located. -1. Open a command prompt and navigate to the project folder containing `AppLogger.csproj` file. +1. Run the following command: `nuget spec AppLogger.csproj`. -1. Run the following command: `nuget spec AppLogger.csproj`. By specifying a project, NuGet creates a manifest that matches the name of the project, in this case `AppLogger.nuspec`. It also include replacement tokens in the manifest. + NuGet creates a manifest that matches the name of the project, in this case `AppLogger.nuspec`. It also includes replacement tokens in the manifest. -1. Open `AppLogger.nuspec` in a text editor to examine its contents, which should appear as follows: +1. Open `AppLogger.nuspec` in a text editor to examine its contents, which will be similar to the following code: ```xml - $id$ - $version$ - $title$ - $author$ - $author$ - http://LICENSE_URL_HERE_OR_DELETE_THIS_LINE + Package + 1.0.0 + Your username + Your username + MIT + http://PROJECT_URL_HERE_OR_DELETE_THIS_LINE - http://ICON_URL_HERE_OR_DELETE_THIS_LINE false - $description$ + Package description Summary of changes made in this release of the package. - Copyright 2018 + Copyright 2022 Tag1 Tag2 @@ -108,56 +113,63 @@ You run `nuget spec` only once to generate the initial manifest. When updating t ## Edit the manifest -1. NuGet produces an error if you try to create a package with default values in your `.nuspec` file, so you must edit the following fields before proceeding. See [.nuspec file reference - optional metadata elements](../reference/nuspec.md#optional-metadata-elements) for a description of how these are used. +1. Edit the following properties before proceeding. Otherwise, if you try to create a NuGet package with the default values in your `.nuspec` file, an error occurs. For information about these properties, see [Optional metadata elements](../reference/nuspec.md#optional-metadata-elements): - licenseUrl - projectUrl - - iconUrl - releaseNotes - tags -1. For packages built for public consumption, pay special attention to the **Tags** property, as tags help others find your package on sources like nuget.org and understand what it does. +1. For packages built for public consumption, pay special attention to the **Tags** property, as tags help others find your package and understand what it does. -1. You can also add any other elements to the manifest at this time, as described on [.nuspec file reference](../reference/nuspec.md). +1. You can also add any other elements to the manifest at this time, as described in [.nuspec file reference](../reference/nuspec.md). 1. Save the file before proceeding. ## Run the pack command -1. From a command prompt in the folder containing your `.nuspec` file, run the command `nuget pack`. +1. With your project open in **Solution Explorer**, open a command prompt by selecting **Tools** > **Command Line** > **Developer Command Prompt**. -1. NuGet generates a `.nupkg` file in the form of *identifier-version.nupkg*, which you'll find in the current folder. + The command prompt opens in your project directory. + +1. Run the following command: `nuget pack`. + + NuGet generates a *.nupkg* file in the form of *identifier.version.nupkg* in the current folder. ## Publish the package -Once you have a `.nupkg` file, you publish it to nuget.org using `nuget.exe` with an API key acquired from nuget.org. For nuget.org you must use `nuget.exe` 4.1.0 or higher. +After you've created a *.nupkg* file, publish it to nuget.org by using the NuGet CLI with an API key acquired from nuget.org. For nuget.org, you must use `nuget.exe` 4.1.0 or higher. + +If you'd like to test and validate your package before publishing it a public gallery, you can upload it to a test environment like [int.nugettest.org](https://int.nugettest.org) instead of nuget.org. Note that packages uploaded to int.nugettest.org may not be preserved. [!INCLUDE [publish-notes](includes/publish-notes.md)] ### Acquire your API key -[!INCLUDE [publish-api-key](includes/publish-api-key.md)] +[!INCLUDE [publish-api-key](includes/publish-api-key-with-link.md)] + +### Publish with the NuGet CLI -### Publish with nuget push +Using the NuGet CLI (*nuget.exe*) is an alternative to using the .NET CLI: -1. Open a command line and change to the folder containing the `.nupkg` file. +1. Open a command prompt and change to the folder containing the *.nupkg* file. -1. Run the following command, specifying your package name and replacing the key value with your API key: +1. Run the following command. Replace \ with the file name of your package and replace \ with your API key. The package filename is a concatenation of your package ID and version number with a *.nupkg* extension. For example, *AppLogger.1.0.0.nupkg*: ```cli - nuget push AppLogger.1.0.0.nupkg qz2jga8pl3dvn2akksyquwcs9ygggg4exypy3bhxy6w6x6 -Source https://api.nuget.org/v3/index.json + nuget push -Source https://api.nuget.org/v3/index.json ``` -1. nuget.exe displays the results of the publishing process: + The result of the publishing process is displayed as follows: ```output - Pushing AppLogger.1.0.0.nupkg to 'https://www.nuget.org/api/v2/package'... + Pushing to 'https://www.nuget.org/api/v2/package'... PUT https://www.nuget.org/api/v2/package/ Created https://www.nuget.org/api/v2/package/ 6829ms Your package was pushed. ``` -See [nuget push](../reference/cli-reference/cli-ref-push.md). +For more information, see [nuget push](../reference/cli-reference/cli-ref-push.md). ### Publish errors @@ -169,15 +181,15 @@ See [nuget push](../reference/cli-reference/cli-ref-push.md). ## Next steps -Congratulations on creating your first NuGet package! +Congratulations on creating a NuGet package by using the Visual Studio .NET Framework. Advance to the next article to learn how to create a NuGet package with the NuGet CLI. > [!div class="nextstepaction"] -> [Create a Package](../create-packages/creating-a-package.md) +> [Create a package using the NuGet CLI](../create-packages/creating-a-package.md) -To explore more that NuGet has to offer, select the links below. +To explore more that NuGet has to offer, see the following articles: -- [Publish a Package](../nuget-org/publish-a-package.md) -- [Pre-release Packages](../create-packages/Prerelease-Packages.md) +- [Publish a package](../nuget-org/publish-a-package.md) +- [Build a prerelease package](../create-packages/Prerelease-Packages.md) - [Support multiple target frameworks](../create-packages/supporting-multiple-target-frameworks.md) -- [Package versioning](../reference/package-versioning.md) -- [Creating localized packages](../create-packages/creating-localized-packages.md) +- [Package versioning](../concepts/package-versioning.md) +- [Creating a localized package](../create-packages/creating-localized-packages.md) diff --git a/docs/quickstart/create-and-publish-a-package-using-visual-studio.md b/docs/quickstart/create-and-publish-a-package-using-visual-studio.md index 8884323c3..dd1169c71 100644 --- a/docs/quickstart/create-and-publish-a-package-using-visual-studio.md +++ b/docs/quickstart/create-and-publish-a-package-using-visual-studio.md @@ -1,151 +1,189 @@ --- -title: Create and publish a .NET Standard NuGet package using Visual Studio on Windows -description: A walkthrough tutorial on creating and publishing a .NET Standard NuGet package using Visual Studio on Windows. -author: karann-msft -ms.author: karann -ms.date: 07/09/2019 +title: "Quickstart: Create and publish a NuGet package using Visual Studio (Windows only)" +description: A quickstart that shows how to create and publish a .NET NuGet package using Visual Studio for Windows. +author: JonDouglas +ms.author: jodou +ms.date: 03/03/2025 ms.topic: quickstart --- -# Quickstart: Create and publish a NuGet package using Visual Studio (.NET Standard, Windows only) +# Quickstart: Create and publish a NuGet package using Visual Studio (Windows only) -It's a simple process to create a NuGet package from a .NET Standard Class Library in Visual Studio on Windows, and then publish it to nuget.org using a CLI tool. +With Microsoft Visual Studio, you can create a NuGet package from a .NET class library, and then publish it to nuget.org using a CLI tool. -> [!Note] -> If you are using Visual Studio for Mac, refer to [this information](/xamarin/cross-platform/app-fundamentals/nuget-multiplatform-libraries/existing-library) on creating a NuGet package, or use the [dotnet CLI tools](create-and-publish-a-package-using-the-dotnet-cli.md). +The quickstart is for Windows users only. If you're using a Mac, use the [.NET CLI](create-and-publish-a-package-using-the-dotnet-cli.md). ## Prerequisites -1. Install any edition of Visual Studio 2017 or higher from [visualstudio.com](https://www.visualstudio.com/) with a .NET Core related workload. +- Install Visual Studio 2022 for Windows with a .NET Core-related workload. -1. If it's not already installed, install the `dotnet` CLI. + You can install the 2022 Community edition for free from [visualstudio.microsoft.com](https://visualstudio.microsoft.com/), or use the Professional or Enterprise edition. - For the `dotnet` CLI, starting in Visual Studio 2017, the `dotnet` CLI is automatically installed with any .NET Core related workloads. Otherwise, install the [.NET Core SDK](https://www.microsoft.com/net/download/) to get the `dotnet` CLI. The `dotnet` CLI is required for .NET Standard projects that use the [SDK-style format](../resources/check-project-format.md) (SDK attribute). The default class library template in Visual Studio 2017 and higher, which is used in this article, uses the SDK attribute. - - > [!Important] - > For this article, the `dotnet` CLI is recommended. Although you can publish any NuGet package using the `nuget.exe` CLI, some of the steps in this article are specific to SDK-style projects and the dotnet CLI. The nuget.exe CLI is used for [non-SDK-style projects](../resources/check-project-format.md) (typically .NET Framework). If you are working with a non-SDK-style project, follow the procedures in [Create and publish a .NET Framework package (Visual Studio)](create-and-publish-a-package-using-visual-studio-net-framework.md) to create and publish the package. + Visual Studio 2017 and later automatically includes NuGet capabilities when you install a .NET-related workload. -1. [Register for a free account on nuget.org](https://docs.microsoft.com/en-us/nuget/nuget-org/individual-accounts#add-a-new-individual-account) if you don't have one already. Creating a new account sends a confirmation email. You must confirm the account before you can upload a package. +- Install the .NET CLI, if it's not already installed. + + For Visual Studio 2017 and later, the .NET CLI is automatically installed with any .NET Core-related workload. Otherwise, install the [.NET Core SDK](https://www.microsoft.com/net/download/) to get the .NET CLI. The .NET CLI is required for .NET projects that use the [SDK-style format](../resources/check-project-format.md) (SDK attribute). The default .NET class library template in Visual Studio 2017 and later uses the SDK attribute. + + > [!IMPORTANT] + > If you're working with a non-SDK-style project, follow the procedures in [Create and publish a .NET Framework package (Visual Studio)](create-and-publish-a-package-using-visual-studio-net-framework.md) instead to create and publish the package. For this article, the .NET CLI is recommended. Although you can publish any NuGet package using the NuGet CLI, some of the steps in this article are specific to SDK-style projects and the .NET CLI. The NuGet CLI is used for [non-SDK-style projects](../resources/check-project-format.md) (typically .NET Framework). + +- [Register for a free account on nuget.org](../nuget-org/individual-accounts.md#add-a-new-individual-account) if you don't have one already. You must register and confirm the account before you can upload a NuGet package. + +- Install the NuGet CLI by downloading it from [nuget.org](https://dist.nuget.org/win-x86-commandline/latest/nuget.exe). Add the *nuget.exe* file to a suitable folder, and add that folder to your PATH environment variable. ## Create a class library project -You can use an existing .NET Standard Class Library project for the code you want to package, or create a simple one as follows: +You can use an existing .NET Class Library project for the code you want to package, or create one as follows: -1. In Visual Studio, choose **File > New > Project**, expand the **Visual C# > .NET Standard** node, select the "Class Library (.NET Standard)" template, name the project AppLogger, and click **OK**. +1. In Visual Studio, select **File** > **New** > **Project**. -1. Right-click on the resulting project file and select **Build** to make sure the project was created properly. The DLL is found within the Debug folder (or Release if you build that configuration instead). +1. In the **Create a new project** window, select **C#**, **Windows**, and **Library** in the dropdown lists. -Within a real NuGet package, of course, you implement many useful features with which others can build applications. For this walkthrough, however, you won't write any additional code because a class library from the template is sufficient to create a package. Still, if you'd like some functional code for the package, use the following: +1. In the resulting list of project templates, select **Class Library** (with the description, *A project for creating a class library that targets .NET or .NET Standard*), and then select **Next**. -```cs -namespace AppLogger -{ - public class Logger - { - public void Log(string text) - { - Console.WriteLine(text); - } - } -} -``` +1. In the **Configure your new project** window, enter *AppLogger* for the **Project name**, and then select **Next**. + +1. In the **Additional information** window, select an appropriate **Framework**, and then select **Create**. + + If you're unsure which framework to select, the latest is a good choice, and can be easily changed later. For information about which framework to use, see [When to target .NET 5.0 or .NET 6.0 vs. .NET Standard](/dotnet/standard/net-standard#when-to-target-net50-or-net60-vs-netstandard). + +1. To ensure the project was created properly, select **Build** > **Build Solution**. The DLL is found within the Debug folder (or Release if you build that configuration instead). -> [!Tip] -> Unless you have a reason to choose otherwise, .NET Standard is the preferred target for NuGet packages, as it provides compatibility with the widest range of consuming projects. +1. (Optional) For this quickstart, you don't need to write any additional code for the NuGet package because the template class library is sufficient to create a package. However, if you'd like some functional code for the package, include the following code: + + ```csharp + namespace AppLogger + { + public class Logger + { + public void Log(string text) + { + Console.WriteLine(text); + } + } + } + ``` ## Configure package properties -1. Right-click the project in Solution Explorer, and choose **Properties** menu command, then select the **Package** tab. +After you've created your project, you can configure the NuGet package properties by following these steps: + +1. Select your project in **Solution Explorer**, and then select **Project** > **\ Properties**, where \ is the name of your project. + +1. Expand the **Package** node, and then select **General**. + + The **Package** node appears only for SDK-style projects in Visual Studio. If you're' targeting a non-SDK style project (typically .NET Framework), either [migrate the project](../consume-packages/migrate-packages-config-to-package-reference.md), or see [Create and publish a .NET Framework package](create-and-publish-a-package-using-visual-studio-net-framework.md) for step-by-step instructions. - The **Package** tab appears only for SDK-style projects in Visual Studio, typically .NET Standard or .NET Core class library projects; if you are targeting a non-SDK style project (typically .NET Framework), either [migrate the project](../reference/migrate-packages-config-to-package-reference.md) and use `dotnet` CLI, or see [Create and publish a .NET Framework package](create-and-publish-a-package-using-visual-studio-net-framework.md) or see [Create and publish a .NET Framework package](create-and-publish-a-package-using-visual-studio-net-framework.md) instead for step-by-step instructions. + :::image type="content" source="media/qs-create-vs-project-properties.png" alt-text="Screenshot showing NuGet package properties in a Visual Studio project."::: - ![NuGet package properties in a Visual Studio project](media/qs_create-vs-01-package-properties.png) +1. For packages built for public consumption, pay special attention to the **Tags** property, as tags help others find your package and understand what it does. - > [!Note] - > For packages built for public consumption, pay special attention to the **Tags** property, as tags help others find your package and understand what it does. +1. Give your package a unique **Package ID** and fill out any other desired properties. For a table that shows how MSBuild properties (SDK-style projects) map to *.nuspec* file properties, see [pack targets](../reference/msbuild-targets.md#pack-target). For a description of *.nuspec* file properties, see the [.nuspec file reference](../reference/nuspec.md). All of these properties go into the `.nuspec` manifest that Visual Studio creates for the project. -1. Give your package a unique identifier and fill out any other desired properties. For a description of the different properties, see [.nuspec file reference](../reference/nuspec.md). All of the properties here go into the `.nuspec` manifest that Visual Studio creates for the project. + > [!IMPORTANT] + > You must give the package an identifier that's unique across nuget.org or whatever host you're using. Otherwise, an error occurs. For this quickstart we recommend including *Sample* or *Test* in the name because the publishing step makes the package publicly visible. - > [!Important] - > You must give the package an identifier that's unique across nuget.org or whatever host you're using. For this walkthrough we recommend including "Sample" or "Test" in the name as the later publishing step does make the package publicly visible (though it's unlikely anyone will actually use it). - > - > If you attempt to publish a package with a name that already exists, you see an error. +1. (Optional) To see the properties directly in the *AppLogger.csproj* project file, select **Project** > **Edit Project File**. -1. Optional: to see the properties directly in the project file, right-click the project in Solution Explorer and select **Edit AppLogger.csproj**. + The **AppLogger.csproj** tab loads. - This option is only available starting in Visual Studio 2017 for projects that use the SDK-style attribute. Otherwise, right-click the project and choose **Unload Project**. Then right-click the unloaded project and choose **Edit AppLogger.csproj**. + This option is available starting in Visual Studio 2017 for projects that use the SDK-style attribute. For earlier Visual Studio versions, you must select **Project** > **Unload Project** before you can edit the project file. ## Run the pack command -1. Set the configuration to **Release**. +To create a NuGet package from your project, follow these steps: -1. Right click the project in **Solution Explorer** and select the **Pack** command: +1. Select **Build** > **Configuration Manager**, and then set the **Active solution configuration** to **Release**. - ![NuGet pack command on the Visual Studio project context menu](media/qs_create-vs-02-pack-command.png) +1. Select the AppLogger project in **Solution Explorer**, then select **Pack**. - If you don't see the **Pack** command, your project is probably not an SDK-style project and you need to use the `nuget.exe` CLI. Either [migrate the project](../reference/migrate-packages-config-to-package-reference.md) and use `dotnet` CLI, or see [Create and publish a .NET Framework package](create-and-publish-a-package-using-visual-studio-net-framework.md) instead for step-by-step instructions. + Visual Studio builds the project and creates the *.nupkg* file. -1. Visual Studio builds the project and creates the `.nupkg` file. Examine the **Output** window for details (similar to the following), which contains the path to the package file. Note also that the built assembly is in `bin\Release\netstandard2.0` as befits the .NET Standard 2.0 target. +1. Examine the **Output** window for details, which contains the path to the package file. In this example, the built assembly is in *bin\Release\net6.0* as befits a .NET 6.0 target: ```output 1>------ Build started: Project: AppLogger, Configuration: Release Any CPU ------ - 1>AppLogger -> d:\proj\AppLogger\AppLogger\bin\Release\netstandard2.0\AppLogger.dll + 1>AppLogger -> d:\proj\AppLogger\AppLogger\bin\Release\net6.0\AppLogger.dll 1>Successfully created package 'd:\proj\AppLogger\AppLogger\bin\Release\AppLogger.1.0.0.nupkg'. ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== ``` -### Alternate option: pack with MSBuild +1. If you don't see the **Pack** command on the menu, your project is probably not an SDK-style project, and you need to use the NuGet CLI. Either [migrate the project](../consume-packages/migrate-packages-config-to-package-reference.md) and use .NET CLI, or see [Create and publish a .NET Framework package](create-and-publish-a-package-using-visual-studio-net-framework.md) for step-by-step instructions. -As an alternate to using the **Pack** menu command, NuGet 4.x+ and MSBuild 15.1+ supports a `pack` target when the project contains the necessary package data. Open a command prompt, navigate to your project folder and run the following command. (You typically want to start the "Developer Command Prompt for Visual Studio" from the Start menu, as it will be configured with all the necessary paths for MSBuild.) +### (Optional) Generate package on build -```cli -msbuild -t:pack -p:Configuration=Release -``` +You can configure Visual Studio to automatically generate the NuGet package when you build the project: + +1. Select your project in **Solution Explorer**, and then select **Project** > **\ Properties**, where \ is the name of your project (AppLogger in this case). + +1. Expand the **Package** node, select **General**, and then select **Generate NuGet package on build**. -The package can then be found in the `bin\Release` folder. + :::image type="content" source="media/qs-create-vs-generate-on-build.png" alt-text="Screenshot showing package properties with Generate NuGet package on build selected."::: -For additional options with `msbuild -t:pack`, see [NuGet pack and restore as MSBuild targets](../reference/msbuild-targets.md#pack-target). +> [!NOTE] +> When you automatically generate the package, the extra time to pack increases the overall build time for your project. + +### (Optional) Pack with MSBuild + +As an alternative to using the **Pack** menu command, NuGet 4.x+ and MSBuild 15.1+ supports a `pack` target when the project contains the necessary package data: + +1. With your project open in **Solution Explorer**, open a command prompt by selecting **Tools** > **Command Line** > **Developer Command Prompt**. + + The command prompt opens in your project directory. + +1. Run the following command: `msbuild -t:pack`. + +For more information, see [Create a package using MSBuild](../create-packages/creating-a-package-msbuild.md). ## Publish the package -Once you have a `.nupkg` file, you publish it to nuget.org using either the `nuget.exe` CLI or the `dotnet.exe` CLI along with an API key acquired from nuget.org. +After you've created a *.nupkg* file, publish it to nuget.org by using either the .NET CLI or the NuGet CLI, along with an API key acquired from nuget.org. [!INCLUDE [publish-notes](includes/publish-notes.md)] ### Acquire your API key -[!INCLUDE [publish-api-key](includes/publish-api-key.md)] +Before you publish your NuGet package, create an API key: + +[!INCLUDE [publish-api-key](includes/publish-api-key-with-link.md)] + +### Publish with the .NET CLI or NuGet CLI -### Publish with dotnet nuget push (dotnet CLI) +Each of the following CLI tools allows you to push a package to the server and publish it. Select the tab for your CLI tool, either **.NET CLI** or **NuGet CLI**. -This step is the recommended alternative to using `nuget.exe`. +#### [.NET CLI](#tab/netcore-cli) -Before you can publish the package, you must first open a command line. +Using the .NET CLI (*dotnet.exe*) is the recommended alternative to using the NuGet CLI. [!INCLUDE [publish-dotnet](includes/publish-dotnet.md)] -### Publish with nuget push (nuget.exe CLI) +#### [NuGet CLI](#tab/nuget) -This step is an alternative to using `dotnet.exe`. +Using the NuGet CLI (*nuget.exe*) is an alternative to using the .NET CLI: -1. Open a command line and change to the folder containing the `.nupkg` file. +1. Open a command prompt and change to the folder containing the *.nupkg* file. -1. Run the following command, specifying your package name (unique package ID) and replacing the key value with your API key: +1. Run the following command. Replace \ with the file name of your package and replace \ with your API key. - ```cli - nuget push AppLogger.1.0.0.nupkg qz2jga8pl3dvn2akksyquwcs9ygggg4exypy3bhxy6w6x6 -Source https://api.nuget.org/v3/index.json + The NuGet CLI generates a *.nupkg* file in the form of *package ID-version.nupkg*. For example, *AppLogger.1.0.0.nupkg*: + + ```nuget + nuget push -Source https://api.nuget.org/v3/index.json ``` -1. nuget.exe displays the results of the publishing process: + The result of the publishing process is displayed as follows: ```output - Pushing AppLogger.1.0.0.nupkg to 'https://www.nuget.org/api/v2/package'... + Pushing to 'https://www.nuget.org/api/v2/package'... PUT https://www.nuget.org/api/v2/package/ Created https://www.nuget.org/api/v2/package/ 6829ms Your package was pushed. ``` -See [nuget push](../reference/cli-reference/cli-ref-push.md). +For more information, see [nuget push](../reference/cli-reference/cli-ref-push.md). + +--- ### Publish errors @@ -155,9 +193,9 @@ See [nuget push](../reference/cli-reference/cli-ref-push.md). [!INCLUDE [publish-manage](includes/publish-manage.md)] -## Adding a readme and other files +## Add a readme or another file -To directly specify files to include in the package, edit the project file and use the `content` property: +To directly specify files to include in the package, edit the project file and add the `content` property: ```xml @@ -168,20 +206,46 @@ To directly specify files to include in the package, edit the project file and u ``` -This will include a file named `readme.txt` in the package root. Visual Studio displays the contents of that file as plain text immediately after installing the package directly. (Readme files are not displayed for packages installed as dependencies). For example, here's how the readme for the HtmlAgilityPack package appears: +In this example, the property specifies a file named *readme.txt* in the project root. Visual Studio displays the contents of that file as plain text immediately after it installs the package. Readme files aren't displayed for packages installed as dependencies. For example, here's the readme for the HtmlAgilityPack package: + +```output +1 ---------------------------------------------------- +2 ---------- Html Agility Pack Nuget Readme ---------- +3 ---------------------------------------------------- +4 +5 ----Silverlight 4 and Windows Phone 7.1+ projects----- +6 To use XPATH features: System.Xml.Xpath.dll from the 3 Silverlight 4 SDK must be referenced. +7 This is normally found at +8 %ProgramFiles(x86)%\Microsoft SDKs\Microsoft SDKs\Silverlight\v4.0\Libraries\Client +9 or +10 %ProgramFiles%\Microsoft SDKs\Microsoft SDKs\Silverlight\v4.0\Libraries\Client +11 +12 ----Silverlight 5 projects----- +13 To use XPATH features: System.Xml.Xpath.dll from the Silverlight 5 SDK must be referenced. +14 This is normally found at +15 %ProgramFiles(x86)%\Microsoft SDKs\Microsoft SDKs\Silverlight\v5.0\Libraries\Client +16 or +17 %ProgramFiles%\Microsoft SDKs\Microsoft SDKs\Silverlight\v5.0\Libraries\Client +``` + +> [!NOTE] +> If you only add *readme.txt* at the project root without including it in the `content` property of the project file, it won't be included in the package. + +## Related video + +Find NuGet videos on [Channel 9](/shows/NuGet-101/) and [YouTube](https://www.youtube.com/playlist?list=PLdo4fOcmZ0oVLvfkFk8O9h6v2Dcdh2bh_). -![The display of a readme file for a NuGet package upon installation](../create-packages/media/Create_01-ShowReadme.png) +Congratulations on creating a NuGet package by using a Visual Studio .NET class library. Advance to the next article to learn how to create a NuGet package with the Visual Studio .NET Framework. -> [!Note] -> Merely adding the readme.txt at the project root will not result in it being included in the resulting package. +> [!div class="nextstepaction"] +> [Create a package using the NuGet CLI](../create-packages/creating-a-package.md) -## Related topics +To explore more that NuGet has to offer, see the following articles: -- [Create a Package](../create-packages/creating-a-package.md) -- [Publish a Package](../nuget-org/publish-a-package.md) -- [Pre-release Packages](../create-packages/Prerelease-Packages.md) -- [Support multiple target frameworks](../create-packages/multiple-target-frameworks-project-file.md) -- [Package versioning](../reference/package-versioning.md) -- [Creating localized packages](../create-packages/creating-localized-packages.md) -- [.NET Standard Library documentation](/dotnet/articles/standard/library) +- [Create a NuGet package](../create-packages/creating-a-package-dotnet-cli.md) +- [Publish a package](../nuget-org/publish-a-package.md) +- [Build a prerelease package](../create-packages/Prerelease-Packages.md) +- [Support multiple .NET Framework versions](../create-packages/multiple-target-frameworks-project-file.md) +- [Package versioning](../concepts/package-versioning.md) +- [Create localized NuGet packages](../create-packages/creating-localized-packages.md) - [Porting to .NET Core from .NET Framework](/dotnet/articles/core/porting/index) diff --git a/docs/quickstart/includes/publish-api-key-with-link.md b/docs/quickstart/includes/publish-api-key-with-link.md new file mode 100644 index 000000000..b0162ee05 --- /dev/null +++ b/docs/quickstart/includes/publish-api-key-with-link.md @@ -0,0 +1,3 @@ +[!INCLUDE [publish-api-key](publish-api-key.md)] + +For more information, see [scoped API keys](../../nuget-org/scoped-api-keys.md). diff --git a/docs/quickstart/includes/publish-api-key.md b/docs/quickstart/includes/publish-api-key.md index d47a1a179..b2588b6be 100644 --- a/docs/quickstart/includes/publish-api-key.md +++ b/docs/quickstart/includes/publish-api-key.md @@ -1,15 +1,24 @@ -1. [Sign into your nuget.org account](https://www.nuget.org/users/account/LogOn?returnUrl=%2F) or create an account if you don't have one already. +1. [Sign into your nuget.org account](https://www.nuget.org/users/account/LogOn?returnUrl=%2F) or [create an account](../../nuget-org/individual-accounts.md#add-a-new-individual-account) if you don't have one already. - For more information on creating your account, see [Individual accounts](../../nuget-org/individual-accounts.md). +1. Select your user name at upper right, and then select **API Keys**. -1. Select your user name (on the upper right), then select **API Keys**. +1. Select **Create**, and provide a name for your key. -1. Select **Create**, provide a name for your key, select **Select Scopes > Push**. Enter * for **Glob pattern**, then select **Create**. (See below for more about scopes.) +1. Under **Select Scopes**, select **Push**. -1. Once the key is created, select **Copy** to retrieve the access key you need in the CLI: +1. Under **Select Packages** > **Glob Pattern**, enter \*. - ![Copying the API key to the clipboard](../media/QS_Create-02-APIKey.png) +1. Select **Create**. -1. **Important**: Save your key in a secure location because you cannot copy the key again later on. If you return to the API key page, you need to regenerate the key to copy it. You can also remove the API key if you no longer want to push packages via the CLI. +1. Select **Copy** to copy the new key. -Scoping allows you to create separate API keys for different purposes. Each key has its expiration timeframe and can be scoped to specific packages (or glob patterns). Each key is also scoped to specific operations: push of new packages and updates, push of updates only, or delisting. Through scoping, you can create API keys for different people who manage packages for your organization such that they have only the permissions they need. For more information, see [scoped API keys](../../nuget-org/scoped-api-keys.md). \ No newline at end of file + ![Screenshot that shows the new API key with the Copy link.](../media/qs-create-api-key.png) + +> [!IMPORTANT] +> +> - Always keep your API key a secret. The API key is like a password that allows anyone to manage packages on your behalf. Delete or regenerate your API key if it's accidentally revealed. +> - Save your key in a secure location, because you can't copy the key again later. If you return to the API key page, you need to regenerate the key to copy it. You can also remove the API key if you no longer want to push packages. + +*Scoping* lets you create separate API keys for different purposes. Each key has an expiration timeframe, and you can scope the key to specific packages or glob patterns. You also scope each key to specific operations: Push new packages and package versions, push only new package versions, or unlist. + +Through scoping, you can create API keys for different people who manage packages for your organization so they have only the permissions they need. \ No newline at end of file diff --git a/docs/quickstart/includes/publish-dotnet.md b/docs/quickstart/includes/publish-dotnet.md index 9223b9eff..eead5986d 100644 --- a/docs/quickstart/includes/publish-dotnet.md +++ b/docs/quickstart/includes/publish-dotnet.md @@ -1,18 +1,20 @@ -1. Change to the folder containing the `.nupkg` file. +From the folder that contains the *.nupkg* file, run the following command. Specify your *.nupkg* filename, and replace the key value with your API key. -1. Run the following command, specifying your package name (unique package ID) and replacing the key value with your API key: +```dotnetcli +dotnet nuget push Contoso.08.28.22.001.Test.1.0.0.nupkg --api-key qz2jga8pl3dvn2akksyquwcs9ygggg4exypy3bhxy6w6x6 --source https://api.nuget.org/v3/index.json +``` - ```cli - dotnet nuget push AppLogger.1.0.0.nupkg -k qz2jga8pl3dvn2akksyquwcs9ygggg4exypy3bhxy6w6x6 -s https://api.nuget.org/v3/index.json - ``` +The output shows the results of the publishing process: -1. dotnet displays the results of the publishing process: +```output +Pushing Contoso.08.28.22.001.Test.1.0.0.nupkg to 'https://www.nuget.org/api/v2/package'... + PUT https://www.nuget.org/api/v2/package/ +warn : All published packages should have license information specified. Learn more: https://aka.ms/nuget/authoring-best-practices#licensing. + Created https://www.nuget.org/api/v2/package/ 1221ms +Your package was pushed. +``` - ```output - info : Pushing AppLogger.1.0.0.nupkg to 'https://www.nuget.org/api/v2/package'... - info : PUT https://www.nuget.org/api/v2/package/ - info : Created https://www.nuget.org/api/v2/package/ 12620ms - info : Your package was pushed. - ``` +For more information, see [dotnet nuget push](/dotnet/core/tools/dotnet-nuget-push). -See [dotnet nuget push](/dotnet/core/tools/dotnet-nuget-push). \ No newline at end of file +> [!NOTE] +> If you want to avoid your test package being live on nuget.org, you can push to the nuget.org test site at [https://int.nugettest.org](https://int.nugettest.org). Note that packages uploaded to int.nugettest.org might not be preserved. \ No newline at end of file diff --git a/docs/quickstart/includes/publish-errors.md b/docs/quickstart/includes/publish-errors.md index cfdb184cc..a6afe8686 100644 --- a/docs/quickstart/includes/publish-errors.md +++ b/docs/quickstart/includes/publish-errors.md @@ -1,10 +1,10 @@ -Errors from the `push` command typically indicate the problem. For example, you may have forgotten to update the version number in your project and are therefore trying to publish a package that already exists. +Errors from the `push` command typically indicate the problem. For example, you might have forgotten to update the version number in your project, so you're trying to publish a package that already exists. -You also see errors when trying to publish a package using an identifier that already exists on the host. The name "AppLogger", for example, already exists. In such a case, the `push` command gives the following error: +You also see errors if your API key is invalid or expired, or if you try to publish a package using an identifier that already exists on the host. Suppose, for example, the identifier `AppLogger-test` already exists on nuget.org. If you try to publish a package with that identifier, the `push` command gives the following error: -```output -Response status code does not indicate success: 403 (The specified API key is invalid, -has expired, or does not have permission to access the specified package.). -``` + ```output + Response status code does not indicate success: 403 (The specified API key is invalid, + has expired, or does not have permission to access the specified package.). + ``` -If you're using a valid API key that you just created, then this message indicates a naming conflict, which isn't entirely clear from the "permission" part of the error. Change the package identifier, rebuild the project, recreate the `.nupkg` file, and retry the `push` command. \ No newline at end of file +If you get this error, check that you're using a valid API key that hasn't expired. If you are, the error indicates the package identifier already exists on the host. To fix the error, change the package identifier to be unique, rebuild the project, recreate the *.nupkg* file, and retry the `push` command. diff --git a/docs/quickstart/includes/publish-manage.md b/docs/quickstart/includes/publish-manage.md index cde7211e3..bf1b8c8e6 100644 --- a/docs/quickstart/includes/publish-manage.md +++ b/docs/quickstart/includes/publish-manage.md @@ -1,17 +1,23 @@ -From your profile on nuget.org, select **Manage Packages** to see the one you just published. You also receive a confirmation email. Note that it might take a while for your package to be indexed and appear in search results where others can find it. During that time your package page shows the message below: +When your package successfully publishes, you receive a confirmation email. To see the package you just published, on [nuget.org](https://www.nuget.org/), select your user name at upper right, and then select **Manage Packages**. -![This package has not been indexed yet. It will appear in search results and will be available for install/restore after indexing is complete.](../media/QS_Create-03-NotIndexed.png) +> [!NOTE] +> It might take awhile for your package to be indexed and appear in search results where others can find it. During that time, your package appears under **Unlisted Packages**, and the package page shows the following message: +> +> ![Screenshot showing the publishing message that's displayed when you upload a package to nuget.org.](../media/qs-create-not-indexed.png) -And that's it! You've just published your first NuGet package to nuget.org that other developers can use in their own projects. +You've now published a NuGet package to nuget.org that other developers can use in their projects. -If in this walkthrough you created a package that isn't actually useful (such as a package created with an empty class library), you should *unlist* the package to hide it from search results: +If you've created a package that isn't useful (such as this sample package that was created with an empty class library), or you decide you don't want the package to be visible, you can *unlist* the package to hide it from search results: -1. On nuget.org, select your user name (upper right of the page), then select **Manage Packages**. +1. After the package appears under **Published Packages** on the **Manage Packages** page, select the pencil icon next to the package listing. -1. Locate the package you want to unlist under **Published** and select the trash can icon on the right: + ![Screenshot that shows the Edit icon for a package listing on nuget.org.](../media/qs-create-vs-edit-package.png) - ![Trash can icon shown for a package listing on nuget.org](../media/qs_create-vs-03-trash-can.png) +1. On the next page, select **Listing**, deselect the **List in search results** checkbox, and then select **Save**. -1. On the subsequent page, clear the box labeled **List (package-name) in search results** and select **Save**: + ![Screenshot that shows clearing the List checkbox for a package on nuget.org.](../media/qs-create-vs-unlist-package.png) - ![Clearing the List checkbox for a package on nuget.org](../media/qs_create-vs-04-unlist.png) \ No newline at end of file +The package now appears under **Unlisted Packages** in **Manage Packages** and no longer appears in search results. + +> [!NOTE] +> To avoid your test package being live on nuget.org, you can push to the nuget.org test site at [https://int.nugettest.org](https://int.nugettest.org). Note that packages uploaded to int.nugettest.org might not be preserved. diff --git a/docs/quickstart/includes/publish-notes.md b/docs/quickstart/includes/publish-notes.md index 383e4df4b..78007281b 100644 --- a/docs/quickstart/includes/publish-notes.md +++ b/docs/quickstart/includes/publish-notes.md @@ -1,4 +1,5 @@ -> [!Note] -> **Virus scanning**: All packages uploaded to nuget.org are scanned for viruses and rejected if any viruses are found. All packages listed on nuget.org are also scanned periodically. +> [!NOTE] > -> Packages published to nuget.org are also publicly visible to other developers unless you unlist them. To host packages privately, see [Hosting packages](../../hosting-packages/overview.md). \ No newline at end of file +> - Nuget.org scans all uploaded packages for viruses and rejects the packages if it finds any viruses. Nuget.org also scans all existing listed packages periodically. +> +> - Packages you publish to nuget.org are publicly visible to other developers unless you unlist them. To host packages privately, see [Host your own NuGet feeds](../../hosting-packages/overview.md). diff --git a/docs/quickstart/install-and-use-a-package-in-visual-studio-mac.md b/docs/quickstart/install-and-use-a-package-in-visual-studio-mac.md new file mode 100644 index 000000000..4dd4766b6 --- /dev/null +++ b/docs/quickstart/install-and-use-a-package-in-visual-studio-mac.md @@ -0,0 +1,102 @@ +--- +title: Install and use a NuGet package in Visual Studio for Mac +description: A walkthrough tutorial on the process of installing and using a NuGet package in a Visual Studio for Mac project. +author: jmatthiesen +ms.author: jomatthi +ms.date: 08/14/2019 +ms.topic: quickstart +--- + +# Quickstart: Install and use a package in Visual Studio for Mac + +NuGet packages contain reusable code that other developers make available to you for use in your projects. See [What is NuGet?](../What-is-NuGet.md) for background. Packages are installed into a Visual Studio for Mac project using the NuGet Package Manager. This article demonstrates the process using the popular [Newtonsoft.Json](https://www.nuget.org/packages/Newtonsoft.Json/) package and a .NET Core console project. The same process applies to any other .NET Core project. + +Once installed, refer to the package in code with `using ` where \ is specific to the package you're using. Once the reference is made, you can call the package through its API. + +> [!Tip] +> **Start with nuget.org**: Browsing *nuget.org* is how .NET developers typically find components they can reuse in their own applications. You can search *nuget.org* directly or find and install packages within Visual Studio as shown in this article. For general information, see [Find and evaluate NuGet packages](../consume-packages/finding-and-choosing-packages.md). + +## Prerequisites + +- Visual Studio 2019 for Mac. + +You can install the 2019 Community edition for free from [visualstudio.com](https://www.visualstudio.com/) or use the Professional or Enterprise editions. + +If you're using Visual Studio on Windows, see [Install and use a package in Visual Studio (Windows Only)](install-and-use-a-package-in-visual-studio.md). + +## Create a project + +NuGet packages can be installed into any .NET project, provided that the package supports the same target framework as the project. + +For this walkthrough, use a simple .NET Core Console app. Create a project in Visual Studio for Mac using **File > New Solution...**, select the **.NET Core > App > Console Application** template. Click **Next**. Accept the default values for **Target Framework** when prompted. + +Visual Studio creates the project, which opens in Solution Explorer. + +## Add the Newtonsoft.Json NuGet package + +To install the package, you use the NuGet Package Manager. When you install a package, NuGet records the dependency in either your project file or a `packages.config` file (depending on the project format). For more information, see [Package consumption overview and workflow](../consume-packages/Overview-and-Workflow.md). + +### NuGet Package Manager + +1. In Solution Explorer, right-click **Dependencies** and choose **Add Packages...**. + + ![Manage NuGet Packages command for project References](media/QS_Use_Mac-02-ManageNuGetPackages.png) + +1. Choose "nuget.org" as the **Package source** in the top left corner of the dialog, and search for **Newtonsoft.Json**, select that package in the list, and select **Add Packages...**: + + ![Locating Newtonsoft.Json package](media/QS_Use_Mac-03-NewtonsoftJson.png) + + If you want more information on the NuGet Package Manager, see [Install and manage packages using Visual Studio for Mac](../consume-packages/install-use-packages-visual-studio.md). + +## Use the Newtonsoft.Json API in the app + +With the Newtonsoft.Json package in the project, you can call its `JsonConvert.SerializeObject` method to convert an object to a human-readable string. + +1. Open the `Program.cs` file (located in the Solution Pad) and replace the file contents with the following code: + + ```cs + using System; + using Newtonsoft.Json; + + namespace NuGetDemo + { + public class Account + { + public string Name { get; set; } + public string Email { get; set; } + public DateTime DOB { get; set; } + } + + class Program + { + static void Main(string[] args) + { + Account account = new Account() + { + Name = "Joe Doe", + Email = "joe@test.com", + DOB = new DateTime(1976, 3, 24) + }; + string json = JsonConvert.SerializeObject(account); + Console.WriteLine(json); + } + } + } + ``` + +1. Build and run the app by selecting **Run > Start Debugging**: + +1. Once the app runs, you'll see the serialized JSON output appear in the console: + + ![Output of the Console app](media/QS_Use_Mac-06-AppStart.png) + +## Next steps +Congratulations on installing and using your first NuGet package! + +> [!div class="nextstepaction"] +> [Install and manage packages using Visual Studio for Mac](/visualstudio/mac/nuget-walkthrough?toc=/nuget/toc.json) + +To explore more that NuGet has to offer, select the links below. + +- [Overview and workflow of package consumption](../consume-packages/overview-and-workflow.md) +- [Package references in project files](../consume-packages/package-references-in-project-files.md) diff --git a/docs/quickstart/install-and-use-a-package-in-visual-studio.md b/docs/quickstart/install-and-use-a-package-in-visual-studio.md index 74b9eb836..5a73bf2cc 100644 --- a/docs/quickstart/install-and-use-a-package-in-visual-studio.md +++ b/docs/quickstart/install-and-use-a-package-in-visual-studio.md @@ -1,86 +1,95 @@ --- -title: Install and use a NuGet package in Visual Studio -description: A walkthrough tutorial on the process of installing and using a NuGet package in a Visual Studio project. -author: karann-msft -ms.author: karann -ms.date: 01/23/2018 +title: "Quickstart: Install and use a NuGet package in Visual Studio (Windows only)" +description: In this quickstart, you learn how to install and use a NuGet package in a Visual Studio project for Windows. +author: JonDouglas +ms.author: jodou +ms.date: 03/03/2025 ms.topic: quickstart --- -# Quickstart: Install and use a package in Visual Studio +# Quickstart: Install and use a NuGet package in Visual Studio (Windows only) -NuGet packages contain reusable code that other developers make available to you for use in your projects. See [What is NuGet?](../What-is-NuGet.md) for background. Packages are installed into a Visual Studio project using the Package Manager UI or the Package Manager Console. This article demonstrates the process using the popular [Newtonsoft.Json](https://www.nuget.org/packages/Newtonsoft.Json/) package and a Universal Windows Platform (UWP) project. The same process applies to any other .NET or .NET Core project. +A *NuGet package* contains reusable code that other developers have made available to you for use in your projects. You can install a NuGet package in a Microsoft Visual Studio project by using the [NuGet Package Manager](../consume-packages/install-use-packages-visual-studio.md), the [Package Manager Console](../consume-packages/install-use-packages-powershell.md), or the [.NET CLI](install-and-use-a-package-using-the-dotnet-cli.md). This article demonstrates how to create a Windows Presentation Foundation (WPF) project with the popular `Newtonsoft.Json` package. The same process applies to any other .NET or .NET Core project. -Once installed, refer to the package in code with `using ` where \ is specific to the package you're using. Once the reference is made, you can call the package through its API. +After you install a NuGet package, you can then make a reference to it in your code with the `using ` statement, where \ is the name of package you're using. After you've made a reference, you can then call the package through its API. -> [!Tip] -> **Start with nuget.org**: Browsing nuget.org is how .NET developers typically find components they can reuse in their own applications. You can search nuget.org directly or find and install packages within Visual Studio as shown in this article. +The article is for Windows users only. If you're using Visual Studio for Mac, see [Install and use a package in Visual Studio for Mac](install-and-use-a-package-in-visual-studio-mac.md). -## Prerequisites +> [!TIP] +> To find a NuGet package, start with *nuget.org*. Browsing nuget.org is how .NET developers typically find components they can reuse in their own applications. You can do a search of nuget.org directly or find and install packages within Visual Studio as shown in this article. For more information, see [Find and evaluate NuGet packages](../consume-packages/finding-and-choosing-packages.md). -- Visual Studio 2017 with the Universal Windows Platform development workload, or -- Visual Studio 2015 Update 3 with Tools for Universal Windows Apps. +## Prerequisites -You can install the 2017 Community edition for free from [visualstudio.com](https://www.visualstudio.com/) or use the Professional or Enterprise editions. +- Install Visual Studio 2022 for Windows with the .NET desktop development workload. -If you're using Visual Studio for Mac, see [Include a NuGet package in your project](/visualstudio/mac/nuget-walkthrough). + You can install the 2022 Community edition for free from [visualstudio.microsoft.com](https://visualstudio.microsoft.com/), or use the Professional or Enterprise edition. ## Create a project -NuGet packages can be installed into any .NET project, provided that the package supports the same target framework as the project. +You can install a NuGet package into any .NET project if that package supports the same target framework as the project. However, for this quickstart you'll create a Windows Presentation Foundation (WPF) Application project. -For this walkthrough, use a simple Universal Windows (UWP) app. Create a project in Visual Studio using **File > New Project...** and selecting the **Windows Universal > Blank App (Universal Windows)**. Accept the default values for Target Version and Minimum Version when prompted. +Follow these steps: -## Add the Newtonsoft.Json NuGet package +1. In Visual Studio, select **File** > **New** > **Project**. + +1. In the **Create a new project** window, enter *WPF* in the search box and select **C#** and **Windows** in the dropdown lists. In the resulting list of project templates, select **WPF Application**, and then select **Next**. + +1. In the **Configure your new project** window, optionally update the **Project name** and the **Solution name**, and then select **Next**. -To install the package, you can use either the Package Manager UI or the Package Manager Console. When you install a package, NuGet records the dependency in either your project file or a `packages.config` file. For more information, see [Package consumption overview and workflow](../consume-packages/Overview-and-Workflow.md). +1. In the **Additional information** window, select **.NET 6.0** (or the latest version) for **Framework**, and then select **Create**. -### Package Manager UI + Visual Studio creates the project, and it appears in [Solution Explorer](/visualstudio/ide/use-solution-explorer). -1. In Solution Explorer, right-click **References** and choose **Manage NuGet Packages**. +## Add the Newtonsoft.Json NuGet package + +To install a NuGet package in this quickstart, you can use either the NuGet Package Manager or the Package Manager Console. Depending on your project format, the installation of a NuGet package records the dependency in either your project file or a *packages.config* file. For more information, see [Package consumption workflow](../consume-packages/overview-and-workflow.md). - ![Manage NuGet Packages command for project References](media/QS_Use-02-ManageNuGetPackages.png) +### NuGet Package Manager -1. Choose "nuget.org" as the **Package source**, select the **Browse** tab, search for **Newtonsoft.Json**, select that package in the list, and select **Install**: +To use the [NuGet Package Manager](../consume-packages/install-use-packages-visual-studio.md) to install the `Newtonsoft.Json` package in Visual Studio, follow these steps: - ![Locating Newtonsoft.Json package](media/QS_Use-03-NewtonsoftJson.png) +1. Select **Project** > **Manage NuGet Packages**. -1. Accept any license prompts. +1. In the **NuGet Package Manager** page, choose **nuget.org** as the **Package source**. -1. (Visual Studio 2017) If prompted to select a package management format, select **PackageReference in project file**: +1. From the **Browse** tab, search for *Newtonsoft.Json*, select **Newtonsoft.Json** in the list, and then select **Install**. - ![Selecting a package management format](media/QS_Use-03b-SelectFormat.png) + :::image type="content" source="media/qs-use-install-package.png" alt-text="Screenshot showing the NuGet Package Manager window with the Newtonsoft.Json package selected."::: -1. If prompted to review changes, select **OK**. +1. If you're prompted to verify the installation, select **OK**. ### Package Manager Console -1. Select the **Tools > NuGet Package Manager > Package Manager Console** menu command. +Alternatively, to use the [Package Manager Console](../consume-packages/install-use-packages-powershell.md) in Visual Studio to install the `Newtonsoft.Json` package, follow these steps: + +1. From Visual Studio, select **Tools** > **NuGet Package Manager** > **Package Manager Console**. -1. Once the console opens, check that the **Default project** drop-down list shows the project into which you want to install the package. If you have a single project in the solution, it is already selected. +1. After the **Package Manager Console** pane opens, verify that the **Default project** drop-down list shows the project in which you want to install the package. If you have a single project in the solution, it's preselected. - ![Locating Newtonsoft.Json package](media/QS_Use-08-Console1.png) + :::image type="content" source="media/qs-use-package-manager-console.png" alt-text="Screenshot showing the Package Manage Console window with Default project highlighted."::: -1. Enter the command `Install-Package Newtonsoft.Json` (see [Install-Package](../reference/ps-reference/ps-ref-install-package.md)). The console window shows output for the command. Errors typically indicate that the package isn't compatible with the project's target framework. +1. At the console prompt, enter the command `Install-Package Newtonsoft.Json`. For more information about this command, see [Install-Package](../reference/ps-reference/ps-ref-install-package.md). + + The console window shows the output for the command. Errors typically indicate that the package isn't compatible with the project's target framework. ## Use the Newtonsoft.Json API in the app -With the Newtonsoft.Json package in the project, you can call its `JsonConvert.SerializeObject` method to convert an object to a human-readable string. +With the `Newtonsoft.Json` package in the project, call its `JsonConvert.SerializeObject` method to convert an object to a human-readable string: -1. Open `MainPage.xaml` and replace the existing `Grid` element with the following: +1. From **Solution Explorer**, open *MainWindow.xaml* and replace the existing `` element with the following code: ```xaml - + -