在Windows Azure中實現和調試一個WCF服務（下）

開啟診斷

對於我們來說，和診斷有關的大多數工作都已經完成了。但是一定要記住，我們必須要把“sharedListener”添加到 “AzureLocalStorage”中。要完成這個工作，只需在“WCF Web Role”的“Web.Config”檔案中交換一下被注釋掉的“system.diagnostics”節點就可以了，就是這麼簡單。

除此之外，你還必須把下面這行代碼添加到“WebRole.cs”檔案中：

DiagnosticMonitor.Start(CloudStorageAccount.DevelopmentStorageAccount, diagnosticConfig);

在使用SDK 1.3把日誌遷移到BlobStorage的過程中，我遇到了一個問題。這個問題和作為SVCLog被建立的檔案上的可用的許可權有關。針對這個問題，有兩種解決方案。首先，你可以模仿RobinDotNet（具體可以參考：http://robindotnet.wordpress.com/2011/02/16/azure-toolssdk-1-3-and-iis-logging/ ——我會在以後的文章中講述具體應該怎麼做的）的做法，或者，你也可以在“ServiceDefinition.csdef”中徹底地刪 除<Sites>節點，這意味著它將不再作為一個完整的IIS來運行。我選擇了第一種方法，在本文中我只是簡單地總結了一下，關於我是如何讓 它正常工作的，以後我會單獨寫一篇文章來說明的。現在，如果你無法解決這個SDK 1.3中的已知問題，你可以通過瀏覽它們的檔案路徑（使用Development Emulator）直接存取這些檔案，或者你也可以使用遠端桌面來訪問雲中的日誌。

如果你對立即可以使用的WCF的追蹤記錄檔比較好奇，你可以開啟附屬的項目，看看它是如何為你工作的——你可以把注意力放在 “FixDiagFolderAccess.ps1”這個powershell指令碼上。它為這個檔案夾建立了一些存取控制表，更重要的是，它會為這個檔案 建立一個NULL或者完全為空白的預留位置（我們最後會重寫這個檔案）。

它可以給你提供SVCLog的定義，其中包括了綁定和異常的所有細節。在這裡，你可以找到“DivideByZeroException”，然後開始診斷這個問題。

這個檔案首先會出現在硬碟上：

片刻之後（注意，在這篇博文中，這個時間沒有什麼暗示！），Windows Azure Diagnostics系統會把這個檔案遷移到blob storage的WAD-TraceFiles容器中。

在此之後，這個日誌可以被下載，用來檢查錯誤。在這個例子中，我們可以向下滾動，直到找到和被0除有關的細節，然後我們會發現有一個紅色高亮的行顯示發生了一個異常。要想查看更多的細節，我們可以從服務端擷取這個錯誤真正的堆疊追蹤資訊。

這篇博文的原始碼可以從如下地址下載：

http://assets.bareweb.eu/wp-content/uploads/2011/03/WCFBasic.zip