36 msdn magazine .NET Framework
Easier Use of .NET Framework NuGet Libraries
We intend to deliver .NET Framework versions more frequently
to make new features and fi xes available sooner. In fact, that’s al-
ready started with the .NET Framework 4.5.1. Additionally, we use
NuGet as a release vehicle to deliver our library features and fi xes
faster in response to customer feedback.
NuGet is a relatively new package format for the .NET
Framework. It provides a standard format for packaging libraries
that target one or more .NET profi les and can be consistently consumed
by developer tools such as Visual Studio. NuGet.org is the primary
NuGet repository and the only one the .NET team uses. Visual
Studio comes with an integrated NuGet client for referencing and
using NuGet packages in your projects.
We’ve been shipping .NET libraries on NuGet for the past few
years. We’ve found NuGet is a great way to deliver libraries to a large
number of developers and to multiple .NET platforms at the same
time. We’ve improved the NuGet UX in Visual Studio 2013 based on
broad feedback, particularly for enterprise scenarios.
Better Discoverability and Offi cial Support Th e Microsoft
and .NET NuGet feed was created to improve the discoverability
of Microsoft packages. NuGet.org hosts thousands of packages, which
could make it challenging to discover the new .NET packages among
all the others. Th is new curated feed provides you with a scoped
view of the offi cial Microsoft and .NET packages on NuGet.org. We
intend to only add packages to this feed that meet the same quality
and support requirements as the .NET Framework. Th erefore, you
can use these packages in all the same places you use .NET APIs.
We’ve also created a Web view of this feed on the “Microsoft .NET
Framework NuGet Packages” page (bit.ly/19D5QLE), hosted on the
.NET Framework Blog.
The NuGet team helped us enable this experience by
updating their client in Visual Studio to include filtering by
curated feeds. Figure 8 shows the NuGet client in Visual Studio 2013.
Serviceability Some enterprise customers told us they were
waiting to adopt our NuGet packages until central servicing was
off ered for these libraries through Microsoft Update. We’ve added this
update capability in the .NET Framework 4.5.1, enabling apps to take
advantage of the new feature. Microsoft Update will be an additional
release vehicle for .NET NuGet libraries in the unlikely case that we
need to quickly and broadly update a library for a critical security
issue. Even with this new option in place, we’ll continue to use NuGet
as a primary vehicle for library updates and fi xes.
Automatic Resolution of Version Confl icts Apps can reference
more than one version of a NuGet package. For desktop and Web apps,
you needed to manually resolve version confl icts to ensure that a con-
sistent set of libraries is loaded at run time, which may be challenging
and inconvenient. To address that, Visual Studio 2013 automatically
confi gures apps to use the highest referenced version of each library,
which solves the issue through a straightforward policy. It also matches
the policy already used for Windows Phone and Windows Store apps.
Visual Studio 2013 will automatically generate binding redirects in
app.confi g at build time if version confl icts are found within the app.
Th ese binding redirects map each of the versions found for a given
library to the highest version found. At run time, your app will use a
single version—the highest one referenced—of each library. Th e main
motivation behind this feature was to provide a better experience for
consuming NuGet libraries; however, it works for any library. Th e “How
to: Enable and Disable Automatic Binding Redirection” topic in the
MSDN Library (bit.ly/1eOi3zW) provides more details about this feature.
And Much More ...
Up to this point, I’ve summarized what was delivered in the .NET
Framework 4.5.1 release. In the same time frame, we delivered
some important new components and features through other
release vehicles as well.
HTTP Client Libraries NuGet Package Th e HTTP client library
provides a consistent and modern networking .NET API. It lets you
write intuitive and asynchronous code (using the await keyword) to
access services exposed through HTTP with method names that di-
rectly correspond to the HTTP primitives, such as GET, PUT, POST
and DELETE. It also provides direct access to HTTP headers and the
response body as any of the String, Stream or Byte[] types.
At fi rst, HttpClient was only available for the .NET Framework 4.5
desktop and Windows Store apps. Portable library and Windows Phone
app developers had to use HttpWeb-
Request and HttpWebResponse, with
their non-Task-based Asynchro-
nous Pattern (TAP) model. Based
on popular demand for portable
library and Windows Phone support,
we shipped the portable version of
the HttpClient library on NuGet
to fi ll the platform gap. As a result,
all .NET developers have access to
HttpClient, with its TAP-async API.
After the first few versions of
the HttpClient NuGet package
Figure 7 ASP.NET App Suspension Performance Numbers Seen in the .NET Lab were released, we added automatic
Figure 6 The State Transitions of ASP.NET Web Sites
Inactive Active Suspended