This post describes how the .NET team uses NuGet and how discoverability and serviceability have improved in the .NET Framework 4.5.1. It was written by Alok Shriram, a Program Manager on the .NET Core Framework Team. 

Update: Read PCL and .NET NuGet Libraries are now enabled for Xamarin to learn more about how our NuGet packages can now be used on all OSes.

The .NET framework team has been increasingly adopting NuGet as a delivery vehicle over the last few years. The ASP.NET and EntityFramework teams have been leading that trend, while the core .NET team started using NuGet in 2012.

NuGet allows us to ship library features faster and to multiple platforms at once. It also enables us to directly engage with you, as we deliver prerelease and then stable versions of our work. Thanks for all the feedback that you’ve given us.

Some larger enterprise customers have been hesitant to adopt our NuGet releases, for a few different reasons. We believe that we’ve solved those issues in the .NET Framework 4.5.1.

We have also spent time rounding out the experience beyond just .NET itself. We want to make consuming .NET Framework NuGet packages a first class experience in Visual Studio. Let’s take a look at what’s changed.

Discovery and support

As we started to talk with customers about our NuGet releases, particularly those that are not regular readers of this blog, we would hear the feedback that our packages were not discoverable. We also had questions about the support level for these packages.

To resolve both issues, we created a .NET NuGet libraries feed that comes with our official stamp of approval, and the same level of support as the .NET Framework. You should think of the libraries in this feed in the same way as regular .NET libraries. The key difference is that they have a different delivery vehicle.

Microsoft Update servicing is another key aspect of support for many of our larger customers. To that end, we have extended the .NET Framework Microsoft Update servicing model to our .NET NuGet libraries feed. Should we need to patch a security vulnerability, we can now service .NET NuGet assemblies with Microsoft Update. This support is only enabled for apps running on the .NET Framework 4.5.1. Note that NuGet remains our primary release vehicle for updates, even if we do use Microsoft Update.

.NET NuGet feed in Visual Studio

The NuGet client has been available in Visual Studio for a few releases now. Up until recently, it provided a single view onto the large and growing NuGet catalog. That’s essentially the discoverability problem again. The NuGet team has integrated our feed directly into their client, so that it is easy for you to search for our libraries. Thank you, Nuget team!

In the NuGet client, you’ll see our feed show up as “Microsoft and .NET”. That’s the exact same feed I referenced above.

This same client is also available in Visual Studio 2012, as an update.

NuGet uses “Stable” and “Prerelease” concepts to describe quality levels. Packages that are marked as prerelease are subject to change in subsequent versions. That’s actually a big part of the value of NuGet, that we can make timely changes in response to your feedback. Once a package is stable, you can count on it being at high quality and not changing (in an API signature sense).

Portable Libraries Consumable in NuGet

You can build apps for Windows, Windows Phone and Windows Azure with .NET. We’d like to make that as easy as possible for you, which is why we build most of our foundational NuGet libraries as portable class libraries that support all of these platforms.

The concept of portable libraries was introduced in .NET 4.0. It enables you (and us) to create a class library which targets and supports 2 or more platforms, as a single binary. NuGet 2.1 added support for portable class libraries, which has enabled us to build and ship portable libraries via NuGet. The process of consuming these libraries from NuGet is now a seamless one.

.NET Library development, with NuGet

We’ve had a great experience using NuGet. On the .NET core team, we published our first NuGet packages in 2012, namely Microsoft.Composition (MEF V2) and TPL Dataflow. The feedback that we received from you since that time has been tremendous. We’ve also been able to improve our turn-around time to responding to bugs and the process and infrastructure we use. Over the last few months, about half the posts on the .NET blog have been for NuGet releases. That’s a sign of our investment in library development.

The nature of our NuGet releases range from new collection type class libraries like Immutable Collections, to frameworks like TPL Dataflow, which enable modelling actor-oriented parallel programming tasks, to libraries that bridge platform gaps like HttpClient and Compression. We’ve also released helper libraries using NuGet, like the TraceEvent library and the CLR crash dump library.

We intend to add most of our NuGet releases to our .NET NuGet feed over time. We also hope to get more teams at Microsoft to do the same. Some libraries won’t show up in the feed, since they don’t meet the quality and support level of the .NET Framework. That’s OK. The ongoing quality level of the libraries in our feed is an important “feature” for us to deliver on.

Summary

The .NET Framework team is using NuGet as a key release vehicle for releasing new libraries. It enables us to ship faster, address more of your feedback, and support multiple .NET platforms in a single release. With this release, we can also deliver the same .NET Framework discoverability and central servicing characteristics that you are used to.

Here’s what you get:

*Existing* .NET Framework values

• Great discoverability
• Known quality, maturity and compatibility level
• Single license and support policy
• Centralized patching for critical security issues

*Plus* new values, for NuGet libraries

• Faster release cadence with a tighter customer feedback loop
• Easy to target multiple .NET platforms

Thanks for the support and interest in our NuGet releases. We appreciate it. Are there other features that you would like to see in our NuGet packages? Please let us know in the comments of this blog post.