You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Keeping the NuGet ecosystem safe is something we take seriously, and today we're sharing a change that's been carefully considered with that responsibility in mind: a small tightening of the rules for what characters are allowed in package IDs, to close the potential for problems in the NuGet ecosystem.
nuget.org now requires new package IDs to use only ASCII letters, digits, dots, and dashes, similar to the conventions used by npm, PyPI, and other major registries. Existing packages and existing IDs remain available.
We know any change to naming rules ripples out to authors who've already shipped their work, so we've designed this rollout to be gradual, to honor what existing publishers have invested, and to give everyone affected real, hands-on help getting through it. Here's the thought process behind this change and how you may be affected.
Why this matters
Under the covers, NuGet derives certain strings such as URLs and file system paths from a normalized version of your package ID.
Unfortunately, when package IDs are normalized, NuGet relies on built-in string libraries which are by design inconsistent across .NET Framework, modern .NET, Windows, and Linux.
This can lead to a situation where two visibly different IDs can resolve to the same string.
Since your package ID is part of your brand, this needs to be remedied.
npm, PyPI, and other registries have all tightened their rules for similar reasons. We're doing the same for NuGet.
What's changing
We're rolling this out in three phases:
Starting now (June 15th, 2026) new NuGet packages on nuget.org are required to adhere to the following package ID rules:
Must start with a letter, number, or underscore
Can only contain letters, numbers, dots (.), or dashes (-)
Cannot contain consecutive . (dot) or - (dash) characters
Must be 100 characters or less
[!NOTE]
For readability and clarity, we recommend starting your package name with a letter.
You will still be able to push new versions of existing packages, even if they do not follow the new package ID rules.
Starting on July 15th, 2026, you will no longer be able to push any package to nuget.org unless it follows the new package ID rules.
Starting on TBD, when using .NET 11, NuGet will emit a warning if you attempt to create a package that does not adhere to the new package ID rules.
What this means for you
Important
If your package IDs already adhere to the new package ID rules you do not need to do anything.
If one or more of your package IDs do not adhere to the new package ID rules, nothing breaks today. Restores keep working, your consumers keep building, and you can keep publishing through July 15th, 2026.
However, we highly encourage you to proactively rename your package(s).
Migrating your package
Take this at your own pace:
Find affected IDs on your nuget.org listings. To check programmatically, an ID is valid if it matches the regular expression ^[A-Za-z0-9_](?!.*[.-]{2})[A-Za-z0-9.-]{0,99}$.
Pick a new name close to the original. Transliterate to ASCII: for example, Müller.Logging becomes Mueller.Logging.
Register and publish under the new ID. A prerelease first lets consumers validate the move.
Deprecate the old ID with package deprecation and set the new package as the alternate. Visual Studio and the NuGet CLI will show that pointer directly to anyone using the old package.
Tell your users in your README and release notes.
Ask us to transfer your history. Email support@nuget.org referencing both IDs and we'll move download history and other metadata over so you don't start from zero.
What we're committing to
This change touches roughly 119 package IDs across 65 owners, around 0.02% of the nuget.org catalog. Small in aggregate, but very real if you're one of those owners. So:
A phased rollout with an allow list so existing IDs keep publishing through Phase 1
Clear errors that say exactly what to fix
Hands-on migration help, by notifying impacted maintainers and offering download credit and history transfer
An open feedback channel at NuGet/Home. If affected publishers need more time, we'll adjust.
We know this affects publishers who use package IDs with characters outside of the new allowed set and our community is global.
International publishers are core to the .NET ecosystem, so we did not take this decision lightly.
However, the security of the NuGet ecosystem is paramount for us all to have confidence in the ecosystem.
Keeping the NuGet ecosystem safe is something we take seriously, and today we're sharing a change that's been carefully considered with that responsibility in mind: a small tightening of the rules for what characters are allowed in package IDs, to close the potential for problems in the NuGet ecosystem.
nuget.org now requires new package IDs to use only ASCII letters, digits, dots, and dashes, similar to the conventions used by npm, PyPI, and other major registries. Existing packages and existing IDs remain available.
We know any change to naming rules ripples out to authors who've already shipped their work, so we've designed this rollout to be gradual, to honor what existing publishers have invested, and to give everyone affected real, hands-on help getting through it. Here's the thought process behind this change and how you may be affected.
Why this matters
Under the covers, NuGet derives certain strings such as URLs and file system paths from a normalized version of your package ID.
Unfortunately, when package IDs are normalized, NuGet relies on built-in string libraries which are by design inconsistent across .NET Framework, modern .NET, Windows, and Linux.
This can lead to a situation where two visibly different IDs can resolve to the same string.
Since your package ID is part of your brand, this needs to be remedied.
npm, PyPI, and other registries have all tightened their rules for similar reasons. We're doing the same for NuGet.
What's changing
We're rolling this out in three phases:
Starting now (June 15th, 2026) new NuGet packages on nuget.org are required to adhere to the following package ID rules:
.), or dashes (-).(dot) or-(dash) charactersYou will still be able to push new versions of existing packages, even if they do not follow the new package ID rules.
Starting on July 15th, 2026, you will no longer be able to push any package to nuget.org unless it follows the new package ID rules.
Starting on TBD, when using .NET 11, NuGet will emit a warning if you attempt to create a package that does not adhere to the new package ID rules.
What this means for you
Important
If your package IDs already adhere to the new package ID rules you do not need to do anything.
If one or more of your package IDs do not adhere to the new package ID rules, nothing breaks today. Restores keep working, your consumers keep building, and you can keep publishing through July 15th, 2026.
However, we highly encourage you to proactively rename your package(s).
Migrating your package
Take this at your own pace:
^[A-Za-z0-9_](?!.*[.-]{2})[A-Za-z0-9.-]{0,99}$.Müller.LoggingbecomesMueller.Logging.What we're committing to
This change touches roughly 119 package IDs across 65 owners, around 0.02% of the nuget.org catalog. Small in aggregate, but very real if you're one of those owners. So:
We know this affects publishers who use package IDs with characters outside of the new allowed set and our community is global.
International publishers are core to the .NET ecosystem, so we did not take this decision lightly.
However, the security of the NuGet ecosystem is paramount for us all to have confidence in the ecosystem.
Thanks for being part of the NuGet community.