Enterprise Library V2 Roadmap

I thought it might be nice to give everyone a little peak into what we are doing for V2 from the development side.  With the release of Whidbey Beta 2 we are working hard on getting something out. 

The main thing we are focusing is giving a strong foundation that shows the direction of V2 for RTM.  We don’t expect to have everything converted, but enough to show you the general direction.

Here is the list of things that we are focusing on for our first community drop:

  • Logging:
  • Data
  • Configuration
  • Instrumentation

I will try to keep this list updated as start making decisions around the areas. Some of the things we have already done are the following:

  • Move Unit Tests:  Now you can have two compiles… debug and release.   No more trying to figure out what you need to do.  Of course, this does mean we will have to make some methods / classes public / protected for testing.
  • Removed the SR.strings files to use the new Resource generated code from Whidbey
  • Put everything into solution folders since we now have double the projects.

Now playing: 311 - Grassroots

Comments (13)

  1. Carlo Folini says:

    Did you plan some beta release?

    I’m starting a project targetting 2.0 platform so having EntLib 2.0 would be a great feature!

  2. I don’t like feeling so isolated from the development of this project. It doesn’t have an open source community feel at all.

    Also, the more I think about it, the more I feel that this project has taken the wrong direction. It’s too large and intimidating to deal with. I think the original Application Blocks idea was closer to the mark. What I would prefer to see would be it split out into blocks again with a common and versioned Configuration Block. Each version of a given block would be dependent on a certain level of the Configuration block, but not anything else (since the magic mapping between the blocks generally takes place there, this should be feasible). One difficulty of this is that you have to make future versions of the config block be backwards compatible, so if I have a DAAB that’s dependent on V2 Config and a Logging that dependent on V1.3 Config that they both work. You’d handle this by putting version numbers in the databaseconfiguration.config, loggingconfiguration.config files.

    I haven’t really checked the source, but this seems doable. It also allows more flexibility in upgrading only the blocks that I need for my project. I can see some versioning difficulties that might require GAC’d assemblies or something, but there should be ways around it.

  3. If you need any testers I will volunteer. Email is cwoodruff@terralant.com

  4. Enterprise Library V2 is coming!

  5. jhaines says:

    One of the stated design goals for the Enterprise Library was that the individual blocks can be used independently. This doesn’t seem to work out of the box ("Just modify the code!" isn’t an appropriate answer).

    If I want to use the Data block, it requires 1) the Configuration block – and the configuration file nightmare that goes along with them, 2) The Instrumentation block – which requires installutil-style installing, breaking xcopy deployment

    Something to be considered for future versions

  6. Sekhar says:

    I tried in vein to use Configuration Application Block on a webfarm with atleast 50 different applications (on 3 servers). Reason, I couldn’t figure out how to configure a SQL storage provider, and how to maintain the same application on different servers on the webfarm.

    It would be really nice if you have a few sample projects which uses Configuration App Block.

    I find it still wague in figuring out how to configure Application Configuration Block for multiple applications. There was no document which would explain me what to have in the SQL server for using a SQL Storage Provider.

    Please give us samples…


  7. Sean says:

    I’m also available for preview testing of v2 testing.

    sean_r_woodward @_do_not_spam_hotmail.com

  8. Tom Pester says:

    Some people here share my thoughts too. I think you are loosing a whole group of developers who are looking for a KISS solution.

    This has been discussed here too :


  9. Steve says:

    Twice I’ve sent one of my developers to look into using a component from this library. (Or maybe it was the patterns & practices library. Or are they same thing? I dunno!) It sounded like a no-brainer to get free configuration management, etc.

    Anyway, they both came back with the same feedback: it’s another complicated mess I’ll need to learn, and it has too many pre-reqs => it’ll be easier to just write this myself.

    The idea of a re-usable set of enterprise blocks is great, but until:

    a) they’re easier to use

    b) the benefits of use are clearer

    I don’t believe they can be successful.

  10. I’m also available to beta test a whidbey release, btw.

  11. charlie ash says:

    I’ve got to say that V1 is great and I look forward to V2.

    I’ve used alot of Java open source libraries (Apache log4J, JBoss Cache, Hibernate) before and I’ve got say that integration all the different JAR files is hardwork. The XML files is so confusing and each project use a different standard.

    With the Enterprise Library, you’ve got an easy GUI config tool and a simple APIs.

    For all those who complain (http://blogs.aspadvice.com/ssmith/archive/2005/04/20/3438.aspx), I’ve got to say you guys most likely don’t need enterprise features in your app so you don’t see the benefits of this tool.

  12. I cannot carry the burden of technical fear and ineptitude any longer!!! I have never used the Enterprise…

Skip to main content