Just released – Microsoft Enterprise Library 6


Five months ago we formulated our vision for the new version of Enterprise Library. Now we are delivering on it. I’m excited to announce the latest release of Microsoft Enterprise Library: version 6.

What is Enterprise Library?

Enterprise Library is made up of application blocks, each aimed at managing specific crosscutting concerns. Crosscutting concerns are those tasks that you need to accomplish in several places in your application. When trying to manage crosscutting concerns there is often the risk that you/different team members will implement slightly different solutions for each task at each location in your application, or that you will just forget them altogether. Writing entries to a system log file or Windows Azure table storage, dealing with transient error conditions and validating user input are typical crosscutting concerns. While there are several approaches to managing them, the Enterprise Library application blocks make it a whole lot easier by providing generic and configurable functionality that you can centralize and manage.

Enterprise Library application blocks are standalone. They work well together, but you only have to get the ones that you need. They are also customizable and extensible, so you can extend them to provide what you need in your specific contexts. You can choose to use it as a seedwork and grow your own library, which you can later reuse and sell. We ship under MS-PL, so this is allowed.

What are the main themes for this release?

  • Simplifying the library all around
  • Embracing semantic logging
  • Increasing resiliency to errors
  • Enhancing Unity type registration
  • Supporting Windows Store apps (Unity, Topaz)
  • Streamlining programmatic configuration of all blocks
  • Integrating with other technologies (ASP.NET MVC and ASP.NET Web API)
  • Improving ease of learning, ease of experimentation (fast start), and ease of use

 

What’s in the box?

  • New block
  • New programmatic configuration
  • Updated 7 blocks:
    • Data Access Application Block
    • Exception Handling Application Block
    • Logging Application Block
    • Policy Injection Application Block
    • Transient Fault Handling Application Block
    • Validation Application Block
    • Unity Application Block/DI Container (v3.0)
  • Configuration console (largely unchanged since v5)

As usual, we are shipping not only the binaries, but also the source code and test cases (unit, integration). To see the details of what have changed and deployment instructions, see the Release Notes.

The diagram below depicts all application blocks and their dependency on the Common package (needed to support configuration tool experience) and optional interblock dependencies.

EL6

 

Additionally, in the next couple of weeks we’ll be shipping a reference implementation and several Quickstarts to showcase how the Enterprise Library can be used in certain scenarios.

How to get it?

Our primary shipping channel for code is NuGet. There are 27 NuGet packages. Search for Unity or EntLib inside NuGet Package Manager.

Additionally, we’ve made all deliverables available as self-extractable zip packages via Microsoft Download Center.

Our guidance deliverables are available on Codeplex today. After post-production work is completed, they will be published on MSDN. You will also be able to order the hardcopies of the Developer’s Guides or get them in PDF, Epub or Mobi formats.

How to get started?

Whether you are experienced with Enterprise Library or new to it, we have guidance to help you make the most out of this release:

The table below will help you orientate:

Enterprise Library 6 Guidance

Do I have to upgrade?

Strictly speaking, no. If you are happy with Enterprise Library 5.0, you can continue using that version. If the new and improved features of Enterprise Library 6.0 appeal to you, then you would want to migrate. Note: Enterprise Library 6.0 targets .NET4.5 framework only. Enterprise Library 5.0 works fine on .NET3.5, .NET4.0 as well as .NET4.5. So, in order for you to move to .NET4.5, you don’t have to upgrade.

How to get help and provide feedback?

Many people provided feedback on our vision, our backlog and CTPs. We thank you all.

If you’d like to provide further feedback, please post it via the Codeplex forum. This is where you can also get support. We have a dedicated sustained engineering team monitoring the forum regularly. To report a bug, use online Issue Tracker.

If you have a story of how your team leverages EntLib and would like to share it with the broader community, please contact us. We’ll be happy to work with you on a case study.

Happy coding!

