Microsoft | patterns & practices | Developer Network | Enterprise Library | Acceptance Testing Guide | Personal Site
Last Friday I signed off on the last quality gates! Yesterday we had our Release Readiness Meeting, which gave a resounding GO to the Enterprise Library 5.0 and a round of applause to the team. As one of the directors concluded “It is a beautiful thing… Not just the product, but also how you’ve got there.”
And now… a drum roll, please. On behalf of the patterns & practices Enterprise Library team I am very excited to announce the world-wide availability of Microsoft Enterprise Library 5.0.
Enterprise Library is a collection of reusable software components (application blocks) designed to assist software developers with common enterprise development challenges (such as logging, validation, caching, exception handling, and many others). Application blocks encapsulate Microsoft recommended development practices; they are provided as source code plus tests and documentation that can be used "as is," extended, or modified.
Enterprise Library is intended for use by developers who build complex, enterprise-level applications. Enterprise Library is used when building applications that typically will be deployed widely and need to interoperate with other applications and systems. In addition, they generally have strict security, reliability, and performance requirements. The goals of Enterprise Library are the following:
Consistency. All Enterprise Library application blocks feature consistent design patterns and implementation approaches.
Extensibility. All application blocks include defined extensibility points that allow developers to customize the behavior of the application blocks by adding their own code.
Ease of use. Enterprise Library offers numerous usability improvements, including a configuration tool, powerful programmatic configuration support, intuitive interfaces, a simpler installation procedure that allows you to select only those application blocks you desire, and clear documentation, samples and hands-on labs.
Integration. Enterprise Library application blocks are designed to work well together or individually.
This major release of Enterprise Library contains many compelling new features and updates that will make developers more productive. There are no new blocks; instead the team focused on making the existing blocks shine, on testability, maintainability and learnability. The new features include:
– Major architectural refactoring that provides improved testability and maintainability through full support of the dependency injection style of development
– Dependency injection container independence (Unity ships with Enterprise Library, but you can replace Unity with a container of your choice)
– Programmatic configuration support, including a fluent configuration interface and an XSD schema to enable IntelliSense
– Redesign of the configuration tool to provide:
§ A more usable and intuitive look and feel
§ Extensibility improvements through meta-data driven configuration visualizations that replace the requirement to write design time code
§ A wizard framework that can help to simplify complex configuration tasks
– Data accessors for more intuitive processing of data query results
– Asynchronous data access support
– Honoring validation attributes between Validation Application Block attributes and DataAnnotations
– Integration with Windows Presentation Foundation (WPF) validation mechanisms
– Support for complex configuration scenarios, including additive merge from multiple configuration sources and hierarchical merge
– Optimized cache scavenging
– Better performance when logging
– Support for the .NET 4.0 Framework and integration with Microsoft Visual Studio 2010
– Improvements to Unity
§ Streamlined configuration schema
§ A simplified API for static factories and interception
§ The capability to add interface implementation through interception
§ Additional types of lifetime manager
§ Deferred resolution (automatic factories)
– A reduction of the number of assemblies
The detailed list of all changes is included in the Enterprise Library documentation and also online.
The Enterprise Library team tried its utmost to preserve the existing Enterprise Library APIs (v3.1 and higher). However, due to the redesign of the internals and the .NET Framework roadmap moving forward, there are some breaking changes. A full list is available here.
· Supported architectures: x86 and x64.
· Operating system: Microsoft Windows® 7 Professional, Enterprise or Ultimate; Windows Server 2003 R2; Windows Server 2008 with Service Pack 2; Windows Server 2008 R2; or Windows Vista with Service Pack 2.
· Microsoft .NET Framework 3.5 with Service Pack 1 or Microsoft .NET Framework 4.0.
For a rich development environment, the following are recommended:
· Microsoft Visual Studio® 2008 Development System with Service Pack 1 (any edition) or Microsoft Visual Studio 2010 Development System (any edition).
To run the unit tests, the following are also required:
· Microsoft Visual Studio 2008 Professional, Visual Studio 2008 Team Edition, Visual Studio 2010 Premium, Visual Studio 2010 Professional, or Visual Studio 2010 Ultimate edition.
· Moq v3.1 assemblies.
For the Data Access Application Block, the following is also required:
· A database server running a database that is supported by a .NET Framework 3.5 with Service Pack 1 or .NET Framework 4.0 data provider. This includes SQL Server® 2000 or later, SQL Server 2005 Compact Edition, and Oracle 9i or later. The database server can also run a database that is supported by the .NET Framework 3.5 with Service Pack 1 or the .NET Framework 4.0 data providers for OLE DB or ODBC.
For the Logging Application Block, the following are also required:
· Stores to maintain log messages. If you are using the Message Queuing (MSMQ) Trace Listener to store log messages, you need the Microsoft Message Queuing (MSMQ) components installed. If you are using the Database Trace Listener to store log messages, you need access to a database server. If you are using the E-mail Trace Listener to store log messages, you need access to an SMTP server.
If these dependencies are not met, you may not be able to use certain Enterprise Library features.
If you are new to Enterprise Library:
− read the Introduction to the Enterprise Library section of the documentation
− read and review examples from the Developer’s Guide
− download, compile and run the source code – study the code and the tests;
− practice the Hands-On Labs (the updated set of labs to be released by the end of April);
− watch the videos;
If you already know and love Enterprise Library:
− check out the change log for this release;
− upgrade to v5.0 – to help you with this task, we’ve written the Migration Guide;
− practice the updated Hands-On Labs (the updated set of labs to be released by the end of April);
− watch the videos;
Community support is provided via Enterprise Library Codeplex forum.
Customers can also obtain support through Microsoft Premier Support Services, but the code is considered user-written by Microsoft support staff.
We would appreciate feedback on any issues found, or any other general comments on this release.
To report a bug, use online Issue Tracker. Other feedback or questions can be posted on the Enterprise Library Codeplex forum.
We are looking for stories. If you adopt Enterprise Library on your project, please let us know – share your experience, join our advisory board, help us drive the next great release of the Enterprise Library. After all, Enterprise Library is driven and built by developers and for developers.
Thanks. I was being using the beta2 product for a while , now i will switch over to this release version
Is Windows XP not supported in this release?
Typically we, at patterns & practices, go back two OS releases when defining our platform test matrix.
That's why Windows XP is not listed in the system requirements since we haven't done as rigorous testing on it as we've done on the listed OSs. Having said this, you should be able to use Enterprise Library on Windows XP with .NET Framework 3.5 SP1 or .NET Framework 4.0 installed. Several beta testers also confirmed this.
Please let me know if you run into any problems.
Thanks to you & your team for this awesome product.
Good news from P & P,I really appreciate your efforts to safeguard the developer community. Keep the good work up,I believe this new release will truly accelerate development.
Thank you! When will the Unity site on CodePlex be updated?
Unity codeplex site will be updated when Unity is released standalone (both desktop and Silverlight versions). Code is done. We are finalizing the doc set for these releases. Should be ready in the next couple of weeks.
The Unity 2.0 final binaries are included in the Entlib 5.0 package, so you can go ahead and start using them before the final standalone release.
Pardon me if I've missed something. I've been searching all day for these answers. I appreciate your assistance if you can give it.
1. Is the Unity 2.0 included with this the release version or a beta?
2. How can I rebuild the Unity 2.0 that is included with this release to be .NET 4/VS 2010? The source doesn't seem to be in the EntLib50 source.
Thanks for your interest in EntLib and Unity.
To answer your questions:
1. Yes, Unity 2.0 final binaries are included with this release of Microsoft Enterprise Library. Not beta, final!
2. The standalone Unity installer is not available till later this month. Thus, if you want to get the source code of the final Unity2.0 bits now, they are available at http://unity.codeplex.com/SourceControl/changeset/changes/50871
This is what the final signed Unity 2.0 dlls, packaged into the EntLib 5.0 final msi, are built from.
Hopefully, this helps. Please let me know if you have any other questions.
Excellent! I'm loving this new stuff. Great job!
I got the Unity source you pointed me to and, after commenting out and replacing a few deprecated Attributes ctor calls (SecurityCriticalAttribute(SecurityCriticalScope)), I managed to compile Unity 2.0 on .NET 4.0. (697 warnings, but who's counting?)
One last thing assembly still on pre-4.0: Microsoft.Practices.ServiceLocation.
I strongly recommend against recompiling the ServiceLocation DLL for .NET 4.0. The whole point of that DLL is to provide a single, binary standard interface. If you recompile it, you've changed the assembly signature, and none of the other adapters will work against it.
Why do you want to do this? Is there some actual value other than saying everything's targetted at .NET 4.0?
Well, perhaps that's a good question. I guess I assume there is some advantage to everything targeting a single .NET runtime. Compatibility or efficiency or something? I have a notion, though perhaps it's wrong, that each referenced runtime will have to be loaded, and that this is less efficient. Am I wrong about this? Should I not worry about multiple runtimes being targeted by various DLLs?
Incidentally, I DID find and re-target Microsoft.Practices.ServiceLocation, but I can always undo the damage if I shouldn't have.
My next quest was to be an attempt to find and re-target source for Microsoft.Practices.EnterpriseLibrary.Configuration.Design.HostAdapter.dll and Microsoft.Practices.EnterpriseLibrary.Configuration.Design.HostAdapterV5.dll, incidentally.
I did a little reading and now understand - if indeed I understood - that assemblies compiled under older runtime versions, when loaded into AppDomains running newer runtime versions, just use the corresponding assemblied and classes from that newer runtime version because it is, in almost all cases, backwards compatible.
This being the case, I suppose won't worry about the .NET 2 assemblies:
The cool thing about that is: I'm done!
Thanks again, Grigori and Chris. Great work!
We will upgrade our ecommerce system v3.0 based on new enterprise library 5.0.