Announcing NuGet 3.5 Beta 2 and 2.12 RTM

NuGet 3.5 Beta 2 for Visual Studio 2015, nuget.exe and NuGet 2.12 RTM for Visual Studio 2013 releases provide quality improvements, performance improvements, .NET Core CLI support, and new target frameworks like netstandard and netcoreapp for our users.

Downloads

All NuGet downloads are available on http://nuget.org/downloads.

  • 2.12 RTM version of the Visual Studio 2013 will be available via Tools -> Extensions and Updates

  • [3.5 Beta 2 of nuget.exe] (http://nuget.org/downloads)

  • 3.5 Beta 2 is available through the following channels.
  • The .NET CLI 3.5 Beta 2 dotnet restore command also has been updated to this version.

New Features

Support for new Target Frameworks

.NET Standard and Net Core App TFM support is now available for Visual Studio 2012 users via the 2.12 release. 3.5 Beta 2 also now supports netstandard1.6 TFM for Visual Studio 2015 users. .NET Standard provides a more concrete guarantee of binary portability to future .NET-capable platforms with an easier-to-understand platform versioning plan.

PackageType

We have started to lay the groundwork for the support for a new PackageType property in nuspec which enables package authors to classify their packages (E.g Dependencies, Tools etc..). More information on this is available in the PackageType spec here.

MinClientVersion support in project.json

Project.json now supports MinClientVersion. You can now version packages that depend on newer NuGet versions so that you can prevent users from running into issues while trying to install packages using older versions of NuGet.

Release Notes

3.5 Beta 2

2.12 RTM

Issues List

3.5 Beta 2

2.12 RTM

What’s Next

The team is now shifting gears into transitioning .NET CLI from project.json into MSBuild and investing in performance and quality of the product.

We want to hear your feedback!

We want NuGet to meet the evolving needs of our community. If you would like share your pain points and your current and future needs, use the calendly link to set up a quick 15-30 min call with us. If you would like to send us an email instead, hit us up at feedback@nuget.org.

You can also leave a comment below, and as always, if you run into any issues or have an idea, open an issue on GitHub.

Published June 27, 2016 by Harikrishna Menon

NuGet API key expiration

Update 6/22 (2:15 P.M PST): We have a lot of feedback coming in from the community on this topic. This change will not have any impact for another 90 days at the minimum. We are reviewing your feedback and will discuss further how to achieve our goal of improved security of NuGet.org. We will have an update within the next 45 days. To continue the dicussion, we have openend a new GitHub issue here.

NuGet.org is growing blazingly fast. The past couple of years have seen a tremendous growth in the usage of packages from the NuGet gallery. It’s important to us and the community that package consumers are able to trust and use the packages that are uploaded to NuGet.org. Making your API key on NuGet.org more secure is one more step in that direction.

When publishing packages to NuGet.org from the command line, for example using nuget.exe, you need an API key so that we can authenticate the publish operation on the server side. Starting today, this API key will have to be refreshed at least every 90 days. We are introducing API key expiration as a means to keep your API key on NuGet.org shorter-lived.

What does this mean for me?

Today, no action is required. To avoid a big rush when the API keys first expire, we have set the expiration for your current API key to a value between 90 and 110 days.

When the API key expires, it can no longer be used for publishing packages to NuGet.org. At this point, your API key will have to be regenerated from your account page.

How do I know when my API key expires?

From your account, you can consult the date and time when your current API key will expire. When approaching the expiration date, we will send one e-mail informing you about the fact your API key is about to expire.

NuGet account page - credentials section

We are also working on an update of the NuGet command line to display a warning when your API key is about to expire:

NuGet client warning when API key is about to expire

We want to hear your feedback!

We want NuGet to meet the evolving needs of our community. If you would like share your pain points and your current and future needs, use the calendly link to set up a quick 15-30 min call with us. If you would like to send us an email instead, hit us up at feedback@nuget.org.

You can also leave a comment below, and as always, if you run into any issues or have an idea, open an issue on GitHub.

Published June 22, 2016 by Maarten Balliauw

Consolidated REST API deployed

A few weeks back, we deployed our consolidated REST API powering NuGet.org and the NuGet client experience in Visual Studio. An invisible change for our users, but a big change for the NuGet team. This consolidated REST API lays the foundation of our future work on the server side of NuGet. In this post, we want to expand a little on the history of the NuGet services and why it matters for us.

History of our internal REST API

Historically, NuGet.org used to serve all requests for packages directly from our database. With the number of NuGet users increasing, the number of queries on our database also increased. Around two years ago, the NuGet team built an internal REST API for use by our own services. It would provide package metadata, provide search results, handle download counts and all that - with great results: the database got some breathing room.

For the beta release of the NuGet 3.0 client, we faced a difficult decision: should we expose this REST API to the public, or build a new one? We decided to build a new, public REST API that would be used by our future NuGet clients. This decision was made because of several reasons. First, we wanted to move on from our OData API that was used in previous NuGet clients. Second, the REST API we had in place was very opinionated and tailored to our own services and not well suited for public access by our users.

So we ended up with an internal and an external REST API. When new features were being added in NuGet 3.0 and beyond, we had to implement them in all of our API’s - resulting in a lot of duplicate work. Both API’s had their own caching layer, which proved quite the challenge in keeping data in sync.

What we did

A few months ago, we set on an adventure of merging both REST API codebases and refactoring them to use the same caching layer. We cleaned up a lot of redundant code paths and optimized the caching layer. While not the scope of this effort, we also introduced a few minor improvements to several features - for example, we now recognize several commonly used acronyms like “EF” (Entity Framework) or “UWP” (Universal Windows Platform) in our search engine.

We fixed several tokenization bugs and differences between the two services. A large test suite for search was added as well, boosting our confidence in future changes and investment in the search engine.

Some improvements were introduced to the search results, like boosting on exact match to package id. A new logarithmic scale for download counts ranks packages with a high number of downloads slightly better - an algorithm which we will be tweaking further.

A lot of work has been done on performance. We profiled the API during load tests to optimize code paths and reduce the API’s memory traffic and garbage collector pauses. One notable improvement is the cold start of the application, which is down to a minute as opposed to the original 7 minutes.

Every few weeks we had a “flighting” moment where we would deploy our changes to a production-like environment, serving production traffic. This allowed us to benchmark the consolidated REST API and verify its responses.

This week, we deployed this consolidated REST API. And nobody noticed - the very nature of this sort of change. We are really excited about it. Reduced maintenance is a benefit we’re really happy with. The refactored code base also lays the foundation for future work on our REST API.

What’s next?

The consolidated REST API, much like our switch from WCF OData to Web API OData, is a project to reduce maintenance and improve the foundation on which the NuGet services are built, for today and tomorrow. We are also working towards documenting the API.

We want to hear your feedback!

We want NuGet to meet the evolving needs of our community. If you would like share your pain points and your current and future needs, use the calendly link to set up a quick 15-30 min call with us. If you would like to send us an email instead, hit us up at feedback@nuget.org.

You can also leave a comment below, and as always, if you run into any issues or have an idea, open an issue on GitHub.

Published May 19, 2016 by Maarten Balliauw

Older Posts