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
- Anonymous
April 26, 2005
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! - Anonymous
April 27, 2005
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. - Anonymous
April 27, 2005
If you need any testers I will volunteer. Email is cwoodruff@terralant.com - Anonymous
April 27, 2005
Enterprise Library V2 is coming! - Anonymous
April 27, 2005
The comment has been removed - Anonymous
April 28, 2005
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...
Sekhar. - Anonymous
April 28, 2005
I'm also available for preview testing of v2 testing.
sean_r_woodward @_do_not_spam_hotmail.com - Anonymous
April 29, 2005
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 :
http://blogs.aspadvice.com/ssmith/archive/2005/04/20/3438.aspx - Anonymous
April 29, 2005
The comment has been removed - Anonymous
May 03, 2005
I'm also available to beta test a whidbey release, btw. - Anonymous
May 11, 2005
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. - Anonymous
May 30, 2005
I cannot carry the burden of technical fear and ineptitude any longer!!! I have never used the Enterprise...