Comments (20)

  1. Ben Lin says:

    Great! It's a long time waiting for me.

  2. Aaron says:

    Just upgraded and now I am getting EnterpriseLibraryContainer not found… did this move namespaces?

  3. @Aaron,

    The Enterprise Library blocks no longer use the Unity container to resolve instances. You should remove all calls to the AddNewExtension<EnterpriseLibraryCoreExtension> method of the Unity container from your code. If your application currently resolves Enterprise Library objects from the container, you must either manually register the required types in the Unity container, or modify your application to use the static facades in the blocks to configure and retrieve the Enterprise Library objects your application uses.

    Also, for other changes, don't forget to check out the change log and the Migration Guide.

  4. Aaron says:

    Nevermind, I just found it in the migration guide (which I didn't know existed).

    The bootstrapping code for all of the blocks has changed in version 6 of Enterprise Library. The blocks no longer use Unity to manage the initialization and configuration, and each block now includes its own bootstrapping code. Any calls to the EnterpriseLibraryContainer.Current.GetInstance method to resolve a type from one of the Enterprise Library blocks should be replaced with the block specific bootstrap code. For example, to create a LogWriter instance based on configuration in the app.config file, you can now use the following code:

    LogWriterFactory logWriterFactory = new LogWriterFactory(); var logWriter = logWriterFactory.Create();

  5. Mark says:

    NuGet tells me there is a Unity upgrade available for my .NET 4.0 project.  It looks like the Unity 3 NuGet package doesn't have any .NET 4.0 DLLs, not even the old versions, so I assume letting it upgrade would be a bad thing.  Is there something you can do in the NuGet package, or I can do in my project, to stop the Unity package from being upgraded – I'm concerned that I will hit the new "Upgrade All" button at some point!

  6. Julian Dominguez says:

    @Mark, this is how NuGet works, and we (p&p) can't add anything on the metadata to prevent it. But they have a way to setting the allowed version you know work on your project.

    Open the packages.config and add the allowedVersions attribute to the Unity package:

    <package id="Unity" version="2.1.505.2" targetFramework="net40" allowedVersions="[2,3)" />

    More info here: docs.nuget.org/…/versioning

    Hope it Helps,

    Julian

  7. Maciek says:

    Any news on the Azure application scaling block? What about compatibility with the latest WindowsAzure.Storage NuGet packages? (v 2.0?)

  8. Matt Ring says:

    Grigori – This looks interesting, but I think the developers guide is still a bit daunting for the uninitiated.  At 269 pages, it's not a very good "elevator speech" to help me understand why I would want to choose EntLib over other open-source components (i.e. Log4Net for logging, for instance).  I'm hoping the quickstarts coming in May are much more consumable.

  9. @Maciek, not in the near term. Re: Azure Storage v2.0 client, you may find this thread useful – social.msdn.microsoft.com/…/03a7f909-9edf-447a-af04-f73edcdc3113

  10. @Matt,

    Thanks for the feedback. The dev guide is in preview. It's still work in progress. To answer your specific question re: logging, I suggest you take a look at my previous post explaining semantic logging and why you'd want to use it – http://aka.ms/semantic-logging . Quickstarts will be illustrating specific scenarios, which users have indicated to us to be common.

  11. Is thre no support for the async/await keywords in the Data Block?!

  12. @kktingle

    We do support APM async methods in DAAB already, but we do not take advantage of the newer TAP versions of the ADO.NET methods in .NET 4.5. Feel free to add/vote on this story to our uservoice site for future updates – http://entlib.uservoice.com

  13. Brian says:

    We're nearing the end of may. When will the documentation and samples be available? Thanks.

  14. @Brian in May as planned.

  15. Anup says:

    Where is the Caching block???

  16. @Anup

    The Caching Application Block has been marked as deprecated in v5 and removed in v6.

    Its functionality is now built-in to versions 4.0 and 4.5 of the .NET Framework. You should consider using the .NET System.Runtime.Caching classes.

    Also, Windows Azure includes Windows Azure Caching and Windows Azure Shared Caching as two alternative approaches to caching to use in your Windows Azure applications.

    AppFabric for Windows Server includes caching features for Windows Server 2008 and Windows Server 2012.

  17. @Maciek, please see this update on the autoscaling story and Wasabi –  http://bit.ly/10zldlA

  18. @griorgi why does ExecuteSprocAccessor doesnt have says:

    an overload of  putting values like

    defaultDB.AddInParameter(sprocCmd, "state", DbType.String, "New York");

    it seems that now , i must be careful cuz params insertion to ExecuteSprocAccessor is by order or apperaence ( very dangerous)

  19. irfangoren says:

    Hi, i was using EL5 caching which depends on common.dll. Now, I want to upgrade to EL6 and use other application blocks and i think i can continue to use EL5 caching also, but does work with EL6 common dll?

    Thanks

  20. @irfangoren

    Not out-of-the box. You can certainly port it by doing the same kind of refactoring we've done for the rest of the blocks. The runtime objects were not affected, but you'd have to change the container-based factories from v5 into the (arguably simpler) approach from v6.

    On a different note, is there a reason for not migrating to the caching support in the .NET framework?