Environments / MergedConfiguration - override CategorySource = (none) ??

Topics: General discussion, Logging Application Block
Jun 3, 2009 at 8:33 PM
Edited Jun 3, 2009 at 8:39 PM

Ive setup an MSMQ configuration as we are moving from 1 server to a Farm (and I dont want to track down logfiles on each machine in the farm)... The MSMQ is working great but Im trying to integrate to keep the various entlib.config files synchronized is very tedious (i.e. WebService -> MSMQ Listner, MSMQ Service -> Actual Listener).

I thought that Environments would be perfect for this but I need to be able to allow multiple Listeners on the MSMQ Service .config.
I attempted to create Listeners in the 'source' config and override them to '(none)' where not desired (the editor will allow you to enter '(none)' by hand) but when merging it complains and leaves the 'referenced' listener instead of overriding.

How can I accomplish the Config File "Morphing" I desire without managing by hand (UG!) ???:

  WebService(s)
MSMQ Service
Category Critical  ----> Critical
  Listener   MSMQ     Rolling Flat File
  Listener  
    Event Log
  Listener  
    DataBase
  Listener  
    Custom
Jun 4, 2009 at 10:00 AM

I think I dont fully understand your scenario. Can you please explain a bit more? Also, what is your goal for overriding the tracelistener to '(none)'. Is the 'source' that you are saying the config from your webService?

Valiant Dudan
Global Technology & Solutions
Avande, Inc.
entlib.support@avanade.com

Jun 4, 2009 at 5:47 PM
Edited Jun 4, 2009 at 5:49 PM

I think the Scenario of having "Many Applications writing to a Single MSMQ TraceListener" (*..1) and then the "MSMQ Server output to Many TraceListeners" (1..*) would be a very common situation... Im attempting to use Environments and MergeConfig to minimize the amount of manual config file synchronization I have to do as the config file(s) evolve but maybe I am going about it the wrong way??

So, My goal is to minimize having to keep .config files in 'sync' between my services and the msmq recipient. The need for different config files is that all the services/applications log everything to a single listener: MSMQ, but the MSMQ service has to then take those and write them out to actual destinations i.e.: WebService  *..1   MSMQ TraceListener --> MSMQ Server/Service 1..*  TraceListener (database, eventlog, etc)

My first attempt of using Environments failed because I cannot ADD new Listeners with an Override (i.e. override the MSMQ Listener with a Database, FlatFile, EventLog, Etc for the MSMQ  1..*  TraceListener)

So, I tried to Create ALL Listeners I wanted in the source.config and override them to '(none)' in the WebService(s) Environment, but KEEP them (dont override to none) in the MSMQ Environment -- again, this failed due to a MergeConfig exception about listeners being set to null

I look forward to all comments/suggestions :)


Jun 5, 2009 at 3:22 AM

So basically your problem is overriding a tracelistener with several tracelisteners in an environment, am I right?  I'm afraid this feature is not included in Environmental Overrides.  You can have your config for the MSMQ environment by simply specifying Don't Override Properties on the tracelisteners but for the WebService environment, the only option for you is to manually edit the config file.

 

Sarah Urmeneta
Global Technology & Solutions
Avande, Inc.
entlib.support@avanade.com

Jun 19, 2009 at 5:48 PM
Edited Jun 22, 2009 at 3:38 PM

I was able to resolve this by creating a custom "null trace listener" which did nothing. I then setup multiple trace listeners which used this new custom type.
I can now have many merge configurations, each with varying numbers of trace listener references (in categories/exceptions) by either overriding the 'null' listener with a functional one, or overriding a functional one with the 'null' listener. The best part is that I am now able to 'mesh' this in with the build processing using the Pre/Post-build events and configuration names (i.e. $(ConfigurationName) = Debug|ReleaseQA|Release ). Also, in doing so I can maintain the capability of 'mergeConfiguation' in all its goodness (i.e. overriding specic values on particular items, not just trace-listeners types) which would be much more tedious to maintiin by hand over 6 different projects (and growing) which share a base entlib.config. This ability will greatly reduce chance of mis-configuration by my team as each developer takes various stages of the overall solution thru the SDLC leading to fewer headaches for all of us! :)

Example(s):

Default Entlib.config:
  Category = Critical
     Listener1 = Null0
     Listener2 = Null1
     Listener3 = Null2

-----------------Project = ServiceA -----------------
Debug ServiceA.Entlib.config (.dconfig):
  Category = Critical
     Listener1 = DebugMSMQDistributor (localhost)
     Listener2 = Rolling Flat File                  <-- 'added' listenter by overriding 'null' to a functional one
     Listener3 = Null2

ReleaseQA ServiceA.Entlib.config (.dconfig):
  ...

Release ServiceA.Entlib.config (.dconfig):
  Category = Critical
     Listener1 = ReleaseMSMQDistributor (server host)
     Listener2 = Null1
     Listener3 = Null2

-----------------Project = ServiceX -----------------
  ....

-----------------Project = MSMQDistributor -----------------
Debug MSMQ.Entlib.Config (.dconfig)
  Category = Critical
     Listener1 = Rolling Flat File
     Listener2 = Null1
     Listener3 = Null2

ReleaseQA MSMQ.Entlib.Config (.dconfig)
  ...

Release MSMQ.Entlib.Config (.dconfig)
  Category = Critical
     Listener1 = Database
     Listener2 = Email            <-- 'added' listenter by overriding 'null' to a functional one
     Listener3 = Eventlog       <-- 'added' listenter by overriding 'null' to a functional one

 

These examples only show 'adding' a listener but you can also perform the opposite (functional -> 'null' replacement).

Also, the 'base' Entlib.config and all .dconfig files are kept together within a project in the solution, then, In a pre-build event of a specific project I call the MergeConfiguration and apply the appropriate .dconfig (i.e. Debug.ServiceA.dconfig) and emit the merged result to a config within the project being built ($(SolutionDir)Util\MergeConfiguration.exe $(SolutionDir)DriverTech.CommonConfig\Entlib.config $(SolutionDir)DriverTech.FWAPI.AdminService\$(ConfigurationName)MSMQ.Entlib.dconfig $(ProjectDir)app.config)

 

Jun 21, 2009 at 3:19 AM

That was a good workaround, didn't think of that.  Thanks for sharing to the community!

 

Sarah Urmeneta
Global Technology & Solutions
Avande, Inc.
entlib.support@avanade.com