VS.NET & CustomTraceListener

Topics: Logging Application Block
Aug 9, 2007 at 7:57 AM
Dear all,

I have tried to wrap a RollingFlatFileTraceListener as CustomTraceListener to specify additional attributes. It is the code we have

code
ConfigurationElementType(typeof(CustomTraceListenerData))
public class RollingUserAppDataFlatFileTraceListener : CustomTraceListener
{
private RollingFlatFileTraceListener _rollingFlatFileTraceListener;

public RollingUserAppDataFlatFileTraceListener(
RollingFlatFileTraceListener rollingFlatFileTraceListener)
{
_rollingFlatFileTraceListener = rollingFlatFileTraceListener;
}

public override void Write(string message)
{
_rollingFlatFileTraceListener.Write(message);
}

public override void WriteLine(string message)
{
_rollingFlatFileTraceListener.Write(message);
}
}
/code

However, we found that we cannot add this type of TraceListener to app.config with "EntLibConfig tool integration". I could not select the RollingUserAppDataFlatFileTraceListener for a "Custom Trace Listener".

Do you have any idea what I missed? And is there any sample for me to extend the CustomTraceListener without breaking the support offer by EntLibConfig tool integration?

Thanks and regards,
William
Aug 9, 2007 at 12:33 PM
Hi,

Is it possible you're building your trace listener using a set of assemblies (say, the unsigned) but using a different assembly set for the tool (say, the signed binaries)?

Btw, you will need to define a constructor with no parameters in order for the factory to build the trace listener for you, and you'll need to create the wrapped trace listener using the information from the "Attributes" collection that will be available for you after creation.

If your trace listener doesn't have extra behavior, you might be better off creating a new configuration object for it, with its matching design time support, and change the information that is fed to the existing RFTL on creation.

Regards,
Fernando
Aug 10, 2007 at 1:23 AM
Hi Fernando,

Yes. my trace listener actually does not have extra behavior. I have tried to create a new configuration object for it by extending the RollingFlatFileTraceListenerData. Unfortunately, the tool does not allow me to select our customized configuration object for the RollingFlatFileTraceListener. It seems that it has hard coded the relationship between the RollingFlatFileTraceListener and RollingFlatFileTraceListenerData.....

Thanks and regards,
William
Aug 10, 2007 at 1:27 AM
Hi Fernando,

One more question. As you mentioned, the factory creates the trace listener with zero-parameter constructor, while we only can get the configuration setting via the "Attributes" collection. Wonder whether those "Attributes" collection have been initialized properly at the constructor?

Thanks and regards,
William
Aug 10, 2007 at 1:37 AM
Hi,

Regarding the hard-coding, it shouldn't. You would need to add design time support for it though, i.e. a new node class mapped to your new configuration object.

And about the attributes, the answer is no. The constructor will always be executed before anything can be set on an object.

Fernnado
Aug 10, 2007 at 6:25 PM
Hi Fernnado,

Sorry for overlooking this possibility. May I know how can I add a new node class mapped for my new configuration object? Do you suggest me to modify EntLib's source code, or creating a new project for extending it? Appreciate if you can provide some hints to me. It will be much better if we do not need to touch EntLib's source code.

Regarding the attributes question, do you mean we should check the CustomTraceListener has been initialized properly with this Attributes on each public method it has? Is there any "Assembler" method it has for this purpose? Or, does it fire any event once its Attributes has been prepared? I wonder how can we know when the Attributes property has been initialized properly..............

Thanks and regards,
William
Aug 10, 2007 at 7:57 PM
Hi,


Sorry for overlooking this possibility. May I know how can I add a new node class mapped for my new configuration object? Do you suggest me to modify EntLib's source code, or creating a new project for extending it? Appreciate if you can provide some hints to me. It will be much better if we do not need to touch EntLib's source code.


Adding desing time support is not hard and it is extensible by design, but there are quite a few pieces that must fit together. You can take a look at this webcast from Brian Button http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032291158&CountryCode=US; it targets EntLib 2.0 but the concepts still apply and the implementation is probably very close to 3.1. You can also use the Application Block Factory for this. While it's not targeted to this specific scenario, you can use it to create a "throwaway" trace listener, remove the trace listener and update the references to the existing trace listener, and then add design time support; most of the code will be generated for you. I haven't tried it though (I tried but my GAX install is hosed after too much poking with it) but it should work.


Regarding the attributes question, do you mean we should check the CustomTraceListener has been initialized properly with this Attributes on each public method it has? Is there any "Assembler" method it has for this purpose? Or, does it fire any event once its Attributes has been prepared? I wonder how can we know when the Attributes property has been initialized properly..............


You'll have to check each time. The reason for this is that the block is expected to work with existing trace listeners. Most custom trace listeners implement their functionality after calling an EnsureXXX method to perform initialization.

Regards,
Fernando
Aug 13, 2007 at 8:29 AM
Hi Fernando,

Thanks a lot for the reference. It is very helpful.

BTW, do you think it is better to let developer extending CustomTraceListenerAssembler to customize the assemble process of CustomTraceListener? It looks that the EnsureXXX method should be in the Assembler instead of the CustomTraceListener.

Thanks and regards,
William
Aug 13, 2007 at 2:12 PM
Hi,

There are two factors here. First, the developer of a "custom" trace listener should only need to write the code for the trace listener itself; no configuration objects nor plumbing code like the assembler, and second, custom trace listeners should ideally work "as is" when configured in the system.diagnostics section for use with the standard .NET Trace API, so they shouldn't rely on anything that is not provided by the platform.

Regards,
Fernando