在 twMVC#15 時，我以「開發的效能和效率」這個題目分享了幾個追蹤分析以及效能監控的工具，有些功能是 Visual Studio 本身就有提供，但是只有在 Ultimate 或 Enterprise 才有提供，而有些則是需要付費購買的第三方套件，看起來好像都需要先付出一筆費用之後才有辦法去做到詳細追蹤分析的事情，不過也並不是這樣，因為有很多人既使給他們用了最高開發等級的 Visual Studio，也還是有一堆功能根本不會用，而且可能還不知道有這些功能。
這一篇文章將會介紹一套免費及操作簡便的 .NET 應用程式分析工具「CodeTrack」，希望能夠為各位的開發與系統維護時有所幫助。
之前連著兩篇介紹了 NanoProfiler.Data 在 ADO.NET 與 Dapper 的專案裡的使用情境與安裝說明，而這一篇就接著介紹專案使用 Entity Framework 與 NanoProfiler 的說明。
上一篇「NanoProfiler 對於資料庫存取的監控 - ADO.NET」的最後有講到使用 ADO.NET 進行資料存取處理雖然可以使用 NanoProfiler 將程式的執行效能作監控，但是卻無法將執行的 T-SQL 內容給記錄起來，所以算是一個未完成品。
現在這一篇則是改用 Dapper 取代 ADO.NET 的操作，然後再使用 NanoProfiler.Data 去進行資料存取的監控並且將執行的 T-SQL 給記錄起來。
前一篇「使用 NanoProfiler 對 ASP.NET Web API 進行性能監控」介紹了 NanoPrifiler 這個套件，讓我們可以在 ASP.NET MVC / WebAPI 或 WCF 等專案裡去監控程式執行的效能，因為是第一篇，所以只有簡單的說明怎麼在 Controller 類別的 Action 方法裡的使用方式，所以在 NanoProfiler 的 Profilering Result 頁面裡只有呈現 Controller 的 Action 裡被 ProfilingSession 給包起來的程式執行數據。
很多人誤會說只要在某個地方用程式給包起來之後就會將有用到的所有程式效能數據都能夠抓出來，這…… 真的有點誤會了，其實 NanoProfiler 並沒有如此厲害，要是真的那麼厲害的話，這樣的程式也太恐怖了些，其實效能數據的監控並不是全部程式的執行效能數據都抓出來就可以讓我們了解程式的狀況，因為太多的數據呈現反而會失去焦點與意義，而是應該對於執行效能有疑慮或是要詳加注意的部分再去做監控就可以。所以 NanoProfiler 的效能監控是由我們來決定那些程式需要被監控，有需要監控的地方再去把程式給包起來就好。
這一篇來說明對於使用 ADO.NET 進行資料庫存取的 Repository 要如何使用 NanoProfiler.Data 去做到監控與執行 T-SQL 的記錄呈現。
在開發 ASP.NET MVC 網站的時候，我會使用 MiniProfiler 或 Glimpse 來監控每一個頁裡各種功能的執行性能，這在之前有寫了多篇文章作介紹，然後也在 twMVC#15 以「開發的效能與效率」這個 Session 裡也做了介紹和說明。但是到了開發 ASP.NET Web API 服務的時候，因為沒有頁面，所以也就無法使用 MiniProfiler 或 Glimpse 等工具去對每次的 API 執行去做監控，以致於就會相當仰賴 Log 記錄，在想要監控的程式片段去計算執行時間與寫入 Log，但是這樣的方式相當沒有效率，而且事後去查看 Log 也要當浪費很多時間才能把相關數據給整理出來。
在 2014 年底，我在 Nuget 的 Release 訊息裡發現了一個名為「NanoPrifiler」的套件，當時的介紹文章相當少，大概只有作者部落格裡的兩篇文章（第三篇文章還是到了 2015 年八月才發佈），而且我在 2014 年看到的時候還沒有放在 Github 分享出來（原本一開始有放在 Github 上，但是後來又關閉，現在已經重新公開），一開始我是被他的介紹與文章說明給吸引，直覺這個套件就是我所想要的，所以花了一點時間去研究，接著在 2015 年初就全面導入到專案開發裡，甚至於之後公司裡幾個後續所開發的 ASP.NET Web API 專案也都導入使用 NanoProfiler。
在 2015 年 12 月裡所舉行的 twMVC#21，我在主講的「以實例說明 ASP.NET Web API 服務的開發與測試過程」裡就有將 NanoProfiler 介紹給大家，而到了現在才有時間將使用、安裝的說明給整理出來，所以將會有一系列的文章說明如何使用 NanoProfiler。
無論是 ASP.NET WebFroms or MVC or WebApi，我都會在專案裡安裝使用 Elmah 來攔截紀錄例外錯誤，這個部落格裡也有很多篇文章在說明，Elmah 這套件真的是一個歷史悠久的工具，早在 2004 年就已經出現了，但是我真的很意外居然蠻多人是聽都沒有聽過，甚至有許多人是不懂為何要來攔截記錄錯誤（我就完全不懂這些人是如何知道網站發生了什麼例外錯誤，而且怎麼去做分析與修復？），有些團隊雖然沒有使用過 Elmah 而是選擇自己建立錯誤處理機制或是使用其他的錯誤攔截記錄機制，不管如何，例外錯誤的處理是不能夠掉以輕心的，問題往往都能夠從這些有被紀錄的 Exception 裡去被發現。
雖然 Elmah 有提供一個基本的記錄顯示介面，可以讓我們看到有哪些 Exception 被記錄下來，但長久下來要在一大多的 Exception Record 裡去找出問題或是作分析就會是一大難題，因為這個基本的顯示介面是相當陽春的，如果有將這些記錄存在 SQL Server 裡的話，還可以在 SSMS 裡去下 T-SQL 做資料查詢，但是要要查個 Exception 紀錄還要開啟 SSMS 也是蠻累人的，尤其是有些團隊的環境裡是不允許開發人員直接連接正式環境的 SQL Server，所以就無法使用 SSMS 去做查詢了。
如果有將 Elmah 所攔截的例外錯誤給存放到「SQL Server」的團隊，這邊向你們介紹一個簡單方便的套件「ASP.NET MVC ELMAH Dashboard」
前不久在 feedly 裡看到訂閱的 Mikesdotnetting 部落格介紹了一個免費的 ASP.NET 監控工具「Prefix」，大致看了一下介紹，發現到這的確是個不錯的工具，所以就寫篇文章來做個簡單介紹。
這部落格也介紹了一些 Profile 的工具，例如 miniProfiler, Glimpse 等，但這個 Prefix 與前面所提的有什麼不同呢？看下去就知道。
在今年六月的時候，我有寫了一篇有關 ELMAH.MVC 2.0.0 的介紹文章：「Elmah.MVC 2.0.0」，其中討論了有關 Elmah Dashboard 瀏覽路徑的設定問題，原本 Elmah.MVC 2.0.0 不能夠讓我們自己去設定瀏覽路徑，而我也到作者的 Blog 中向他反應這個問題，但是作者的回覆說，基於「security by obscurity」以及加入瀏覽權限設定並且只限定 local 讀取 Elmah 就不需要擔心，不過在 2012-08-16 所更新的 Elmah.MVC 2.0.1，在這個版本裡就增加了可以自行定義瀏覽路徑的設定，另外也針對 VB.NET 使用 Elmah.MVC 時所發生的錯誤也做了修正（由 KKBruce 向作者提出），接下來說明一下有關自行定義 Elmah Dashboard 瀏覽路徑的設定與該注意的地方。
這是 2012-06-14 twMVC 「攻略 ASP.NET MVC - 從無到有 與 偵測監控」研討會中由我所主講的題目，講題的內容包含了有關網站監測與 Log 記錄的工具介紹與使用：
ELMAH
NLog
Log Reporting Dashboard
在這裡將簡報檔以及講題所使用的範例程式檔案做整理，並且列出相關的資訊。
twMVC 在 2012-06-24 所舉辦的「攻略 ASP.NET MVC - 從無到有 與 效能剖析」研討會中，我所主講的「ASP.NET MVC 偵測監控與 Log 記錄」這個主題內容裡，除了有介紹 ELMAH 與 NLog 之外，在最後的一點時間裡有提到一個整合 Log 記錄的模組，這個模組就是「Log Reporting Dashboard」，其實原本主題說明裡給予 Log Reporting Dashboard 說明介紹的時間就只有一點點，只是向在場的研討會參加者介紹有這麼一個 ASP.NET MVC 網站模組可以用來整合顯示各個 Log 機制的記錄，而當時講完 ELMAH 與 NLog 之後的時間也所剩無幾，所以對於 Log Reporting Dashboard 就只能走馬看花的介紹，所以在這邊就寫一篇文章來稍微詳細的介紹。
為什麼要把 NLog 的 Log 記錄給儲存在 SQLite 中呢?
因為有時候我們所建置的網站資料庫環境並非那麼容易就可以讓我們建立一個 Database 或是 Table，有的公司或是有的環境，對於資料庫的管理會相當嚴謹，凡是要建立一個新的 Database 或是 Table 都需要層層關卡，甚至於會因為提出的申請需求不明確或是他們覺得沒必要而駁回。
雖然說把 Log 記錄儲存成一個個的文字檔案也是可以，但是事後的 Log 記錄的追查就不是那麼方便，甚至於如果想要自己建立一個瀏覽 NLog 記錄的功能網站或是導入使用 Log Reporting Dashboard，不把 Log 記錄給放到資料庫中是不太可行的，而把 Log 記錄給儲存到 SQLite 的話，在這樣資料庫嚴謹管控的情況下，使用 SQLite 就會是一個蠻適合的解決方案。
這一篇就說明如何將 NLog 的 Log 記錄儲存到 SQLite 中。
NLog 有支援很多不同的 targets，在 NLog 的首頁上有列出一些比較常用到的，
… and many more
其中比較常用到的應該是 Files, Database 以及 Email，不過 NLog 能夠支援的 targets 的清單如下：
http://nlog-project.org/wiki/Targets
而這些 NLog 所記錄的 Log 在我們 Debug 時還要去另外開啟資料庫工具或是開啟檔案、收信等，才能夠看到 Log 內容，
有時候在 Visual Studio 進入偵錯模式的時候，不會想再分神去開啟別的工具來看這些 Log 檔案，
而會希望能夠把一些不需要記錄到 Log 資料庫的訊息給顯示在某個地方，讓我們執行到某些地方就可以看到記錄，
有一些寫 ASP.NET 的朋友最常用的方式就是 …… ResponseWrite() 與 Javascript 的 Alert() ……
但這不是一個好的方式。
之前有說到，Elmah.MVC 已經在 2012-06-16 發佈 2.0.0 的更新了，
之前我們一直使用的版本是 1.3.2，新舊版本的差異性相當地大，所以就覺得有需要做個介紹，
其實最主要的原因是，在 2012-06-14 twMVC 的研討會活動，我所講述的「ASP.NET MVC 偵測監控與 Log 記錄」中，
有向在場的朋友介紹使用 Elmah.MVC，當時所使用的版本仍然是 1.3.2，
雖然 2.0.0 早已經在 2012-06-13 做了 RC 發佈，但當時我是想說應該不會這麼快就有變化，
沒想到上週六（2012-06-16）在家整理專案的時候，一樣是透過 NuGet 安裝 Elmah.MVC，發現到安裝後有很大的不同，
當時心裡就覺得大事不妙，心想著假如有參加過研討會的朋友練習使用 Elmah 然後也安裝了 Elmah.MVC，
發覺到怎麼安裝之後的內容跟我在研討會中所說的不同時，我一定會遭到這些朋友的咒罵，因為是完全兩碼子不同的事！
所以就寫一篇文章來說明一下 Elmah.MVC 2.0.0 有什麼樣的不同與變化！
在之前的文章：
「ASP.NET MVC + ELMAH 監控並記錄你的網站錯誤資訊 1」
「ASP.NET MVC + ELMAH 監控並記錄你的網站錯誤資訊 2」
第一篇是講有關 ASP.NET MVC 網站專案安裝 Elmah 相關 Package 的說明，
第二篇則是講到有關如何修改 Elmah 的 location 的方法（在文章的下方，雖然說得不是很清楚）。
然後前些日子（2012-06-14）這天的活動「活動宣傳 2012/06/14 「攻略 ASP.NET MVC - 從無到有 與 效能剖析」」
這天我所講述的內容當中也有說明到如何去修改 Elmah 的 location 以及如何去修改 Elmah.MVC 所預設建立的 Area 名稱，
其實 Elmah.MVC 這個 package 並非一定要安裝，Elmah.MVC 只是提供一個符合 MVC URL 路徑的瀏覽方式，
如果我們的 ASP.NET MVC 網站有安裝 Elmah 但不想安裝 Elmah.MVC 的話，其實也是可行的，
這樣的作法就跟 ASP.NET WebForms 網站使用 Elmah 是一樣的。
但因為沒有安裝 Elmah.MVC 的情況下，要如何修改 Elmah 的 location 呢？
以下就為各位做個說明。
最近為了 twMVC「攻略 ASP.NET MVC ─ 從無到有 與 偵測監控」其中的講題「ASP.NET MVC 偵測監控與 Log 記錄」而一直在做準備，
但是這兩天突然看到一個很奇怪的現象，讓我一直很納悶……
為什麼 ELMAH 沒有記錄到正確的 Http Status Code 呢？原本應該是 500 而 ELMAH 卻是記錄為 0 ……
這個問題一直困擾著我，所以就試著找出原因來。
經常來這個部落格的人應該會發現到我一直推薦大家使用 MiniProfiler，大家的反應也都是很好，但卻一直保持觀望，為什麼會這樣呢？其實了解一些朋友的疑慮之後就讓我不禁搖頭，我必須說，好用的工具介紹給大家，各位也必須要自己抓下來安裝之後來做個了解，而不能只是看看文章，覺得東西不錯但有些疑慮擺在心理然後就把這好用的工具給拋在腦後，這樣是不對的啦！
我這邊聽到最多的都是 MiniProfiler 的安全性以及上線後的 Profiling Popup 的顯示……
如果是真的有實際玩過 MiniProfiler 的人就不會有這樣的疑問，玩過的人反而會問的是如何設置權限……
所以就藉著這篇文章來試圖解除還沒有玩過 MiniProfiler 的人存在心中以久的疑慮。
上一篇文章「MiniProfiler 2.0.1」就有說到 MiniProfiler 有支援 ASP.NET WebForms 與 WCF，因為我對 WCF 相當不熟，而目前工作所執行的專案就是使用 ASP.NET WebForms，所以看到 MiniProfiler 有支援 WebForms，我就期待在 WebForms 上可以使用，因為在 MVC 的專案開發時使用 MiniProfiler，的確是有很大的幫助，而如果相同的功能可以在 WebForms 上執行就太好了，不過 MiniProfiler 的官網上的使用說明以及作者的部落格文章裡面對於 WebForms 專案如何配置 MiniProfiler 的設定卻是隻字未提。
而 github 上所開放的原始碼裡，WebForms 專案看起來就是個測試追蹤 SQLite 的 Demo 專案，如果要看原始碼中 WebForms 專案的配置設定來做為我們專案修改的參考，我必須說一定看不懂啦！不過我在幾次的測試之後整理出如何為 WebForms 專案配置設定 MiniProfiler 的方式，以下就是我所整理出的心得，分享給有需要的朋友做參考。
MiniProfiler 在這個部落格中的很多文章中都有出現過，甚至於也以此為題寫了有四篇的文章：
哪為什麼現在又要再寫一篇有關 MiniProfiler 的文章呢？
這絕對不是為了要佔篇幅（這裡不是報紙也不是雜誌），也不是為了要騙稿費（我找誰要稿費呀），而是因為 MiniProfiler 在 2012-02-22 所發佈更新的 v2.0 有了蠻多的變革，而我卻是遲至今日才開始想寫這些內容，工作忙碌、twMVC 準備工作滿檔、懶？
總之呢 …… 就看下去吧！
「觀察 Entity Framework 轉換所產出的 SQL Command」這一篇文章當中有簡單介紹了在Oracle ODAC For EF 的情境下如何觀察SQL Command，然而並不是每個方式都管用，而且有的方式會需要在偵錯模式下才能觀察（如使用Entity Visualizer），而之前也曾經介紹過一個可以用來偵測ASP.NET MVC執行效能的套件「MVC-Mini-Profiler」，這一個套件除了偵測執行效能外，有使用Entity Framework的話也可以偵測EF所產生的SQL Command，「ASP.NET MVC 3 + MiniProfiler.MVC3 偵測執行效能」文章裡所使用的資料庫是MS SQL Server，而當資料庫改使用Oracle而EF Provider也使用了Oracle ODAC for EF呢？
這一篇文章就來看看在使用Oracle ODAC for EF的情境下使用MVC-Mini Profiler是否可以偵測到EF所產生的SQL Command。
