在 twMVC#15 時，我以「開發的效能和效率」這個題目分享了幾個追蹤分析以及效能監控的工具，有些功能是 Visual Studio 本身就有提供，但是只有在 Ultimate 或 Enterprise 才有提供，而有些則是需要付費購買的第三方套件，看起來好像都需要先付出一筆費用之後才有辦法去做到詳細追蹤分析的事情，不過也並不是這樣，因為有很多人既使給他們用了最高開發等級的 Visual Studio，也還是有一堆功能根本不會用，而且可能還不知道有這些功能。
這一篇文章將會介紹一套免費及操作簡便的 .NET 應用程式分析工具「CodeTrack」，希望能夠為各位的開發與系統維護時有所幫助。
是的，在今年三月的時候微軟就已經宣佈要讓 SQL Server 放在 Linux 系統裡，而在前陣子的 Microsoft Connect(); 2016 大會裡發表了 Microsoft SQL Server for Linux v.Next，雖然離真正可以商業應用的階段可能還要一段時間，但是我想不久的將來微軟應該就可以完成這個目標，畢竟目前 Linux 系統的市佔率是節節升高，微軟以及使用微軟技術的工程師們必須正視這樣的轉變，也必須進早熟悉和因應。
這一篇文章將會簡單的介紹如何以 Docker 的方式讓 MS SQL Server for Linux 運行在 Docker for Windows 上。
經過上一篇「Docker for Windows 與 ASP.NET Core - Part.1 安裝與使用 Visual Studio 2015」的環境建置與開發環境建立專案和使用 Visual Studio Tools for Docker - Preview 之後，這一次來嘗試使用指令碼的方式建立 ASP.NET Core 的 Image 和 Container 並且運行在 Docker 裡。
目前容器技術已經成為主流，許多公司的資訊系統架構都已經轉向容器化，以往在 Windows 系統要使用 Docker 都會受到許多技術限制，雖然可以用許多方式來使用 Docker，但使用上還是不太順暢與便利，不過 2016年的下半年陸續由 Docker 發佈了 Docker for Windows 以及 Microsoft 發佈 Windows Container，前者可以讓開發人員可以在 Windows 環境裡架設及使用 Linux 基礎的 Docker，後者則是 Windows 版的 Container 技術，不管是哪一種版本都是開發人員必須要熟悉與認識，因為這是未來的一大趨勢。
此篇文章會先介紹如何安裝 Docker for Windows，另外使用 Visual Studio 2015 建立 ASP.NET Core 專案以及安裝套件，然後使用這個 ASP.NET Core 專案建立 Docker image, container 以及執行。
接下來會有幾篇文章會介紹 Docker for Windows 與 Windows Container 的文章，方便大家可以入門學習。
將「Repository 測試 - 使用 LocalDB」這系列文章的範例程式碼給發佈到 Github 上面囉，完整的專案程式碼會比文章裡只有提到部分來得清楚（其實文章裡所提供的程式都已經是完整的內容），還是有很多開發者對於文字與部分程式的內容比較沒有感覺，所以有時間就把專案 Clone 一份下來看看。（還是有很多人習慣看程式，都已經把完整的專案公開了，就下載並且執行看看吧）
本來應該在 Part.3 這一篇就應該做個完結，但還是有一件事情要交代，所以又開了一篇來做說明，這一篇會有關於前陣子所發的文章「準備 Repository 單元測試的測試資料 - 產生匯入資料的 SQL Script」有關，在「Repository 測試使用 LocalDB - Part.3」裡面所使用的是 CSV 匯入測試資料，而接著就會說明使用 Insert SQL Command 的方式匯入測試資料的做法。
接續上一篇「Repository 測試使用 LocalDB - Part.2 」的內容，在上一篇已經完成使用 Entity Framework 建立與移除 LocalDB 的類別和方法，在第一篇「Repository 測試使用 LocalDB - Part.1 」也說明了要受測試的目標類別與方法，另外也建立了要在單元測試裡所使用的測試資料。
這一篇就要完成 Repository 的單元測試，會用到前面兩篇所建立的類別與資料，所以請各位要仔細看清楚囉。
去年有寫過一篇關於在測試專案裡使用 LocalDB 的文章「測試專案使用 LocalDB - 使用 Entity Framework 的情境」，的確是一個可以執行的做法，但是在多人開發的專案或是多分支開發的專案裡，這樣的做法會帶來一些問題，另外在一些環境裡執行單元測試時會遇到權限不足的問題（例如登入使用者並不具有 Administrator 權限時）會造成測試執行失敗，以致於最後我不在使用那種方式。
既然不用了也還是必須要有替代的方式去完成 Repository 的單元測試，於是我之後嘗試使用指令碼的方式在執行 Repository 測試前建立 LocalDB、執行測試後再移除 LocalDB，這樣的做法也真的可行，不過卻相當不穩定，當測試全部都執行正確時是不會有問題，但是一旦當一個錯誤發生問題時，建立的 LocalDB instance 就會被鎖住而無法正確釋放、移除，這樣的問題一直困擾著我很久。
接下來的幾篇文章將會介紹一個穩定而且不會發生測試失敗就把 LocalDB 鎖住的方式，藉助 Entity Framework 所提供的類別與方法來完成 Repository 測試的 LocalDB 建立與移除，讓我們能夠以更為簡易的方式來完成 Repositoy 的單元測試。
之前有介紹過一篇準備測試資料的文章「輸出測試用資料的 CSV 檔案 - 使用 LINQPad, AutoMapper, CsvHelper」，在大部分的情況下我蠻常使用這樣的操作方式來準備測試資料，但隨著單元測試的數量越來越多，而且因為在公司裡所開發的專案大部分還是使用 Dapper 來存取資料，所以 Repository 的單元測試就開始暴增，原本使用 CSV 檔案來匯入測試資料到 LocalDB 的前置作業就會成為讓整體測試作業執行時間緩慢的原因之一（有關怎麼使用 LocalDB 進行 Repository 單元測試與使用 CSV 檔匯入測試資料的內容，日後再寫篇文章來說明）。
為了解決使用 CSV 檔案匯入測試資料會因為資料轉換而使得測試時間拉長的情況，所以乾脆使用 SQL Dumper 及 ApexSQL Script 工具匯出 SQL Script 來直接匯入測試資料。
以往在針對方法的執行結果進行資料排序的驗證時，比較直接的做法就是取得 collection 的第一筆與最後一筆，然後再依據用什麼條件做排序去比較兩筆資料，例如使用日期為條件而且是由新到舊的排序，那麼第一筆資料必須要比最後一筆資料的日期還要新，大概是用這樣的方式做資料排序的驗證。
不過這樣的做法還蠻土砲的，所以就用 Fluent Assertions 所提供的方法來處理吧。
資料存取層的測試… 真的比較麻煩
有些資料是已經存在於資料庫，例如定期匯入或排程計算的資料結果，如果在程式裡使用 AutoFixture 或是假資料來做測試，有時候會出現一些問題點，所以就會從資料庫直接取得一部份的資料來做為測試資料，匯出的方式有很多種，而這一篇所介紹的方式就是其中一種，我是希望可以盡量使用程式的方式來處理而不是以 Insert Script 的方式來，不過這不是絕對的做法，就看各位習慣什麼方式，或許大家有更好以及更好管理的方法。
去年曾經向各位介紹如何使用 LINQPad 快速產生相對映 SQL Command 查詢結果的類別，連結如下：
http://kevintsengtw.blogspot.tw/2015/10/dapper-linqpad-sql-command.html
對於使用 Dapper 做為資料讀取異動操作的開發者來說，應該是相當方便，目前我目前的工作環境裡，幾乎新開發的專案裡都已經使用 Dapper 以及快速產生相對映類別的方法。
另外就是有關於單元測試的部分，公司裡的各個開發團隊也陸續在專案裡導入單元測試，不管是應用展示層或是商業邏輯層都會嘗試去做單元測試，唯獨資料存取層的單元測試卻是比較少人會去做，當然資料存取層的單元測試是否要做，這並沒有一定的標準答案，而我所認知的是，只要程式是開發人員去編寫出來的就有必要做測試，但是資料存取層的測試所牽涉到的技術會比較多一些，也關係到資料存取所使用的方式，都是影響要不要做測試的因素。
而這一篇所要介紹的內容也就是在做資料存取層的單元測試時的其中一個環節。
之前連著兩篇介紹了 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」
2009 年在台灣微軟 7F 的一場由 Will 保哥所帶來的一個多小時教學課程開始，我第一次接觸了 ASP.NET MVC，當時的我對於這項技術還是懵懵懂懂，整場下來猶如走馬看花一般，太多觀念與實作方式與當時我所熟悉的 ASP.NET WebForm 有著極大的不同，但當時對我而言，比較讓我不明白的是在 View, Controller 以及 Route，因為這是 WebForm 所沒有的，但已經使用 LINQ to SQL 與 Entity Framework, 物件導向程式開發的我來說，在 Model 部分是沒有讓我有任何的不明白，當時我已經不再使用 DataSet, DataTable, DataSource Controls，而在一年之後的七月，我就全面開始以 ASP.NET MVC 在工作上進行專案開發，而從 ASP.NET WebForm 到全面轉換為 ASP.NET MVC 開發，這過程我花了一個多月，不算順利、遇到很多問題、撞了很多牆、衝擊很多觀念，最後就一直到了現在。
這邊分享一些我的看法與建議。
前不久在 feedly 裡看到訂閱的 Mikesdotnetting 部落格介紹了一個免費的 ASP.NET 監控工具「Prefix」，大致看了一下介紹，發現到這的確是個不錯的工具，所以就寫篇文章來做個簡單介紹。
這部落格也介紹了一些 Profile 的工具，例如 miniProfiler, Glimpse 等，但這個 Prefix 與前面所提的有什麼不同呢？看下去就知道。
把 2013 年 10 月份所寫的一系列 ASP.NET MVC + jQuery EasyUI DataGrid 文章裡的範例做了整理，然後發佈在 Github Repository 上，雖然在臺灣使用 jQuery EasyUI 在系統裡的專案並不是很多，尤其是 ASP.NET MVC 的更少，但我覺得過去的這系列文章裡也有一些內容是可以借鑑的，例如多欄位排序的處理。
放到 GitHub 上的範例程式都是可以正常執行的，建議各位不要只是在 GitHub 上面瀏覽程式，而是直接將原始碼下載或 Clone一份，直接在你自己的電腦上面執行。
經過兩篇文章的鋪陳，總算來到了最後一篇，將會把修改過的最後完成版提供給各位，讓各位開發 Web API 專案時在操作使用 Postman 能夠方便與易於管理。
ASP.NET Web API - Import a Postman Collection Part.1
ASP.NET Web API - Import a Postman Collection Part.2
接續上一篇的內容，來看看最原始的做法有些什麼樣的問題，先開門見山做個說明，這一篇會再沿用別人所提供的改良做法，不過最後的結果依舊還是會有一些問題存在，所以最後在第三篇的文章裡將會提供我所修改過的程式碼，而這也是我開發的專案以及部門其他開發團隊所使用的方法。
之前介紹了幾篇在開發 ASP.NET Web API 專案時會使用到的功能：
ASP.NET Web Api - Help Page
ASP.NET Web API 文件產生器 - 使用 Swagger
Swashbuckle - Swagger for Web Api 顯示內容的調整
雖然 Help Page 可以提供專案 API 功能說明文件的查看，而 Swagger 除了涵蓋 Help Page 所提供的文件查看功能外，也可以直接在頁面上操作 API 並且立即得到執行結果。
在開發過程中，開發人員主要還是會透過 Postman 進行開發的偵錯、測試、操作等，如果開發人員只有一個人的時候，在 Postman 裡增加或管理 Collection, API 都還算是可以控制，但如果是多人開發團隊共同開發一個 Web API 專案時，就會發現到每個人所使用的 API Collection 內容都有很大的出入與差異，所以就必須要有一個能夠一致化 API Collection 的功能，讓團隊的每個開發人員都使用一樣的 API Collection 進行操作。
關於 Visual Studio 佈景主題的相關文章寫了不少篇，不過都是以 Visual Studio 2013 為主，但是到了 Visual Studio 2015 卻有點不同了，例如 Studio Styles 這個提供了很多編輯器樣式的網站，絕大部分的 Style Setting 雖然依然可以在 VS2015 裡面使用，但因為 VS2015 修改了很多樣式設定的名稱，所以就會有很多地方是相當怪異，最後我就只好使用 VS2015 所提供的預設 Dark 主題，這個主題的編輯器顏色配置算是相當舒服，與 VS2013 or VS2012 原本的 Dark 主題可以感受到明顯的差別，但是看久了之後還是很不習慣，所以血液裡的搞怪因子又讓我起了動手腳的念頭，於是參考了網路上的幾篇文章與說明做了修改，最後的結果還不錯，這篇文章就為各位說明如何去動手腳。
