1
A
回答
1
我用的就是登錄到兩個服務器和客戶端的技術。你可以通過一個入口點，一個Log類和許多靜態方法來實現，或者如果你願意的話可以使用單例。這可以配置爲只執行客戶端日誌記錄，只是服務器，兩者都不是。
客戶端日誌就可以誘導對話框，其中完整堆棧跟蹤可在一個toggle'able文本框顯示在非恐慌。這顯然允許在Web服務停止或中斷時捕獲異常。它還可以讓用戶複製堆棧跟蹤併發送給你，如果他們特別憤怒。
儘管服務器日誌記錄功能（例如Log4Net）功能更強大，它爲日誌記錄提供了更多選項，包括電子郵件警報，但它確實依賴於您能夠爲特定人員找到例外情況，這需要額外的搜索工具或在事件日誌的情況下的知識。
在我看來，增加客戶端日誌記錄功能是一個值得追加的功能。
1
我通常不喜歡僅僅依靠Silverlight來顯示以有意義的方式錯誤給客戶端（即「問題加載數據......」）。相反，我更願意包裝異常，並通過WCF服務通過一個公開的方法回調我的服務器，以接受Silverlight異常作爲參數。一旦在服務器上，您可以將其記錄到事件日誌，文本日誌，電子郵件到支持組等。
這裏真正的關鍵是要從客戶端獲取該異常，並將其傳遞到要處理的服務器上最好的和最傳播的方式。
「其中完整堆棧跟蹤處於toggle'able文本框可用。」選擇此選項時要非常小心。如果您在控制的Intranet應用程序中提到SL控件，那麼您應該沒問題。但是，如果這是在互聯網上暴露的SL控制，則顯示堆棧跟蹤可能是安全風險。關於可能暴露代碼內部結構的異常，您不想放棄任何細節。 – atconway 2010-09-13 13:08:36
@Atconway他們可以將XAP解壓縮並反射回來:) – 2010-09-13 18:20:45
確實如此，但是使用反射器解壓縮.zap文件不會給你「插入到MyTableName失敗。沒有這樣的參數@UserID at MyServiceDALMethod.Save字符串Val1，StringVal2）「全部在一條消息中。此外，如果客戶端上有真正的祕密，代碼可能會被混淆以幫助防止使用反編譯器。我認爲大家的共識是「不」向客戶展示完整的堆棧跟蹤，除非您正在測試等。 – atconway 2010-09-14 12:29:54