Enterprise Library vNext – Simplified!

TL;DR edition

We are simplifying EntLib. Next version targets Windows 8/Windows Server 2012 and .NET4.5. Help shape the release. Provide input via Uservoice.

Full edition

It’s been over 2 years since the last major release of Microsoft Enterprise Library. That release (v5.0) was the most successful release to date with over 1.5 million downloads and many teams using it in their systems development today. I regularly get feedback and testimonials from our users. Those are inspiring. We have also shipped two integrations packs – one for Silverlight and another one for Windows Azure.

Original mission

When the original Enterprise Library was envisioned back in 2004, the target audience included developers, solution architects, and operations specialists, who build, extend, and maintain .NET line-of-business systems that typically need to be deployed widely and need to interoperate with other applications and systems. The vision was to provide guidance and reusable components designed to encapsulate recommended practices for .NET application development which facilitate consistency, extensibility, ease of use, and integration. These components (which we call “application blocks”) address common cross-cutting concerns (like logging, validation, data access, error management), sparing you, the developer, from building your own plumbing (though many would consider that to be the most fun) and instead focus on what matters the most to your customers – the business logic. Thus, Enterprise Library is meant as a development accelerator.

The vision hasn’t changed.

Path forward

Over time, Enterprise Library evolved and grew by adding new application blocks and new features to the existing blocks. We kept the public APIs mostly backwards compatible with the previous versions of EntLib (going as far back as v2.0). As a result, EntLib became large and arguably more complex than it needs to be. In our efforts to simplify EntLib, we’ve removed certain features in v5.0 (such as WMI support) and announced deprecation of others in the future releases (such as the Caching Application Block). A year ago, I wrote a blog post On Deprecation elaborating on why deleting code is one of my favorite things. I encourage you to read it to better understand our approach to graceful deprecation.

The time has come to think about the future of Enterprise Library and Unity. In vNext, we’d like to revisit all the scenarios EntLib addresses and see whether they still make sense to be included. The .NET Framework has advanced big time in the past couple of years. Thus, we plan to deprecate many pieces that are not relevant anymore. In addition to the Caching Application Block, the Cryptography Application Block and the Security Application Block are likely candidates. We don’t want to be confined by the historical cruft. We will also do a sweep of all providers for other blocks and see which ones make sense to keep. This means that even the remaining blocks will be reimagined and possibly rearchitected, not simply ported. On the other hand, we’ll evaluate which blocks from the integration packs make sense to generalize. In the world of distribution and asynchrony, it’s likely that the Transient Fault Handling Application Block will play a much more prominent role and become more general purpose, not just focusing on the technologies and services offered by Windows Azure.

The way we envision Enterprise Library v6.0 and Unity 3.0 is that they will be targeted at Windows 8 and Windows Server 2012 developers that are using .NET framework 4.5. We would like to take advantage of all the new powerful features .NET 4.5 has to offer (including the new asynchronous features, new communication APIs, improved portable class libraries, instrumentation, etc.) as well as the full power of the Windows 8 runtime and application model. Keep in mind that EntLib 5.0 has been fully tested on .NET 4.5 already. You can use it now with confidence. We have also recently released a port of Unity to .NET4.5 and WinRT.

The guidance will embody recommendations and patterns of design for scalability, high availability, and high perf. Another important theme will likely be the unification and simplification of the configuration throughout. We recognize this is a non-trivial task.

Call to action

Considering the above, I’d like to issue an open call to action. Help us scope and shape the next release of Enterprise Library and Unity. Where should we focus our efforts? What stories should we address? Unleash your ideas. Don’t feel constrained by the current blocks or features. Think of an ideal world where all your wishes could be granted and the types of scenarios you really wished were supported. My call goes to our raving fans and loyal users, as well as to the avid critics. If you are annoyed by any of the EntLib features, make your criticism constructive – suggest improvements! We are not only listening, but also acting.

You can provide your input in a variety of ways:

Respond/comment/vote via UserVoice. Do not assume we are looking for new feature requests only. If there’s something in the existing EntLib you really want to see moving forward, please submit that as a separate UserVoice story. Also, please don’t be biased by the existing submissions –UserVoice displays them in the order of the most votes, but we suggest you review the entire list.

Comment to this blog post.

If you prefer, send me an email directly at grigori dot melnik at microsoft dot com.

Look forward to your suggestions!

Update [27-Aug-2012]: Call for Advisory Board Members

I describe how our Advisory Board operates here. We are lookig for both subject matter experts and passionate novices. If you are interested in being an advisor and helping us shape the next releases of Enterprise Library and Unity, answer this call.

Yes, it's dated and is still one of the most popular blocks. However, there's still plenty of stored procedures out there and people writing raw ADO.NET code. The Data Access Application Block is meant to help them.

How would your want it to be compatible with EF and more importantly why? If someone uses EF already, what are the gaps that EntLib can fill there?

I'd like an application block to guide me through the different ways I could implement workflow – MSMQ, WF etc…

The trick will be to keep the scope to a helper application block rather than write an Enterprise Service Bus. Surely, workflow is as useful as Data Access in the enterprise – so guidance in the form of the Enterprise Library would be helpful.

This is awesome! I just spent about 10 hours last weekend trying to figure out if the Enterprise Library was dead or not! Its not easy to find any info on this. I did see it in the Best Practices but there is no road map and no one every mentions the enterprise library when talking about data layers. Every thing you see in Microsoft documentation leads you to assume its dead. We'll I for one am glad its not.

Have you visited our codeplex site – http://entlib.codeplex.com? It has the links to the current and past roadmaps. We've shipped a lot of updates and 2 new integration packs. EntLib is definitely alive. The official documentation site – msdn.microsoft.com/entlib also has the newest information. Can you please let me know where you were looking so that we could update those pages as well?

Josh is right. I guess if the Entity framework could use DAAB for execute the SQL statements would be a pretty great idea. We could then intercept, change the connection feature and tune up the queries, also improve the performance

The Data Access Layer needs updated to have similar capabilities of Micro ORM's like PetaPoco. Example, I should not have to declare parameters manually when using ExecuteSqlStringAccessor. It allows you to pass params as part of a function call only when using Stored Procs…. It should handle results sets better and serialization of 1-M and M-1 calls as well.