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.
Read more: .NET Framework blog
QR: 