Base types, Collections, Diagnostics, IO, RegEx…
If you’ve installed the .NET Framework 4.5 RC, you may have noticed some differences between this prerelease and the .NET Framework 4.5 Beta. One of the changes we made was to move two libraries to an independent distribution model via NuGet.
Many of you sent us feedback about the frustration of waiting for a full product cycle to get small changes. By changing the distribution model, we are taking our first steps toward meeting this challenge. We expect this will enable us to invest in these libraries and deliver improvements to you faster.
The BCL is broad and varied, and not every library in it has the same lifecycle requirements. NuGet today provides an alternative to the full .NET Framework redistributable, and we want to take advantage of it where the model is a good fit.
The packages we are releasing on NuGet – TPL Dataflow and MEF for Windows Metro style apps – were included in the base installation of the .NET Framework 4.5 Beta, but are now available as NuGet packages. These packages are fully supported, first-class members of the BCL and offer additional functionality over their .NET Framework 4.5 Beta versions.
TPL Dataflow, which is part of the Task Parallel Library, is an exciting new library for building highly concurrent systems based on actor/agent-oriented techniques.
TPL Dataflow was implemented in the assembly System.Threading.Tasks.Dataflow.dll in the .NET Framework 4.5 Beta and was not available for use by Windows Metro style apps. In the .NET Framework 4.5 RC, TPL Dataflow is delivered in the Microsoft.Tpl.Dataflow NuGet package and is supported everywhere, including desktop, server and .NET for Metro style apps.
The simplest way to install the package in Visual Studio is to highlight the target project, choose Tools > Library Package Manager > Package Manager Console, and at the prompt type:
Install-Package Microsoft.Tpl.Dataflow -Pre
The -Pre flag is needed because these packages are marked as prerelease versions. You can use the GUI Manage NuGet Packages dialog box for this task as well, but when searching make sure to select Include Prerelease from the appropriate drop-down list:
The Managed Extensibility Framework (MEF), which was introduced in the .NET Framework 4, provides a “part model” for application extensibility and to keep applications flexible as they grow in size and complexity.
In the .NET Framework 4.5 Beta, Windows Metro style apps could use a subset of MEF functionality. Feedback on this approach led us to conclude that Metro style apps have different requirements of MEF than desktop applications do. For instance, extensibility by third parties is not a focus of Metro style apps. Instead, MEF use focuses on application decoupling scenarios in conjunction with patterns like Model-View-ViewModel (MVVM). By releasing MEF for Metro style apps as a NuGet package, we are enabling the .NET Framework to better adapt to the requirements of this application model.
The package ID for MEF in Metro style apps is Microsoft.Composition. To install the package from the Package Manager Console, type:
Install-Package Microsoft.Composition -Pre
You can alternatively install the package from the Manage NuGet Packages dialog box.
MEF for Metro style apps is built on the lightweight composition engine previously previewed for use with ASP.NET MVC. This composition engine enables us to tailor the experience better for Metro style apps, but also means that this release is not fully backward-compatible with the beta release. Documentation of the differences between the Microsoft.Composition package and the version of MEF in the full .NET Framework can be found here.
MEF is still included and supported in the .NET Framework 4.5 RC. Furthermore, we are continuing our development of MEF as an open source project. These changes affect Metro style apps only.
NuGet is a developer-deployed, developer-serviced distribution mechanism. This means that applications carry their own versions of NuGet-packaged assemblies. This greatly simplifies side-by-side deployment and often allows you to use new versions of libraries without needing a .NET Framework update on your computer.
Developers need to update and redeploy an application to take advantage of a new version of a NuGet package: new versions won’t be pushed out automatically with .NET Framework updates. This model doesn’t suit every kind of library, but we’re confident that for MEF and for TPL Dataflow this is the right approach.
NuGet is integrated into Visual Studio 2012 RC. The package repository (including Microsoft and third-party packages) can be viewed at http://nuget.org. To use NuGet packages in a disconnected environment, you can set up a local file share as a package repository using the Package Sources page of the Visual Studio Options dialog:
We’re very excited to be opening up new channels to deliver BCL functionality. We are deeply grateful to our early adopters and we've considered this direction carefully, although we realize that making this change in RC involves additional work for some of you.
We expect that our approach will evolve with the help of your feedback and experiences. To provide feedback on the TPL Dataflow release, please visit our UserVoice site. For MEF feedback, the MEF CodePlex project discussion forum is the best place to engage with our team.
Will TPL Dataflow be available for 4.0 (perhaps with the async targetting pack) or is it definitely 4.5+ only?
Please produce a PCL version
Hi Simon - which packages, and which platforms are you targeting? Thanks!
James, Thanks for the feedback. We will keep this on our suggestions list, though at this point we are not planning to do a 4.0 compatible release.
I would prefer the opposite. As a software developer in the Microsoft Word it is hard to follow up the new technologies and frameworks. Until now it was mostly in a two year cycle. But know we get updates (one of the MS NuGet packages) about every month.
I have experienced that the NuGet Packages (e.g. Entity Framework 4.x) suffer in quality (API, implementation) whereas the .NET Framework comes with a very high quality. And the worst part is that these are official releases and thus, bad API or wrong behavior is not anymore changed because someone could already use one of the frequent NuGet releases.
Hi Jim - thanks for sharing your thoughts. Making package releases predictable from a lifecycle standpoint is a high priority for us, and an area we are actively discussing.