除了啟用設定中的追蹤來收集由 Windows Communication Foundation (WCF) 產生的檢測數據之外，您也可以透過程式碼在使用者程式碼中產生追蹤。 如此一來，您可以主動建立檢測數據，以供稍後用於診斷用途。 本主題討論如何執行這項作。
此外， 擴充追蹤 範例包含下列各節中示範的所有程序代碼。
建立追蹤來源
您可以使用下列程式代碼來建立使用者追蹤來源。
TraceSource ts = new TraceSource("myUserTraceSource");
建立活動
活動是處理邏輯單元。 您可以為每個主要處理單位建立一個活動，將追蹤資料分組在一起。 例如，您可以為每個對服務的要求建立一個活動。 若要這樣做，請執行下列步驟。
將活動標識碼儲存在範圍中。
建立新的活動標識碼。
從範圍中的活動傳輸到新的活動，在範圍中設定新的活動，併發出該活動的開始追蹤。
下列程式代碼示範如何執行這項作。
Guid oldID = Trace.CorrelationManager.ActivityId;
Guid traceID = Guid.NewGuid();
ts.TraceTransfer(0, "transfer", traceID);
Trace.CorrelationManager.ActivityId = traceID; // Trace is static
ts.TraceEvent(TraceEventType.Start, 0, "Add request");
在用戶活動中生成痕跡
下列程式碼會在使用者活動內產生追蹤記錄。
double value1 = 100.00D;
double value2 = 15.99D;
ts.TraceInformation("Client sends message to Add " + value1 + ", " + value2);
double result = client.Add(value1, value2);
ts.TraceInformation("Client receives Add response '" + result + "'");
停止活動
若要停止活動，請移回舊活動、停止目前的活動標識符，以及重設範圍中的舊活動標識符。
下列程式代碼示範如何執行這項作。
ts.TraceTransfer(0, "transfer", oldID);
ts.TraceEvent(TraceEventType.Stop, 0, "Add request");
Trace.CorrelationManager.ActivityId = oldID;
將活動標識碼傳播至服務
如果您在用戶端和服務組態檔中將追蹤來源的 屬性propagateActivity設定true為 System.ServiceModel ，則 Add 要求的服務處理會發生在用戶端中定義的相同活動中。 如果服務定義自己的活動和傳輸，服務追蹤就不會出現在客戶端傳播的活動中。 相反地，它們會透過傳輸痕跡與其中活動相關聯的活動中出現，該活動的標識碼是由客戶端傳播的。
備註
propagateActivity如果 屬性在用戶端和服務上都設定為 true ，則服務作業範圍中的環境活動是由WCF 設定。
您可以使用下列程式代碼來檢查活動是否在 WCF 的範圍內設定。
// Check if an activity was set in scope by WCF, if it was
// propagated from the client. If not, ( ambient activity is
// equal to Guid.Empty), create a new one.
if(Trace.CorrelationManager.ActivityId == Guid.Empty)
{
Guid newGuid = Guid.NewGuid();
Trace.CorrelationManager.ActivityId = newGuid;
}
// Emit your Start trace.
ts.TraceEvent(TraceEventType.Start, 0, "Add Activity");
// Emit the processing traces for that request.
serviceTs.TraceInformation("Service receives Add "
+ n1 + ", " + n2);
// double result = n1 + n2;
serviceTs.TraceInformation("Service sends Add result" + result);
// Emit the Stop trace and exit the method scope.
ts.TraceEvent(TraceEventType.Stop, 0, "Add Activity");
// return result;
追蹤程式碼中拋出的例外狀況
當您在程式碼中拋出例外狀況時，您也可以使用下列程式碼以警告層級或更高層級來追蹤該例外狀況。
ts.TraceEvent(TraceEventType.Warning, 0, "Throwing exception " + "exceptionMessage");
在服務追蹤查看器工具中檢視用戶追蹤
本節包含使用服務追蹤查看器工具 （SvcTraceViewer.exe） 檢視時，執行擴充追蹤範例所產生的追蹤螢幕快照。
在下圖中，在左面板中選取先前建立的「新增要求」活動。 它與其他三個數學運算活動 （Divide， Subtract， Multiply） 一起列出，構成應用程式用戶端應用程式。 用戶程式代碼已為每個作業定義一個新的活動，以隔離不同要求中可能發生的錯誤。
為了示範在 擴充追蹤 範例中使用轉移，也會建立一個包含四個操作請求的計算機活動。 對於每個請求，計算機活動與請求活動之間都會來回傳輸（在圖中右上方面板中，追蹤會被反白顯示）。
當您選取左面板上的活動時，此活動所包含的追蹤會顯示在右上方的面板上。 如果 propagateActivity 位於 true 要求路徑中的每個端點，則要求活動中的追蹤來自參與要求的所有進程。 在此範例中，您可以在面板的第 4 個資料行中看到來自客戶端和服務的追蹤。
此活動顯示下列處理順序：
用戶端會將訊息傳送至 Add。
服務會收到新增請求訊息。
服務會傳送新增回應。
用戶端會收到新增回應。
所有這些追蹤都是在資訊層級發出。 按一下右上方面板中的追蹤，會在右下方面板中顯示該追蹤的詳細資訊。
在下圖中，我們還看到與計算機活動相關的傳輸追蹤，包括每個請求活動的兩對開始和停止追蹤，一對來自用戶端，一對來自服務端（每個追蹤來源各一個）。
按建立時間的活動清單（左面板）及其巢狀活動（右上方面板）
如果服務代碼拋出一個例外狀況，導致用戶端也拋出例外狀況（例如，當用戶端未取得其要求的回應時），服務與用戶端的警告或錯誤訊息都會在同一個活動中發生，以便在同一個活動中直接關聯。 在下圖中，服務會擲回例外狀況，指出「服務拒絕在使用者程式代碼中處理此要求」。用戶端也會擲回例外狀況，指出「伺服器因內部錯誤而無法處理要求」。
下列圖像顯示，如果要求活動 ID 已經被傳播，指定請求在不同端點的錯誤將出現在相同的活動中。
在左側面板中雙擊 [乘法] 活動會顯示以下圖表，其中包含涉及每個進程的乘法活動追蹤。 我們可以看到第一次在服務發生的警告（拋出異常），緊接著在客戶端出現警告和錯誤，因為請求無法被處理。 因此，我們可以暗示端點之間的因果錯誤關聯性，並衍生錯誤的根本原因。
下圖顯示錯誤相互關聯的圖表檢視：
若要取得先前的追蹤，我們會針對ActivityTracing設置使用者追蹤來源和propagateActivity=true以及System.ServiceModel追蹤來源。 我們未將ActivityTracing設定為System.ServiceModel追蹤來源，無法啟用使用者程式代碼至使用者程式代碼的活動傳播。 （當 ServiceModel 活動追蹤開啟時，用戶端中定義的活動識別碼不會一路傳播至服務用戶程式代碼：不過，傳輸會將用戶端和服務用戶程式代碼活動與中繼 WCF 活動相互關聯。
定義活動和傳播活動標識碼，可讓我們跨端點執行直接錯誤相互關聯。 如此一來，我們可以更快速地找出錯誤的根本原因。