Freshness Edit: NuGet (#3554)

* Refresh article and screenshots

* Refresh article and screenshots

* Refresh article, remove note from include, add note to other article

* Adjust language

* Address error: remove duplicate lightbox

* Adjust language

* Address Copilot comments: adjust capitalization and formatting

* Address Copilot comment: adjust error example

* Address review comment: remove Visual Studio steps for adding read-me file

* Address review comments: remove DLL check, streamline code, follow readme convention, correct link

Author: JKirsch1

docs/nuget-org/Publish-a-package.md

@@ -22,6 +22,9 @@ To publish on nuget.org, sign in to nuget.org with a Microsoft account, and use
 
 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.
 
+> [!NOTE]
+> If you want to publish your package on a test site before publishing it on nuget.org, you can use [https://int.nugettest.org](https://int.nugettest.org). Note that packages uploaded to int.nugettest.org might not be preserved.
+
 ### Upload to the nuget.org web portal
 
 To upload a package to the nuget.org website:

docs/quickstart/create-and-publish-a-package-using-visual-studio.md

@@ -1,3 +1,3 @@
 [!INCLUDE [publish-api-key](publish-api-key.md)]
 
-For more information, see [scoped API keys](../../nuget-org/scoped-api-keys.md).
+For more information, see [Scoped API keys](../../nuget-org/scoped-api-keys.md).

docs/quickstart/includes/publish-api-key-with-link.md

@@ -1,24 +1,24 @@
-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.
+1. [Sign in to 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.
 
-1. Select your user name at upper right, and then select **API Keys**.
+1. In the upper-right corner, select your user name, and then select **API Keys**.
 
-1. Select **Create**, and provide a name for your key.
+1. Select **Create**, and then enter a name for your key.
 
 1. Under **Select Scopes**, select **Push**.
 
-1. Under **Select Packages** > **Glob Pattern**, enter \*.
+1. Under **Select Packages**, for **Glob Pattern**, enter an asterisk (**\***).
 
 1. Select **Create**.
 
 1. Select **Copy** to copy the new key.
 
-   ![Screenshot that shows the new API key with the Copy link.](../media/qs-create-api-key.png)
+   :::image type="content" source="../media/qs-create-api-key.png" alt-text="Screenshot of a nuget.org page that shows the new API key, a message about copying the key now, and the Copy button, which is highlighted.":::
 
 > [!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.
+> - Always keep your API key a secret. The API key is like a password that anyone can use 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.
+*Scoping* provides a way to create separate API keys for different purposes. Each key has an expiration time frame, 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.

docs/quickstart/includes/publish-api-key.md

@@ -1,20 +1,16 @@
-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.
+From the folder that contains the *.nupkg* file, run the following command. Replace `<package-file>` with the name of your *.nupkg* file, and replace `<API-key>` 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
+dotnet nuget push <package-file> --api-key <API-key> --source https://api.nuget.org/v3/index.json
 ```
 
 The output shows 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'...
+Pushing <package-file> 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
+  Created https://www.nuget.org/api/v2/package/ 2891ms
 Your package was pushed.
 ```
 
 For more information, see [dotnet nuget push](/dotnet/core/tools/dotnet-nuget-push).
-
-> [!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.

docs/quickstart/includes/publish-dotnet.md

@@ -1,10 +1,15 @@
-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.
+When you run the `push` command, you sometimes encounter an error. For instance, you might get an error in the following situations:
 
-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:
+- Your API key is invalid or expired.
+- You try to publish a package that has an identifier that already exists on the host.
+- You make changes to a published package, but you forget to update the version number before you try to publish it again.
 
-   ```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.).
-   ```
+The error message typically indicates the source of the problem.
 
-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.
+For example, suppose the identifier `Contoso.App.Logger.Test` exists on nuget.org. If you try to publish a package with that identifier, you get 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.).
+```
+
+To address this situation, check the scope, expiration date, and value of your API key. If the key is valid, the error indicates that the package identifier already exists on the host. To overcome the problem, change the package identifier to be unique, rebuild the project, re-create the *.nupkg* file, and retry the `push` command.

docs/quickstart/includes/publish-errors.md

@@ -1,21 +1,21 @@
-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**.
+When your package is successfully published, you receive a confirmation email. To see the published package, go to [nuget.org](https://www.nuget.org/), select your user name in the upper-right corner, and then select **Manage Packages**.
 
 > [!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:
+> It might take a while for your package to be indexed and to 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)
+> :::image type="content" source="../media/qs-create-not-indexed.png" alt-text="Screenshot of a nuget.org warning message about the package not being published yet. The text states that validation and indexing can take an hour.":::
 
-You've now published a NuGet package to nuget.org that other developers can use in their projects.
+Now that your NuGet package is published at nuget.org, other developers can use it in their projects.
 
-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:
+If you create a package that isn't useful (such as this sample package from an empty class library), or if you don't want the package to be visible, you can *unlist* the package to hide it from search results:
 
 1. After the package appears under **Published Packages** on the **Manage Packages** page, select the pencil icon next to the package listing.
 
-   ![Screenshot that shows the Edit icon for a package listing on nuget.org.](../media/qs-create-vs-edit-package.png)
+   :::image type="content" source="../media/qs-create-vs-edit-package.png" alt-text="Screenshot of the nuget.org Packages page. The Published Packages section lists one package. Its edit icon is highlighted.":::
 
-1. On the next page, select **Listing**, deselect the **List in search results** checkbox, and then select **Save**.
+1. On the next page, select **Listing**, clear the **List in search results** checkbox, and then select **Save**.
 
-   ![Screenshot that shows clearing the List checkbox for a package on nuget.org.](../media/qs-create-vs-unlist-package.png)
+   :::image type="content" source="../media/qs-create-vs-unlist-package.png" alt-text="Screenshot of a nuget.org page. In the Listing section, the option for listing the package in search results is highlighted.":::
 
 The package now appears under **Unlisted Packages** in **Manage Packages** and no longer appears in search results.
 

docs/quickstart/includes/publish-manage.md

@@ -1,5 +1,5 @@
 > [!NOTE]
 >
-> - 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.
+> - Nuget.org scans all uploaded packages for viruses and rejects any packages that contain 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).
+> - Packages you publish to nuget.org are publicly visible to other developers unless you unlist them. To host packages privately, see [Hosting your own NuGet feeds](../../hosting-packages/Overview.md).