How to reduce Enterprise Library 5.0 Logging memory usage? - c#-4.0

Question

I am using enterprise logging 5.0 within a .net 4.0 console application. I notice very high memory usage within my application. I was able to determine that the cause was due to the following call:
var logWriter = EnterpriseLibraryContainer.Current.GetInstance<LogWriter>();
After some profiling and manual testing with a simple console application, I was able to determine that memory usage drop from 45mb to 10mb when the following dlls were removed from the execution folder:
Microsoft.Practices.EnterpriseLibrary.Validation.dll
Microsoft.Practices.EnterpriseLibrary.Data.dll
The log initialization is my first call to Enterprise library apis. My console application does not make any calls to the Data.dll and Validation.dll. They exist in my execution folder, because they are references for other class libraries and our deployment setup.
I am assuming that EnterpriseLibraryContainer.Current is initializing based on what is found in the execution folder. I tried creating my logwriter with the following but I got the same result:
var configSource = new FileConfigurationSource(configPath);
var logWriterFactory = new LogWriterFactory(configSource);
var logWriter = logWriterFactory.Create();
Is it possible to initialize a logwriter without increasing the memory usage with the validation and data dlls present in the execution folder?
UPDATE:
So after some debugging within the entlib source. I believe the following is finding the dll and instantiating the Validation.dll, and Data.dll, despite not being referenced at all in the project.
From EntLib50Src\Blocks\Common\Src\Configuration\ContainerModel\TypeLoadingLocator.cs
private IEnumerable<TypeRegistration> GetRegistrationsInternal(IConfigurationSource configurationSource,
Func<ITypeRegistrationsProvider, IConfigurationSource, IEnumerable<TypeRegistration>> registrationAccessor)
{
Type providerType = Type.GetType(Name);
if (providerType == null) return new TypeRegistration[0];
var provider = (ITypeRegistrationsProvider)Activator.CreateInstance(providerType);
return registrationAccessor(provider, configurationSource);
}
the call to Type.GetType(Name) looks in the Executing Assembly location, which seems to be the reason why it registered the entlib data access.
After Debugging further my original application which contains connection strings with Oracle ODP.net Providers. (which I failed to mention from the start)
(my current application execution makes no calls or references to data access, connection strings are defined because application uses dynamic calls to other dlls which need connection strings., but for my test I am not invoking any of those calls)
Since Microsoft.Practices.EnterpriseLibrary.Data.dll is found, EnterpriseLibrary continues default registration of types for dataaccess and I found that the following call is the cause for the huge memory spike:
\EntLib50Src\Blocks\Data\Src\Data\Configuration\DatabaseSyntheticConfigSettings.cs
private static DbProviderMapping GetDefaultMapping(string dbProviderName)
{
// try to short circuit by default name
if (DbProviderMapping.DefaultSqlProviderName.Equals(dbProviderName))
return defaultSqlMapping;
if (DbProviderMapping.DefaultOracleProviderName.Equals(dbProviderName))
return defaultOracleMapping;
// get the default based on type
var providerFactory = DbProviderFactories.GetFactory(dbProviderName);
if (SqlClientFactory.Instance == providerFactory)
return defaultSqlMapping;
if (OracleClientFactory.Instance == providerFactory)
return defaultOracleMapping;
return null;
}
The DbProviderFactories.GetFactory(dbProviderName) call when dbProviderName=Oracle.DataAccess.Client.OracleClientFactory causes the huge memory spike.
So looks like the reason for the huge memory spike was due to odp.net and the fact that its registering DBFactories.
It seems like I cannot create a logger without registering everything present in the executing assembly location. Ideally I would like to not register data access unless its explicitly told to.

Answer 1

The fact that ODP.NET is being used as the underlying provider is the main reason for the memory spike, and the GetDefaultMapping will return null anyways. The following change could be made:
private static DbProviderMapping GetDefaultMapping(string dbProviderName)
{
// try to short circuit by default name
if (DbProviderMapping.DefaultSqlProviderName.Equals(dbProviderName))
return defaultSqlMapping;
if (DbProviderMapping.DefaultOracleProviderName.Equals(dbProviderName))
return defaultOracleMapping;
if (dbProviderName != "Oracle.DataAccess.Client")
{
// get the default based on type
var providerFactory = DbProviderFactories.GetFactory(dbProviderName);
if (SqlClientFactory.Instance == providerFactory)
return defaultSqlMapping;
if (OracleClientFactory.Instance == providerFactory)
return defaultOracleMapping;
}
return null;
}
This still doesn't explain why Oracle.DataAccess.Client uses so much memory for :
DbProviderFactories.GetFactory(dbProviderName);
as well as to why its registering the data access with the container.