Logging

Logging

• Petunia

  Excellent. Thanks!

  Scott

  
  
  

• divs

  That's what I mean Scott, except that the bytes being sent are encoded as Base64 in the trace log. And, worse, the trace viewer doesn't appear to have a way to view the raw bytes (in hex) sent across the wire.

  On a related note, any idea why tools like the SOAP toolkit's trace utility and TCPtrace don't work with WCF Trying to proxy through these tools just results in an exception being thrown with message "The endpoint cannot process the message at this time." I guess these programs must be modifying headers or something and therefore WCF spits the dummy

  Thanks,
  Kent

  
  

• ghell

  Thanks Scott. For others searching for a solution to this problem, you can use the channelViaUrl behaviour on your client as follows:

  <endpoint address="http://localhost:4893/WebAppName/ServiceUrl.svc"
  behaviorConfiguration="clientBehavior" ...

  ...

  <behavior name="clientBehavior">
  <channelViaUri viaUri="http://localhost:8080/WebAppName/ServiceUrl.svc"/>
  ...
  </behavior>

  More info is available in these blog posts:

  • http://www.winterdom.com/weblog/2006/04/17/RedirectingThroughTcpTraceWithWSEAndWCF.aspx
  • http://pluralsight.com/blogs/aaron/archive/2006/04/17/21870.aspx

  Cheers,
  Kent Boogaart

  
  

• horatio05

  If you tell it to log at the transport layer, you will see all the encrypted/signed stuff in the envelope, untouched by the securitybindingelement. If you log at the message layer it will show you the decryted contents of the envelope. Is that what you mean

  Thanks,

  Scott

  
  
  

• Steven Jaques

  Hi,
  
  I have tried that, but like I said it logs in its own custom format - not the format that is sent across the wire. Unless I'm missing something
  
  Kent
  
  

• Robert Schroeder

  We used to have a problem in the WSE days when we used TCPtrace. My guess is that when you use TCP trace, you have to modify the client to send it to the tracer, and then the tracer tool will forward it on to the real server. This is all fine and dandy but the problem here is that the server may not be listening for the right enpoint if you do it that way. Let me explain....

  Your server is listening for traffic on http:\\localhost:8000\Myservice

  Your client is sending it's msg's to the same and all works well.

  So now you fire up your trace tool to listen at port 8001 and modify your client to send msg's to http:\\localhost:8001\Myservice.

  Once the msg is sent to the tool, it then forwards it on to the real server at http:\\localhost:8000\Myservice. This is the correct address but it still fails because when the client sent its msg it set the endpointaddress of http:\\localhost:8001\Myservice. This means that the <To> element is http:\\localhost:8001\Myservice which the server cannot handle.

  One workaround to this is to create a logical endpointaddress for the server and have the client send it TO the logical endpointaddress VIA the physical address of the trace tool. That way the <TO> element is what the server expects and it will be able to handle it. I hope that made sense.. ;>

  I have some simple sample code lying around somewhere that demos this. Let me know and I'll dig it up for you.

  This is just a guess about what's happening but it's based on several past experiences like this... ;>

  Thanks!

  Scott

  
  
  

• ruppuk

  Try looking here:

  http://blogs.msdn.com/madhuponduru/archive/2006/05/18/601458.aspx

  
  
• Logging