I wouldn't mind if you were to add: Make sure not everything is sealed / non-public and allow easy extension/decoration of the IBuilder/IFactory pattern.

If possible, could you make sure the objects associated with Logging and Exception Handling blocks are serializable so we can use EL4 within SharePoint (MOSS) custom workflows developed in VS 2008? I can't use EL3 because the objects are not serializable; therefore, SharePoint throws a hissy fit when it tries to dehydrate the workflow and finds non-serializable objects.

fmorriso - thanks for your feedback, which objects? handlers themselves?
francois - merci pour votre respond - yes, we'll unseal those and the DI container will allow the extensions you are looking for.

Will new release address this issue: "Logging Messages and Exceptions to Same File TraceListener" (http://www.codeplex.com/entlib/WorkItem/View.aspx?WorkItemId=10278)?

I hope DAAB 4.0 will support SQL Compact 3.5!

Can we have "Can be Null" on all Validators to make "Can be NULL or Integer in the range 1..12" a lot easier?

rrmamedov - yes, I'll update the backlog with this story
johntenney - DAAB 3.1 already supports SQL/CE. It's not part of the main solution, but it is there. Check the source code.

I have tried to improve TextFormatter by myself and did get a x14 speed increase.
http://geekswithblogs.net/akraus1/archive/2008/01/14/118543.aspx

Perhaps it helps to streamline the performance of the formatters even more.

Yours,
Alois Kraus

what's the plan around WPF validation? will the block provided by Martin (http://www.bennedik.de/2007/05/update-of-wpf-integration-for.html) formally get into EL 4.0?

AtulGupta - have you seen story #26?

It would be great if the PIAB could inject on Generic methods... eg:

[ValidationCallHandler]
public void SelfValidate<T>(T p) //eg. if "T" contains [SelfValidation] methods
where T : class, IAccount
{
//...
}

In VAB, having better RuleSet management becomes crucial. On all validators, there should be at least a MultipleRuleSet property, or better: IncludedRuleSets and ExcludedRuleSets. It is essential when you start dealing with rulesets representing the states of your entities.

I'd love to see ODP.NET support added. We need some of the features of ODP.NET to improve performance, and we are considering abandoning the Enterprise Library (for data access, anyway) for an Oracle-based project because that support is missing. We've played around with the code on Enterprise Library Contrib (http://www.codeplex.com/entlibcontrib/WorkItem/View.aspx?WorkItemId=3167), and it works fine for some scenarios, but we have parameter type conversion issues and a few other problems that we didn't have when using System.Data.OracleClient. We can get things working if we use ODP.NET directly, but we don't have the resources to work through all the problems when the Enterprise Library is sitting in between. It's the second-most requested feature in Enterprise Library Contrib, but nothing seems to have happened on it since the draft code was uploaded months ago. I know it's non-trivial, but it would be really great to see that work finished.

Any chance of getting patches for known bugs and easy fixes (in particular, the ones mentioned for the VAB), rather than waiting for the 4.0 release and requiring an upgrade?

Not sure if this has been spoken about but is there any need for any changes for EL 4.0 if we want to use LINQ for our data access and EL for the rest (config, exception, logging, etc.) ?
Will it be possible to use the LINQ to SQL OR mapping tool for our data access? Or will this replace the EL 4.0 DAAB

Adam Dialect:
I ran into the same issue with generic methods and found out why the policy handler wasn't properly executing the policies. Basically, the policy handler uses a Dictionary keyed using MethodBase objects to cache the configured pipelines for each method on the intercepted class. Unfortunately, when the dictionary is built, the MethodBase objects used are the generic versions of the method information, not the "Closed" version that is actually passed in to the Invoke() method of the InterceptingRealProxy class, which actually does the interception. Therefore, it can't find a configured pipeline for the method and doesn't execute a pipeline at all. I've got what looks like a reasonable solution to the problem, which involves modifying InterceptingRealProxy (and, since many of the classes it depends on are internal, I had to move a bunch of those classes over as well). It is really only about a 5 line code change to InterceptingRealProxy - In the Invoke() method, check if callMessage.MethodBase.IsGenericMethod and, if so, cast callMessage.MethodBase to a MethodInfo object and use the results of the GetGenericMethodDefinition() method as the key into the memberHandlers dictionary instead of callmessage.MethodBase.

I'm working to get permission from my company to post my modified policy injector code here, but given the actual change is so minimal you may just want to recompile EntLib and put this support into the baseline 3.1 codebase locally.

Hye To all the team guys !

First, Thanks for this huge job and Project to make such Framework as you did and you still do..

I would ask you several question or remark about DAAB in the version 3.1.1. I am using in a deconnected project (yes, the constraints are very different compare to connected mode)

Will you project to allow the Adapter to NOT AcceptChanges on ALL the datatables in a DataSet when the SqlExDatabase.UpdateDataSet methods is invoked with only one DataTable or DataRow[]...Default Value of an Adapter are
AcceptChangesDuringFill = true;
AcceptChangesDuringUpdate = true;

With the EntLib COntrib 3.1.1 (same problem in 3.1) DAAB the invocation of this fonction make all the DataRowState to 'unchanged' of ALL DataTable in the same DataSet -> Huge problem with deconnected mode when several DataBase DBcommand are needed to update the data on several Table from several DataTAble (with cardinality 1..n realtion) in the same DataSet...

Typical Example :
1 Order and n Products...with deconnected Mode,n orders and Products are stored in Different datatable..now using DAAB 3.1.1, I invoke UpdataSet with the Datatable Order with adapted DBCommand (such SP = Stored Procedure)...the RowStates of added , deleted or modified Products will change to Unchanged whereas the DBCommand concern ONLY the Order DB Table...maybe because of the default Value of the used Adapter returned by the SQLexDataBase.GetAdapter..

Because of the Atomic contraint with using the UpdateDataset methods, a solution is to use complex Query DBcommand but with SP is going to be too heavy ...because this mecanism requires to instore a deserialisation of the n Products into the SP ...(huge treatment so dicrease of Server Performances)

Second solution is to not use the compiled DAAB DLL and modified the Adapter value...

My .NEt competences are very young (I start on January 2008) so maybe I have a wrong reflexion about DAAB using. Or I have maybe ignored too much that the creator ( Chris Dufour) works with ASP.NET (which is maybe only connected mode)

Maybe this exposed is really a present problem and a solution is already present in 4.0 version...if not I will be very pleasure to help you to resolve this problematic...

What ever receive an amical 'Bonjour et merci' from France , Have fun and Enjoy on the Entreprise Library Project..

Julien Gourdet

Ok, Problem Found. I had created automation on the DataRelations with the used Dataset...With my previous solution I used the TableAdapter mecanism in the Data Access Layer ...

So I had checked "Cascade" for the Update, Delete, and Accept/Reject Rules and "Both Relation and Foreign Constraint" on DataRelations in the Visual Studio DataSet GUI. The cascade on the Accept/Reject Rule was giving me the problems. Once the parent table was updated and accepted, all of the child tables were evently automatically being accepted becuase of the DataRelations parameter . Once I set the Accept/Reject Rule to "None," everything worked as expected...
I found the solution grace to jimmarq in this topic http://www.codeplex.com/entlib/Thread/View.aspx?ThreadId=10402
Sorry to disturb this discussion but I search this solution till 3 days..If yu need to delete my 2 previous posts , make it , I make you my apologizes...

Another last point which may disturb the total control of the RowState is the default value of the Adapter (like write on top)
AcceptChangesDuringFill = true;
AcceptChangesDuringUpdate = true;

After the invocation of the UpdateDataset, must we, with no other way, copy the Rows (with no Unchanged State) to preserve the Rowstate after the delete...for example to inform which Row has been upadted on DB and which not..like :

dt = MydatatabletoUpdate.Getchanges(); //copy of the Rows which will be updated
SqlExDatabase.Updatedataset( MydatatabletoUpdate., DBcommands, etc...)
Displays (dt);//because MydatatabletoUpdate.Getchanges() == null at this moment.....if I want to preserve the changes How can I do with no data redondance ?

I think a fundamental story should be the ability for the LAB email sink to support smtp authentication.