Thank you for your feedback. We removed the MessageWriterTraceListener because it is not part of the listeners shipped with the CLR. It may become one in the future. In the meantime, we included it in the WCF SDK as a sample listener for users who still want the multi-trace feature. You may use that sample to create your own custom listener.
Thank you Michele, for the message logging configuration section description.
Please continue to send feedback on the trace viewer and trace contents as it is very useful.
I had the same question and here's what I know. The September CTP no longer supports multiple file message tracing (meaning, each message is dumped to a file), but it does support configuration for message tracing as follows:
Now, here's the deal, in the latest bits (November) you will be able to see the full message in the trace log using svctraceviewer.exe...but in Sept. CTP from what I have seen I cannot get the trace viewer to show the entire message body, only headers.
Any reasons why the multi-file trace has been pulled out I sincerely hope this is an oversight ;).
Multi-file traces are great to show during demos and POCs. One look at it and one will be able to determine the number of bootstrapping calls. Since files are small, I do not have to worry about file bloat and big filestream r/w which is one thing I hated about how WSE does its tracing. Keeping that multi-file option together with the e2e option will be good and let each customer determine what is best for their scenario :)
<system.diagnostics> <sources> <!-- Add the Message Logging Trace Source so we can log to a specific directory --> <source name="IndigoMessageLogTraceSource" switchValue="Verbose"> <listeners> <add name="xml" type="System.Diagnostics.TextWriterTraceListener" initializeData="c:\OneBIGMonsterSOAPTrace.txt" /> </listeners> </source> </sources> <trace autoflush="true" /> </system.diagnostics>
I have been doing this way for some time now and it works well. I do have a XML tool that I use to parse the dumped messages, so all headers + body can be viewed in this tool. I really didnt like the svcTraceViewer tool at all since the first Indigo CTP drop. My view is that it is too cryptic for my liking :)
That listener has been moved to a sample. The diagnostics are a little different; the message logging source is "just another source" that can be used with any listener. In b2, the source is named System.ServiceModel.MessageLogging
Can you give a sample diagnostics configuration section that I would add to a web.config or an app.config file of a WCF client or service I'm using the September CTP release.
Txs for this post. It was really helpfull. I'm giving a session in TechDays and i couldn't make diagnostics work.
Michele, what's the source "System.ServiceModel.MessageLogging" in your example, is that a replacement for "IndigoMessageLogTraceSource" I Couldn't find that source in the Sept CTP...
I asked the same question. My take on it is, if multi-file trace can be easily configured with a custom extension, I'll be happy. Since messages can be viewed in the trace viewer (as of Nov I can see them) I'm happy with that too.
I'm getting more "comfortable" with the trace viewer the more I rely on it, but it still needs some work to make it easier to filter certain things. Like: I want to see only messages that were sent to/fro, or I want to filter for a specific datetime range, and maybe they could make it possible to open the XML message dump in a browser instead of showing in the limited viewscape of the tool...
WCFdiagnostics in the September CTP
lonskie1030
Hi,
Thank you for your feedback. We removed the MessageWriterTraceListener because it is not part of the listeners shipped with the CLR. It may become one in the future. In the meantime, we included it in the WCF SDK as a sample listener for users who still want the multi-trace feature. You may use that sample to create your own custom listener.
Thank you Michele, for the message logging configuration section description.
Please continue to send feedback on the trace viewer and trace contents as it is very useful.
Thanks,
Laurence Melloul
rdtcgriffin
I had the same question and here's what I know. The September CTP no longer supports multiple file message tracing (meaning, each message is dumped to a file), but it does support configuration for message tracing as follows:
Add this to your <system.servicemodel> section:
<diagnostics performanceCountersEnabled="true" wmiProviderEnabled="true" >
<messageLogging logEntireMessage="true" logMalformedMessages="true" logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true" maxMessagesToLog ="3000" />
</diagnostics>
Add this to your <configuration> section (this is just one example of how to dump message to a single log):
<system.diagnostics >
<sharedListeners>
<add name="sharedListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="c:\logs\tracelog.e2e" />
</sharedListeners>
<sources>
<source name="System.ServiceModel" switchValue="Verbose, ActivityTracing" >
<listeners>
<add name="sharedListener" />
</listeners>
</source>
<source name="System.ServiceModel.MessageLogging" switchValue="Verbose">
<listeners>
<add name="sharedListener" />
</listeners>
</source>
<source name="ApplicationLogging" switchValue="Information" >
<listeners>
<add name="sharedListener" />
</listeners>
</source>
</sources>
</system.diagnostics>
Now, here's the deal, in the latest bits (November) you will be able to see the full message in the trace log using svctraceviewer.exe...but in Sept. CTP from what I have seen I cannot get the trace viewer to show the entire message body, only headers.
DHolland
Any reasons why the multi-file trace has been pulled out I sincerely hope this is an oversight ;).
Multi-file traces are great to show during demos and POCs. One look at it and one will be able to determine the number of bootstrapping calls. Since files are small, I do not have to worry about file bloat and big filestream r/w which is one thing I hated about how WSE does its tracing. Keeping that multi-file option together with the e2e option will be good and let each customer determine what is best for their scenario :)
<diagnostics>
<messageLogging logEntireMessage="true"
maxMessagesToLog="300"
logMessagesAtServiceLevel="true"
logMalformedMessages="true"
logMessagesAtTransportLevel="true" />
</diagnostics>
<system.diagnostics>
<sources>
<!-- Add the Message Logging Trace Source so we can log to a specific directory -->
<source name="IndigoMessageLogTraceSource" switchValue="Verbose">
<listeners>
<add name="xml" type="System.Diagnostics.TextWriterTraceListener" initializeData="c:\OneBIGMonsterSOAPTrace.txt" />
</listeners>
</source>
</sources>
<trace autoflush="true" />
</system.diagnostics>
I have been doing this way for some time now and it works well. I do have a XML tool that I use to parse the dumped messages, so all headers + body can be viewed in this tool. I really didnt like the svcTraceViewer tool at all since the first Indigo CTP drop. My view is that it is too cryptic for my liking :)
But then again: Maybe it is only me :)
Risto Ylipaavalniemi
Jesse Towner
ccsfiona
Txs for this post. It was really helpfull. I'm giving a session in TechDays and i couldn't make diagnostics work.
Michele, what's the source "System.ServiceModel.MessageLogging" in your example, is that a replacement for "IndigoMessageLogTraceSource" I Couldn't find that source in the Sept CTP...
Txs
regards!
Sreeya
I'm getting more "comfortable" with the trace viewer the more I rely on it, but it still needs some work to make it easier to filter certain things. Like: I want to see only messages that were sent to/fro, or I want to filter for a specific datetime range, and maybe they could make it possible to open the XML message dump in a browser instead of showing in the limited viewscape of the tool...
Sailu
How would you configure a multi-file trace to output the files to a certain directory