Adding custom configSections to BTSNTSvc.exe.config

Here's one from Oleg -

Be careful adding custom conifgSection to BTSNTSvc.exe.config file: it must be the first child of the root element.

Otherwise application host instance fails to start with the strange error:

Event Type: Error
Event Source: BizTalk Server 2006
Event Category: BizTalk Server 2006
Event ID: 5410
Date: 09/11/2006
Time: 14:33:12
User: N/A
Computer: A10944
Description:
A failure occurred when executing a Windows service request.

Service request: Start

BizTalk host name: BizTalkServerApplication
Windows service name: BTSSvc$BizTalkServerApplication

Additional error information:
Error code: 0xc0c0153a
Error source: BizTalk Server 2006
Error description: A BizTalk subservice has failed while executing a service request.

Subservice: Tracking
Service request: Start

Additional error information:
Error code: 0x80131534
Error source: Microsoft.BizTalk.Bam.EventBus
Error description: The type initializer for 'System.Data.SqlClient.SqlConnection' threw an exception.

not very helpful one.

the interesting point is that it seems BizTalk 2004 (or is it visual studio? or the .net framework?) was much more descriptive as I've noticed from the following blog post -
http://biztalkblogs.com/deepakl/archive/2005/09/26/31.aspx

passing 'in' parameters between orchestrations

It seems that there is no real distinction between an 'in' parameter and 'ref' paremeter of an orchestration when it comes to objects.

When you pass in an object from 'orchestration A' to 'orchestration B' as a parameter and 'orchestration B' changes a property of that object, when it finished the object in 'orchestration A' is left with the modified property.

Had this been .net it would have been perfectly expected, what confused me is that when you define your parameters for an orchestration you are asked to choose between 'out', 'ref' and 'in' parameter type, having 'out' and 'ref' in that list suggested, in my mind, that 'in' represents a 'by value' parameter which means changes to the object in the called orchestration will have no effect on the calling orchestration's copy of that object, but as I've said - this does not seem to be the case

Logging application blog configuration error

We're using the logging application block as a basis to a tracing and logging service across our solution.

As always the application block is driven by configuration sections in config files.

Today I got an error similar to this one -

"The configuration for TraceListener named Trace Listener A is missing from configuration."

I've briefly checked the configuration file and didn't find a problem in my source or listener.

What I did find strange was that I did not used to so called Trace Listener A in the bit of code I was running but another trace listener.

A closer look at the config file (through the skilled eyes of Ben here) revealed the problem - another source had that listener configured but had a leading space in its name.

I did not expect the application block to check the validity of the entire config section, but assumed it only looked at the bits required for the current execution i.e. the trace source and corresponding trace listener, but that is not the case.