We just started to use Enterprise Library 5 in a project here. One thing that we almost always do is takeout the EntLib configuration out of the App.config/Web.config file. I already did that several times in the past using other version of Enterprise Library with no problem.

What was my surprise today when I tried the same thing I always did with previous version and found that it wasn’t working anymore!

This is the configuration I have in my configuration editor:

I am configuring a Web Application Project and I'm expecting EntLib to find my entlib.config at the root of the website… Wrong!

The problem reside in the fact that the file path resolution logic go through a new method in v5: GetRootedCurrentConfigurationFile, and the current implementation do not handle non rooted path correctly. The problem is that the method try to check the file existence before fixing it when dealing with a non rooted path. Here is the code directly from FileConfigurationSource.cs

private static string GetRootedCurrentConfigurationFile(string configurationFile)
{
    if (string.IsNullOrEmpty(configurationFile))
        throw new ArgumentException(Resources.ExceptionStringNullOrEmpty, "configurationFile");

    if (!File.Exists(configurationFile))
    {
        throw new FileNotFoundException(
            string.Format(
                CultureInfo.CurrentCulture,
                Resources.ExceptionConfigurationLoadFileNotFound,
                configurationFile));
    }

    return
        Path.IsPathRooted(configurationFile)
            ? configurationFile
            : Path.Combine(AppDomain.CurrentDomain.BaseDirectory, configurationFile);
}

A proposed fix is already available at CodePlex but it implies to modify the source of EntLib yourself and live with a home, recompiled version of EntLib. That directly means supporting another dependency which is something I don’t want.

Here is the link to the CodePlex page:
FileConfigurationSource::GetRootedCurrentConfigurationFile throws FileNotFoundException on relative path configuration file name

For us, it means that we can’t use Enterprise Library Configuration Sources until this bug is fixed. But… there’s a solution to keep the benefits of having the block configuration in external files. The solution resides in .Net and have been around for a while now: configSource! What we did is use the configSource attribute to point to external files for the desired Enterprise Library sections.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <configSections>
        <section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="true" />
        <section name="exceptionHandling" type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration.ExceptionHandlingSettings, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="true" />
	</configSections>
	<loggingConfiguration configSource="configs\entlib-logging.config" />
	<exceptionHandling configSource="configs\entlib-exception.config" />
</configuration>

This way we can keep the advantage of having our configuration outside the App.config/Web.config until this bug is fixed.

Note: One thing to keep in mind though… You cannot tell multiple configSource to use the same file. This is why I have entlib-logging.config and entlib-exception.config declared in my web.config.

Tags: enterprise library, configuration, bugs

Here at Orckestra, Commerce Server is an important part of our offering. Evidently, any new release of Commerce Server is analysed and validated against any of our solutions. In this process, We have discovered a very important bug in the new Commerce Server 2009.

Most of our solutions depend on the Free-Text search capabilities of Commerce Server. In this optic, I tried creating a simple search using the API:

var query = new CommerceQuery<CatalogEntity, CommerceCatalogFullTextSearchBuilder>(); 
query.SearchCriteria.Catalogs.Add("My_Catalog"); 
query.SearchCriteria.FirstItemIndex = 0; 
query.SearchCriteria.FullTextSearchType = CommerceFullTextSearchType.FreeText; 
query.SearchCriteria.NumberOfItemsToReturn = 500; 
query.SearchCriteria.Phrase =”My Criteria”; 

query.SearchCriteria.ReturnTotalItemCount = true; 
query.SearchCriteria.WhereClause = "[Active] = 1"; 

As it turns out I was constantly getting an unknown error. Digging through the code and using the SQL Profiler I discovered this line in the [dbo].[ctlg_GetFTSQuery] stored procedure of the catalogue database:

IF @IsVirtualCatalog = 1 or @SQLClause < 1 or (CHARINDEX(N'CONTAINS',@SQLClause) = 0 ) 

where @SQLClause is defined as an nvarchar(MAX). Well, @SQLClause < 1  is wrong and should then read: LEN(@SQLClause) < 1

So in that regard here is the entire line:

IF @IsVirtualCatalog = 1 or LEN(@SQLClause) < 1 or (CHARINDEX(N'CONTAINS',@SQLClause) = 0 ) 

Please remember that this bug is in the RTM so I would advise you to fix immediately or any Free-Text search will fail if it contains a where clause. Here is Microsoft’s official response by the way on the Connect site:

Hello David,
Thanks for reporting this. We have identified it is indeed a product defect.
As you already mentioned here, there is a syntax error inside ctlg_GetFTSQuery. Your suggested fix is correct and probably you have already done such modification from your side.
Unfortunately, the same error is also inside RTM release. We are building official fix for this problem. Please contact Microsoft CTS (Commercial Technical Support) for the official fix.
Thanks
Hao

Tags: commerce server, commerce server 2009, bugs