I've inherited a project that makes use of the EnterpriseLibrary; specifically with regards to logging. The code base is currently on v3.1, but is being upgraded to v5.0. v3.1 impl currently makes use of the ObjectBuilder P&P tool/namespaces
(specifically Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder and Microsoft.Practices.ObjectBuilder), which appear
to not be in v5.0 any longer.
From those namespaces, there appears to be a number of attributes and base classes looks to have been obsoleted c. v4.0 (attributes and classes listed at the end of this post). From what I can tell, this v4.0 refactoring in the EnterpriseLibrary was meant
to have a zero-impact for backwards compatibility (from MSDN article found here http://msdn.microsoft.com/en-us/magazine/ee335709.aspx and from 4.0 release notes; specifically the
2nd bullet listed here: http://msdn.microsoft.com/en-us/library/cc511712.aspx#Changes_That_Affect_All). But I'm having trouble reconciling the design goal
for backwards compatability while removing namespaces, classes and attributes. Any thoughts? Very possible is related to my new exposure to the EnterpriseLib block. Any input/suggestions you could give around accommodating these now
deprecated items would be appreciated as well...
Thanks in advance,
Classes/Interfaces used in v3.1 which are no longer in v5.0:
- TraceListenerAsssembler (sic.)
Entlib 5.0 ChangeLogs somehow shed some light. I also suggest you to check out the
Entlib 5 extensibility hands-on-labs which goes into the details on how to build a variety of extensions to Enterprise Library, including custom trace listeners.
Noel Angelo Bolasoc
Global Technologies and Solutions
The changes to remove ObjectBuilder happened in Entlib 5.0, not Entlib 4.0. so statements of back compatibility in the Entlib 4.0 release notes are not relevant. We were quite explicit in the Entlib 5 dev cycle and release notes that we broke existing Entlib
extensions in version 5.0. Our user research showed that only about 2% of users were writing any kind of extensions, so the pain for a small percentage of users was decided to be worth it for the perf and simplicity gains due to the architecture change inside
Entlib. The code that consumes the library (as opposed to extending it) remains highly back compatible.
Yes, that does mean you'll have to rewrite your custom trace listeners. Do the extensibility labs, at least the first exercise. You'll find that most of the stuff that was built in previous extensions can simply be thrown out - writing custom providers for
entlib has gotten much, much easier in Entlib 5. Fewer classes to write, less "this attribute points to a class with an attribute which points to another class" kinds of wireup, and supporting the config tool is almost automatic now, instead of having to write
yet another parallel type hierarchy. In fact, if you don't understand what something did in the old version (an Assembler, for example) then just ignore it. You most likely don't need it anymore anyway.