Okay, it appears that the re-start of the host, everytime you change the BTSNTSVC.exe.config file is key (one would think thats obvious... isnt that the way almost all of .NET works !!!).
I went back over the stuff step by step, removed the sections i had put into the BTS config file, leaving them in the App Domain config file, taking care to restart the host every time and the logging continued working. Finally it even got to the point where it didnt need the IgnoreSectionHandler line to work. I also found that the mirror log file on disk was being created on C: cos I had forgotten to update the loggingDistributionConfiguration.config file. Changed that to D (my environment needs stuff to be on D:) and it worked fine.
Thanks to Andy Morrison for a useful article. Now to try the data block. oohh..shiver me timbers.. that should prove to be a challenge.
If Metallica were coders that would have been the title of their first album, instead of Kill 'em all.
I finally won one battle with Enterprise Library. I uninstalled the Jan version, the hands on labs, the June version, everything and installed just June 05 and the Hands On Labs. Lo and behold, the logging exercise started working. Why? I havent the foggiest. It could be because of some clashes with the Jan version, but then again, i dont know why that would arise. One thing that strikes me as a possible factor is a line in the app.config which has an "IgnoreSectionHandler" presumably telling the framework not to look for the loggingConfiguration element inside the config file but to go for a separate file.
The second battle, BizTalk and Ent Lib is sort of won. I say 'Sort of' because it appeared to work a couple of hours ago when it shouldnt !! Let me explain.
I took Andy Morrisons sample for Ent Lib logging. Andy uses a technique of marking his assembly as belonging to a separate AppDomain and setting the config file for that AppDomain which functions just like a regular app.config file and from there it points to the loggingConfiguration and loggingDistributorConfiguration files (usually in the same folder)
(a) I tried it out, straight from the can, but my old bugbear appeared, saying "the section loggingConfiguration could not be found in the BTSNTSVC.exe.config or the machine.config"
(b) Next, I got rid of the old Ent Lib projects from his solution to avoid any PublicKey or version clashes. I set a reference to my Ent Lib DLLs' which had just been strong named. No luck. Same message
(c) Then I added the "IgnoreSectionHandler" line into the configSections element of BTSNTSVC . Again, no luck.
(d) Finally, in desperation i copied the entire contents of the dll.config (the config sections, the pointers to loggingConfiguration etc) ans pasted it into BTSNTSVC.exe.config, re-started the host and... whaddya know... it logged something to the event log.
I left it at that stage, rejoicing that it finally worked. After a while though, sanity prevailed. HOW CAN IT POSSIBLY WORK? The thing is, even if it read the stuff i pasted in, there is no loggingConfiguration file in the BizTalk program files folder so it cant have found the instructions from there.
That leaves me with only two options
(a) there must be some default logging setup in EntLib to direct stuff into the event log (or)
(b) the host re-start was the one which did the trick. It read through my stuff, went past it, read the AppDomain thingy and worked as Andy had intended it to.
Very strange indeed. I need to test that out again tomorrow. One thing which didnt happen is that a log text file which should have been a replica of the event log messages, didnt appear as the documentation was expecting it to. I'll see if i can adjust the loggingConfiguration and add that sink in. That might do the trick.
I'll keep y'all posted. If that works, then i can move on to the Data block. Soon I will become a 'block'head :-)
If there isnt one yet, there should be, namely,"Thou shalt study ALL the samples that Microsoft has given thee".
Strewth! I found a SchemaResolver component in the SDK samples that matched my requirements 99%. It demonstrates a technique where we can peek into the contents of the message and dynamically select a schema from a list based on what we find. In the specific case of the sample, the first two characters of the message determined which schema, but of course this can be changed to whatever logic is applicable to us.
Initially before finding the sample, i was playing around with SchemaWithNone() and found that the answer to my own question yesterday namely "what does the SchemaFromType() method [demonstrated in Gilles weblog" return? is "STRING". Thats very strange. Dont know why it didnt even compile first time around. Once i managed to change the DocumentSchema, i got a little stuck since i had written the code in the Disassemble method and didnt know exactly how to call the flat file disassembler to continue its execution. As a result, the ouput of the pipeline was in the same native format that it arrived! Anyhow, alls well that ends well.
To summarise, Its a common requirement to have multiple flat files (of different schemas) arriving at the same location, or have multiple recieve locations being handled by the same pipeline. In order to pick up the corresponding schema, there are two methods
(1) Stick a series of FF Disassemblers in the Disassemble stage. BTS will utilise a probing technique and find out which one to use (This is quoted direct from the SDK document. I need to test this out)
(2) Probe the message and find out which schema to use. Create a SchemaWithNone("ResultSchemaName") object and assign it to the DocumentSchema. [If you use the Pipeline Component Wizard, which is really awesome, it will create a disassembling component for you and SchemaWithNone can be set as one of the design time properties"]. Once you have assigned the schema, dont forget to call the disassembler. Take a look at the SDK sample or Gilles post on "selecting a flat file schema dynamically" , for code blocks that achieve this.
Just to add one more thing and reinforce what I said earlier, the Pipeline Component Wizard is really neat. Great work Martijn.