Register Application Blocks from DLL

Topics: Caching Application Block , Exception Handling Application Block, General discussion, Logging Application Block
Jun 25, 2008 at 2:35 PM

Greetings EntLib gurus,

We have an application that we are attempting to modify so that we can be hosted within another process.  As with most tasks there have been some integration issues but for the most part it has been relatively painless.  One area that we are having trouble with is the configuration file.  Unfortunately, in this particular case we are not being loaded in our own Application Domain so I cannot use that as a starting point.    Any of the appsettings I have been able by mapping my own configuration file using OpenMappedExeConfiguration().  But the reliance on the configuration file for the Enterprise Application Blocks has been a stumbling point.  I have seen that I can create my own logger to use to remove reliance on the static logger and am pursuing that as the solution to this problem.   I'm just a firm believer in that if it seems to be the most difficult way to do something then there is probably an easier way and I hope you can point out the errors of my way.
We have entries for the following types (mostly application blocks) that I am attempting to determine the best way to have recognized.
 
        Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings
        Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration.ExceptionHandlingSettings
        Microsoft.Practices.EnterpriseLibrary.Caching.Configuration.CacheManagerSettings
        Microsoft.Web.Services3.Configuration.WebServicesConfiguration
   
 
To summarize - we have moved from our being launched within our own executable to being launched as a DLL from another process and are attempting to identify a way that allows us to reuse the app.config that our executable used.  Or at a minimum some assurance that I am pursuing the correct course of action.
 
Thank you for any pointers or suggestions that you may have.
 
Michael Fischer
Jun 25, 2008 at 3:40 PM
Hi Michael,

For a typical provider, EntLib has static factory and an instance factory. For some blocks, it also has a static facade. The static factories, and transitively the facades that use them, use the default configuration source that comes from the standard .net configuration file. For the instance factories, you can use any configuration source you want, which means you can look for configuration on an arbitrary configuration file using the file configuration source.
Unfortunately, some of the blocks' features are provided by the facades, which means only the standard configuration file can be used with them; ExceptionPolicy is a typical example of this situation.

You could avoid using the existing facade and replace it with a new facade of your own. In ExceptionPolicy in particular, there are overrides that let you provide the instance factory for the policy objects but they are not public; you can base your own facade on the existing implementation while still getting your configuration from a separate file.

Hope this helps,
Fernando


mkfischer wrote:

Greetings EntLib gurus,

We have an application that we are attempting to modify so that we can be hosted within another process.  As with most tasks there have been some integration issues but for the most part it has been relatively painless.  One area that we are having trouble with is the configuration file.  Unfortunately, in this particular case we are not being loaded in our own Application Domain so I cannot use that as a starting point.    Any of the appsettings I have been able by mapping my own configuration file using OpenMappedExeConfiguration().  But the reliance on the configuration file for the Enterprise Application Blocks has been a stumbling point.  I have seen that I can create my own logger to use to remove reliance on the static logger and am pursuing that as the solution to this problem.   I'm just a firm believer in that if it seems to be the most difficult way to do something then there is probably an easier way and I hope you can point out the errors of my way.
We have entries for the following types (mostly application blocks) that I am attempting to determine the best way to have recognized.
 
        Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings
        Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration.ExceptionHandlingSettings
        Microsoft.Practices.EnterpriseLibrary.Caching.Configuration.CacheManagerSettings
        Microsoft.Web.Services3.Configuration.WebServicesConfiguration
   
 
To summarize - we have moved from our being launched within our own executable to being launched as a DLL from another process and are attempting to identify a way that allows us to reuse the app.config that our executable used.  Or at a minimum some assurance that I am pursuing the correct course of action.
 
Thank you for any pointers or suggestions that you may have.
 
Michael Fischer



Jun 25, 2008 at 3:49 PM
Fernando,

Thanks,  that is the path that I am taking.  I just saw this as an exercise that would involve creating a few new classes and writing a little bit of code.  My concern was that these changes would ripple down through all of the different component teams for the project so I didn't want to implement it and find out after the fact that there was some 2 line snippet that I could have used to accomplish the same task.  It is good to know that I am on the right path.

Thank you,

Michael Fischer