C＃跟蹤截斷長消息

Question

在C＃中，我啓用了跟蹤和網絡跟蹤源。

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
    <startup> 
     <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" /> 
    </startup> 
    <system.diagnostics> 
    <sources> 
     <source name="System.Net" tracemode="includehex" maxdatasize="1024"> 
     <listeners> 
      <add name="System.Net"/> 
     </listeners> 
     </source> 
    </sources> 
    <switches> 
     <add name="System.Net" value="Verbose"/> 
    </switches> 
    <sharedListeners> 
     <add name="System.Net" 
     type="TraceTest.StringWriterTraceListener, TraceTest" 
     initializeData="myfile.log" 
     /> 
    </sharedListeners> 
    <trace autoflush="true" indentsize="4" />  
    </system.diagnostics> 
</configuration> 

但較長的消息被截斷（長的很像12KB/30日線，沒多久就像1GB！），所以我在這裏唯一的網絡reqiest頭部的一部分被記錄的情況下結束。

如何解決這個問題？

還是你知道一本書或一些資源，解釋.net跟蹤和調試非常詳細？

日誌例如：

  System.Net Information: 0 : [1204] Connection#63291458 - Received headers 
     { 
     Transfer-Encoding: chunked 
     Connection: keep-alive 
     Keep-Alive: timeout=10 
     Content-Type: text/html; charset=windows-1251 
     Date: Mon, 04 Jul 2016 17:50:33 GMT 
     Set-Cookie: uid=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0,uid=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/,uid=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.zamunda.net,pass=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0,pass=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/,pass=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.zamunda.net,bitbucketz=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0,bitbucketz=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/,bitbucketz=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.zamunda.net,cats=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0,cats=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/,cats=deleted; 
expires=...}. 

這是一個消息，在不知何故TraceListenerWrite方法被稱爲絲毫該正被截斷單個消息做爲參數（「...}」結尾）

而且餅乾可怕的書面和幾乎是不可分析的，但我可以忍受......

呀，可悲的是從System.dlls篡改或使用一些奇怪的和複雜的類型繼承除了沒有太多成爲 完成。

Answer 1

你不會得到額外的數據。

你典型的例子是從名爲ParseResponseData的私有方法，它調用這個未來：

Logging.PrintInfo(Logging.Web, this, SR.GetString("net_log_received_headers", new object[] 
    { 
     this.m_ResponseData.m_ResponseHeaders.ToString(true) 
    })); 

內部密封靜態類SR與方法GetString是這裏的罪魁禍首。 net_log_received_headers資源字符串是收到的標題{{{0}}}。。 ILSpy顯示驗證碼：

public static string GetString(string name, params object[] args) 
{ 
    SR sR = SR.GetLoader(); 
    if (sR == null) 
    { 
     return null; 
    } 
    string @string = sR.resources.GetString(name, SR.Culture); 
    if (args != null && args.Length != 0) 
    { 
     for (int i = 0; i < args.Length; i++) 
     { 
      string text = args[i] as string; 
      if (text != null && text.Length > 1024) 
      { 
       args[i] = text.Substring(0, 1021) + "..."; 
      } 
     } 
     return string.Format(CultureInfo.CurrentCulture, @string, args); 
    } 
    return @string; 
} 

你注意到這片：

if (text != null && text.Length > 1024) 
{ 
    args[i] = text.Substring(0, 1021) + "..."; 
} 

你在它扔什麼都，這將改寫參數長度1024個字以內。

由於ResponseHeaders集合將其所有名稱/值寫入單個字符串，一旦將其交給SR.GetString，所有這些努力和內存都將浪費。

當SR.GetString參與日誌記錄時，您可能會將數據截斷。知道在哪裏發生這種情況的唯一方法是通過檢查組件或.Net Reference Source

當內部Logging類的Dump方法被稱爲在配置的maxdatasize設置使用。但是，您不必猜測數據是否被截斷，因爲它會告訴您在日誌文件中：

int maxDumpSizeSetting = Logging.GetMaxDumpSizeSetting(traceSource); 
if (length > maxDumpSizeSetting) 
{ 
    Logging.PrintLine(traceSource, TraceEventType.Verbose, 0, string.Concat(new string[] 
    { 
     "(printing ", 
     maxDumpSizeSetting.ToString(NumberFormatInfo.InvariantInfo), 
     " out of ", 
     length.ToString(NumberFormatInfo.InvariantInfo), 
     ")" 
    })); 
    length = maxDumpSizeSetting; 
}