NuGet Spring 2018 Roadmap

Anand

March 1st, 2018

In August 2017, we published the NuGet Fall 2017 Roadmap where we outlined our backlog for the upcoming quarter. Since then, we’ve published specifications for these experiences on GitHub for the community to review. You have provided a ton of great feedback that has helped us ensure we deliver the right experiences. Thank you for your continued involvement and feedback!

In this post, I would like to briefly summarize our progress on our Fall 2017 roadmap and discuss what we plan to build over the next quarter leading up to early Summer (May 2018).

Looking back

Here is a quick summary of the various experiences that we have enabled or are enabling soon.

Package ID Prefix Reservation

Status: Implemented

This feature aims to reduce confusion with NuGet package identity (author, owner, ID). NuGet package owners can apply to reserve a package ID prefix glob pattern so that only they can submit to that pattern. In addition, a visual indicator on NuGet.org and in the Visual Studio Package Manager UI will show when a prefix is reserved so that consumers of the package know that they are getting the package from the author(s) listed. This feature is open to any NuGet package contributor who believes they meet the criteria for prefix reservations. Since the feature went online, we have received and approved requests from more than 250 NuGet.org authors with more than 7000 packages now having the checkmark.

Package Signing

Status: In progress

We are enabling package signing across multiple waves. As the first step, we wanted to enable authors to sign their packages and be able to consume it from the CLI. Hence, two new nuget.exe commands – sign and verify – are now available with nuget.exe v4.6.0-preview3. Visual Studio 2017 (version 15.6.0 Preview 3.0 and above) now has the capability to verify the signatures of a signed packages. Note that NuGet.org does not support accepting signed packages yet. You can try the signing functionality with your internal/local NuGet feeds until we allow signed packages on NuGet.org.

The next step is to enable NuGet.org to accept signed packages and in addition, counter-sign all packages with the NuGet.org repo signature. Together this will help ensure package integrity from the time package was authored to the time it was consumed. We plan to roll out the E2E signing feature by May 2018. Upcoming updates to Visual Studio will also have the ability to configure environments to enforce various levels of package signing. Over time, we will add package integrity checks to cross-platform CLIs like dotnet.exe and msbuild.exe.

Two-factor authentication

Status: In progress

We are transitioning away from NuGet.org’s home-grown authentication mechanism which will eventually allow us to add support for two-factor authentication (2-FA).

Organizations

Status: In progress

Organizations allow multiple individuals to manage the same set of packages. Support for Organizations will be available on NuGet.org by early April.

Roadmap for the next quarter

In addition to the experiences listed above, we will work on the following new experiences.

Cross-platform credential provider support

Feature specification | Github discussion issue

If you use an authenticated package feed like VS Team Services Package Management with Visual Studio or NuGet CLI (including dotnet.exe and msbuild.exe), there is no easy way to restore packages on Linux or Mac. The only solution available today is to specify Personal Access Tokens or the API keys in plain text in your nuget.config file, which is obviously not a good security practice. We would like to address this by having integrated support for credential providers similar to the Windows experience.

Enable repeatable builds for PackageReference based projects

Feature specification | Github discussion issue

Projects that use PackageReference to manage NuGet dependencies only specify direct package dependencies. The transitive closure for the dependencies happen during restore resulting in potenitally different build outputs for consecutive builds. We plan to address this issue by enabling locking of package dependency graph for projects.

Improved debugging and symbols support for packages

Feature specification | Github discussion issue

With a fast growing .NET ecosystem, we’ve observed a need to streamline the NuGet package debugging experience. Developers should be able to get meaningful debug information when consuming NuGet packages, and for open-source projects, they should even be able to step into the code without the need to clone the repository. In collaboration with the .NET team, we are working to provide an integrated experience for all NuGet package consumers when they want to debug into packages. Some shortcomings of the experience as it exists today are:

Discoverability issues in the tooling – it’s difficult to determine whether a package can be debugged

Lack of support for portable PDBs

Various ways to include source information with no prescribed methodology built into the tooling

Since Symbols and .nupkgs are maintained by separate services, providing a first-class experience for both is impossible to do

In addition to building a first party service to address the above issues, we are also partnering with the maintainer of SymbolSource to provide additional value to members of the .NET ecosystem. Expect more information on this soon.

Improve validation times on package submissions

Github discussion issue

In December 2017, we changed the NuGet.org backend publishing pipeline to introduce a set of validation steps for packages. Our goal is to maintain the same level of experience in terms of the time and effort it would take to publish a package and have it available for download. However, these new validation steps caused a few incidents that resulted in significant delays in the publishing workflow. As mentioned in our recent blog post, we plan to reduce the overall time it takes to validate packages as well as improve our communication and reporting for related service degradations.

PackageReference migration tool

Feature specification | Github discussion issue

With Visual Studio 2017 and .NET Core, we improved NuGet package management by introducing the PackageReference feature in MSBuild. PackageReference enables capabilities such as simplified package dependency management, deep MSBuild integration, improved performance for everyday tasks such as install and restore, multi-targeting etc. The next logical steps include providing better guidance and help to users trying to migrate their projects to use PackageReference to express NuGet dependencies, and partnering with package authors to test various package consumption scenarios.

We want to hear your feedback!

While the experiences above capture our immediate plans, we are also aware of a few other that we simply could not get to in the current quarter and will be our top candidates in the rare event that we run out of work :). Otherwise they will be picked up for consideration in the next quarter.

Deprecate external icon URLs for packages NuGet#352

Allow users to determine version resolution strategy NuGet#5553

Manage allowed packages for a solution/repo (or globally) NuGet#5934

Package discovery: Show and search by TFM/package-compatibility NuGet#3098

Easy licensing embedded in package NuGet#4628

Package discovery: Show dependent packages NuGet#4718

Markdown support for documentation on NuGet.org NuGet#2280

Improve basic search NuGet#4124

We would love to hear your feedback on any additional items we should prioritize. You can reach out to us by commenting on the blog, emailing me at anangaur@microsoft.com or by tagging @NuGet in your tweets. You can also create an issue in our Github repository. We will be sure to announce any changes or updates on our NuGet/Announcements repo.