We are excited to announce that nuget.org now supports package deprecation. This has been a long standing ask that will help the ecosystem use supported packages. As a package publisher on nuget.org, you can now deprecate packages that are obsolete, legacy,
It’s been a long time coming, and today we are excited to announce the new and improved search on NuGet.org leveraging Azure Search. We want to start this post with a huge thanks to you, the NuGet community, for providing feedback.
There are several criteria you can use today to evaluate NuGet packages. We received feedback that you would like even more information to help choose the right packages. We’re excited to introduce GitHub Usage on nuget.org, which allows you to explore top GitHub repositories that depend on the package you are looking at.
With PackageReference, NuGet always tries to produce the same closure of package dependencies if the input package reference list has not changed. However, there are a few scenarios where it may not be able to do so. While these cases are limited,
Starting today, you can publish symbol packages to the NuGet.org symbol server. With NuGet.org as a single service provider for libraries and symbols, package authors and consumers will have a streamlined publishing and consumption experience. With a single place for managing authentication and identity,
NuGet.org now supports surfacing source code repository link for NuGet packages. This will enable package authors to surface both the project’s website and the source repository using the projectUrl and the repository properties respectively instead of having to choose between the two using just the projectUrl property.
In September 2017, we announced our plans to improve the security of the NuGet ecosystem by introducing the ability for package authors to sign packages. Today, we want to announce support for any NuGet.org user to submit signed packages to NuGet.org.
We are happy to announce support for Organizations on NuGet.org. This will help businesses and open-source projects collaborate on packages using a single nuget.org identity.
NuGet.org used to allow you to create an account and publish packages through that account with little support to manage and publish packages as a team or a group.
Last year, we introduced the option to make PackageReference the default package management format for managing NuGet dependencies when installing the first NuGet package for a newly created projects. With Visual Studio Version 15.7 Preview 3, we have introduced the capability to migrate existing projects that use the packages.config format to use PackageReference instead.
Update on 10/16/2017: Package ID Prefix Reservation is now live. The documentation can be found here.
We want to start this post with a huge thanks to you, the NuGet community. Over the last several months we have been talking to many of you to get feedback on NuGet package identity and trust.