NuGet Spring 2018 Roadmap
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
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.
Light
Dark
0 comments