NuGet.org frequently-asked questions

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.

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 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

In general, we do not support deleting a package published to NuGet.org. Read more about our policy on deleting packages.

Yes. You can reserve IDs for packages on 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.

See Managing package owners on NuGet.org.

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 to follow before asking NuGet.org administrators to intercede.

For test purposes, you can use int.nugettest.org, or alternative public NuGet servers like myget.org or Azure DevOps.

Note that packages uploaded to int.nugettest.org may not be preserved.

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 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

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.

If that version of NuGet client continues to fail, contact support and provide additional connection troubleshooting information including:

• 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)
• 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.

• Enter api.nuget.org as the hostname and click Start.

• Wait until the Sent column is >= 100.

  

• Copy text to clipboard.

To capture Fiddler:

• Install the latest version of 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.

Please note that the NuGet.org Password login has been discontinued. 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.

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.

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 and click on Need assistance signing in? link.
2. 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.

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 after clicking Sign in with Microsoft.

2. Once logged in, go to your account settings page.

3. Expand the section for Login Account. Click on the Change Account button.

4. 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.

5. If you see an error like below, see Microsoft account is linked with another NuGet.org account for more details.

   Failed to update the Microsoft account with 'account2 account2@outlook.com'. This could happen if it is already linked to another NuGet account. Contact support for more information.

6. 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.

If you tried changing your Microsoft login and saw the error below:

Failed to update the Microsoft account with 'account2 account2@outlook.com'. 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 <account2@outlook.com> 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.

Login with the second Microsoft account on the 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.

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 for the second NuGet.org account MyNuGetAccount2.
2. Once this account is deleted, you can retry the steps to change Microsoft account login.

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.
2. 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.

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.

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.

You should use the sign in assistance flow to figure out which Microsoft account is linked to the NuGet.org account with the email address account1@outlook.com.

If you tried using the sign in assistance 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
• Work or school account (AAD): Work or school account help or contact your admin tenant.

If you want to transform your account to an organization, please follow the steps given in the documentation for organizations on nuget.org.

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.

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, which creates such an "Unmanaged" tenant for the used Microsoft account domain(@yourdomain.com in your case).

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 documented by the Azure Active directory. Once this is done, your normal login should start working.

You can request a username change by sending an email to 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.

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 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.

Follow the following steps to proceed with account deletion.

1. Login to NuGet.org with the account you wish to delete.
2. Click on this url: 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.

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.