NuGet is a .NET framework release vehicle

NuGet is a .NET framework release vehicle

Rate This
  • Comments 12

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 clip_image002vehicle 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.

clip_image004

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.

Leave a Comment
  • Please add 8 and 6 and type the answer here:
  • Post
  • Can you detail how the Windows Update patching of NuGet libraries works exactly? How do you find out which assemblies on disk need to be updated?

  • +1 to Alex's question. It sounds scary to me.

  • @Alex/Kent: Great question! We'll be following up with a post on how this works under covers. In short it's not that scary; we made it possible for Microsoft Update to detect when a given assembly is being used and then use publisher policy to override the app's version with a version elsewhere. We never update a binary in-place.

    David Kean

    CLR Team

  • What about samples and documentation ? Is MSDN library updated after each package release ?

  • Please stop doing this until you figure out how 3rd library vendors can take advantage of this without being forced to also publish their stuff for free on nuget. There's lots of your stuff I could use in these packages that I'm not able to because you're completely ignoring the 3rd party component vendor story.

  • You mention enterprise customers. Most won't be able to use this, since 4.5 won't install on XP

  • @Morten: Not sure I'm following. To be clear, there are no plans to service 3rd party assemblies. We'll only service Microsoft owned assemblies.

  • @Enterprise customers: Point taken. However, being an enterprise customer doesn't imply running Windows XP. In fact, we've many enterprise customers that run later versions of Windows.

  • @Immo: I think what Morten is asking is how can a 3rd party vendor distribute their .dlls that depend on NuGet packages without using NuGet themselves (which would make the library available to everyone for free).

  • Chilkat already does this: they ship their dll as a Nuget package (relatively new for them, i think it's like 2 or 3 months old) www.nuget.org/.../chilkat-win32

    You have to "unlock" the component via a license key, there is unmanaged code in there, which makes the thing 32bit/64bit dependent, so it's separate packages. Not ideal, but it's certainly possible.

  • Enterprise customers also may be using Win2k3 Server (or other pre-Win2k8 Servers).

  • @Svick and Morten. I see, you're basically asking for a VS toolbox experience for NuGet components. Today, this model doesn't exist. I assume you've an installer that puts the components in the toolbox/installs specific templates? I guess in cases where you're able to run code (such as when creating a project via a custom wizard) you could conceivably use VS automation to install a NuGet packages (assuming automation APIs exist). That's an interesting idea. How do you enforce the licensing today? Are you using the WinForm license manager?

Page 1 of 1 (12 items)