Enterprise Library vs. Software Factories

Topics: General discussion, Pre-release discussions
Feb 2, 2007 at 4:51 PM
This may or may not be an issue, but I think it needs to be addressed.

Many if not all of the software factories come with their own version of Enterprise Library as well as custom extensions. A good example that I have been dealing with this week is the Web Client Software Factory, which does have its own signed assemblies and custom extensions.

In March when EntLib 3.0 is expected to come out, the WCSF will still be running on its own version 2.x, which will not contain the Validation Application Block, the new rolling log file tracelistener, and all the nice enhancements to the DAAB. I don't know for sure, but WCSF may lag behind the new version of EntLib by 3 to 6 months or more depending on what it takes to integrate it successfully and, of course, based on their own release schedule. The same goes for the other software factories, too.

This will also make the Integrated Visual Studio Configuration Editor useless in some cases and we will need to run the stand-alone config tool that ships with each software factory, because it needs to be in the same directory as the assemblies.

If you aren't using the software factories this is not a big deal, but if you are using the software factories, one will want to immediately use the new features in EntLib 3.0 before the factories directly support them as well as a single configuration tool / built-in editor.

How is this leap frogging effect going to be addressed? Again, I know I will want to use the new functionality in EntLib 3.0 as soon as it is released with the software factories and I need a good answer :)




David Hayden
Microsoft MVP C#
Feb 2, 2007 at 6:29 PM
Hi Dave -

Great question. Now that we're starting to get a lot more dependencies across different p&p deliverables, we're trying some new approaches to deal with this complexity. Essentially, if deliverable A depends on deliverable B (examples: A=WCSF, B=EntLib, or A=EntLib, B=ObjectBuilder), we will ship the binaries of B (only) inside A's package. If you want the source of B, you'll generally need to get that from a different package.

We are trying very hard to maintain consistent versions of deliverables across different packages, eg the versions of the EntLib binaries in WCSF and WCSF are the same (which is labeled 2.0.1, and is the January 2006 version plus the medium trust patch, in case you're wondering).

Still, we can't stand still forever, and versions will change. The policy is that, wherever feasible, each "A" deliverable will ship the binaries of the latest available version of "B". In the event that we ship a new version of B before the next version of A, it will be up to you on whether it's worth updating A to use the new B. We try hard to keep backwards compatibility, in which case it should be relatively straightforward (such as EntLib 2.0-3.0).

HTH - I really should blog this :-)
Feb 2, 2007 at 6:54 PM
It does help and make sense, but I am wondering if there will be more guidance when the time comes.

When EntLib 3.0 is released, I would like to use it with say the WCSF. My immediate question will be how, and I am hoping there will be clear cut migration steps to do it.

In some cases, the WCSF will be using the current block in their framework like the Logging Application Block or Security Authorization Block. In other cases, they won't be using the block in the framework like the DAAB or Validation Application Block.

I just don't want it to be complicated and/or be a surprise that developers will want to use the new stuff. There are a lot of good and much needed changes in EntLib 3.0 that I want to use in the software factories as soon as it released.

I am not expecting an answer now. I just want you guys to be prepared for the flood of requests and to have an easy migration process ( automated :) for when the time comes. I hope I am not asking for too much.




David Hayden
Microsoft MVP C#
Feb 3, 2007 at 3:55 PM
I with David on this. I want to start using WCSF, but not until it fully benefits Entlib 3.0.

But i see the problem, when u develop Entlib 3.0, all the other projects can't wait for it to finish.
Mar 7, 2007 at 10:05 PM
I too with David & Benny, in my current application we are interested use some features (VAB) from Entlib3.0 in WCSF. We are facing some problems in integration. Can anyone tell exactly when can we expect fully tested installer available of WCSF with Entlib3.0? We are waiting for this installer.

Ramesh Tamma
Mar 7, 2007 at 11:17 PM

Perhaps I'm not quite right on this but as far as I remember someone mentioned that all blocks in EntLib 3 are backward comportable with 2.0 I mean blocks in 3.0 which came from 2.0 - DAAB, EHAB, etc. So why don't just recompile the latest versions of factories (SCSF, WCSF, WSSF, I guess MCSF couldn't be supported so easy) with 3.0 release the same day EntLib will be shipped? Could this work? I think at least having a single version of EntLib and avoiding the compile-time version collisions is ok at first.

Mar 8, 2007 at 9:05 PM
This is a great discussion and one that we in patterns & practices will continue to discuss as our products our become more dependent on each other. With EntLib 3.0, we believe that it will be a fairly smooth transition for WCSF customers to migrate from EntLib 2.0 to EntLib 3.0 blocks that are used in the factory. That being said we are doing 2 things with regards to EntLib 3.0 in WCSF:

  • We plan to smoke test WCSF with EntLib 3.0's existing blocks to see what challenges customers will have. Depending on the finding we determine our next course of action.
  • We plan to utilize new EntLib 3.0 capabilities in WCSF Release 2 which starts in April. As outlined in the roadmap posted on the home page, validation is one of the core challenges we plan to address. If there are other EntLib 3.0 capabilities you think we should address please add them to the Issue Tracker Page as this is an important source for our future direction.

Blaine Wastell
PM Client Program patterns & practices
Mar 9, 2007 at 11:10 AM

Just a quick question - are there any issues I could run into having both versions 2.0 and 3.0 installed which can block development using SCSF, WCSF and WSSF on the same pc? I mean the current versions of factories.


Mar 9, 2007 at 5:46 PM
Leonid - none that we are aware of.
Mar 9, 2007 at 9:55 PM
Thanks Tom!

BTW if I want to watch EntLib performance counters which ones I will get - from 2.0, 3.0 or a sum of both?

Mar 9, 2007 at 10:32 PM
We still have some testing to do, but we haven't changed any of the instrumentation classes, so both v2 and v3 should reuse the same counters.

Mar 13, 2007 at 3:39 PM
Basically, my idea is I have to reuse the same rules at 2 different levels (UI & Entity). I tried in that fashion, I came across the following 2 scenarios.

#1: I used Validation assembly in my application; I build the application without any conflict. I am not used Validation.Integration.AspNet.dll here. I used some predefined attributes at entity level. It's working.

#2: I created some rules and trying to use at UI level. Now the problem comes into picture. After submitting, I am getting the following error:
The property name required to retrieve validation information for integration is invalid or does not belong to a public property.
The same application I tried with out WCSF stuff, used only 3.0 dlls. It's working. But after integration this was happening.

Last week I tried the same sample, first I did #2. There only I stuck-up, I couldn't resolve the issue. For the above problem, my assumption is the validation assembly is using version common.dll is different version ( and in WCSF it's older version ( is using :-(..
May be the same is happens with other assemblies too. I am not sure.

This is what I am facing the problem. Can anyone help me out from this?


Mar 20, 2007 at 2:03 PM
I have
1. enable intrumentation block using entlib consol
<section name="instrumentationConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Common.Instrumentation.Configuration.InstrumentationConfigurationSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<instrumentationConfiguration performanceCountersEnabled="true"
eventLoggingEnabled="true" wmiEnabled="true"/>

2. run InstallServices.bat
3. write and run the below program
static void instrumentationOnDB() {
Database db = DatabaseFactory.CreateDatabase("TriRef");
for (int i= 0 ;i< 10000 ; i++)
db.ExecuteNonQuery(System.Data.CommandType.Text, "select top 10 * from job");

4. How do I see the performance counter in any form? Do I need to do more coding in order to see the performance couneter on Enrterprise Library Data Counter?