在 2015 年 12 月裡所舉行的 twMVC#21，我在主講的「以實例說明 ASP.NET Web API 服務的開發與測試過程」裡就有將 NanoProfiler 介紹給大家，而到了現在才有時間將使用、安裝的說明給整理出來，所以將會有一系列的文章說明如何使用 NanoProfiler。
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 開發，這過程我花了一個多月，不算順利、遇到很多問題、撞了很多牆、衝擊很多觀念，最後就一直到了現在。
這邊分享一些我的看法與建議。
經過兩篇文章的鋪陳，總算來到了最後一篇，將會把修改過的最後完成版提供給各位，讓各位開發 Web API 專案時在操作使用 Postman 能夠方便與易於管理。
ASP.NET Web API - Import a Postman Collection Part.1
ASP.NET Web API - Import a Postman Collection Part.2
接續上一篇的內容，來看看最原始的做法有些什麼樣的問題，先開門見山做個說明，這一篇會再沿用別人所提供的改良做法，不過最後的結果依舊還是會有一些問題存在，所以最後在第三篇的文章裡將會提供我所修改過的程式碼，而這也是我開發的專案以及部門其他開發團隊所使用的方法。
在開發過程中，開發人員主要還是會透過 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 主題可以感受到明顯的差別，但是看久了之後還是很不習慣，所以血液裡的搞怪因子又讓我起了動手腳的念頭，於是參考了網路上的幾篇文章與說明做了修改，最後的結果還不錯，這篇文章就為各位說明如何去動手腳。
前一篇簡單介紹如何在一個 ASP.NET Web Api 專案裡安裝 Swashbuckle - Swagger for Web Api 這個套件，基本上都沒有什麼難度，特別要注意的就是 Controller 與 Action 方法與相關類別的 XML 文件註解要記得寫以及維護，在一般的使用情況下的 Api 服務資訊提供已經相當清楚了。
不過提供更加清楚的資訊給使用 Api 服務的開發者對於產品的開發與溝通是有絕對幫助的，但老實說，要把 Swagger 寫得好又要能夠搭配 Web Api 後端程式讓資訊可以自動產生，其實也不是容易的事情，這邊就來說明幾個調整顯示資訊的做法。
Swagger 是一套 API 互動文件產生器，使用 HTML 與 Javascript 所編寫的，與之前所介紹的 ASP.NET Web API Help Page 不同的是，Swagger 是一套 Open Source Software，支援了現在許多的 REST API，之所以會說這是一個互動的文件，除了顯示 API 輸出入規格外，也能夠讓使用者即時的在 Swagger UI 介面上進行操作，立刻就能看到執行結果。
這一篇將會簡單說明如何在一個 ASP.NET Web API 專案裡加入 Swagger 功能。
這個功能的主題其實有很多人都寫過了，不過為了之後的文章，所以還是要先寫出這一篇。
大家也都知道 ASP.NET Web Api 2 都已經有內建了 Help Page 的功能，這是一個可以產生對應 API 服務的線上文件產生器，所謂的產生並不是可以幫我們做出一份 Word 或是 PDF 檔，而是指將我們所開發的 API 服務相關的輸入、輸出、Resource 等資料經由 Help Page 的功能處理並建立好網頁，在網頁上去提供了這些 API 服務的相關資訊，以方便介接 API 服務的開發人員查看。
這一篇就來簡單地介紹如何在 ASP.NET Web Api 應用服務裡啟用這一個功能。
