前一篇簡單介紹如何在一個 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 應用服務裡啟用這一個功能。
因為這一年來主要都是在開發 ASP.NET Web Api 專案，Client 端的開發測試工具是使用「Postman」，而我也並非第一次在專案開發裡使用，在這幾年的開發裡都有使用到，只不過這次的角色從介接使用別人所開發的 Web Api 變成開發別人要使用的 Web Api，其實不管哪一種角色，使用這類的工具如何可以更加地瞭解如何應用，那麼就會省下很多很多的時間，而這一篇所要講的就是 Postman 所提供的一個功能「Generate Code Snippet」。
從 twMVC#12 由 91 哥所分享的「如何在實務上使用 TDD 來開發」開始，然後 91 哥在 SkillTree 講授「自動測試與 TDD 實務開發(使用C#)」四個梯次，從一開始對測試與開發的懵懵懂懂，到現在雖然還無法相當進階，但也已經在平常工作的開發裡導入單元測試，並且向部門同事分享，分享的內容是以 91 哥在課堂上的內容為基礎，再以公司團隊的現況去做調整，我無法像 91 哥那樣可以將測試、開發甚至到後續的規格實例化以及使用 BDD 等一連串內容講得鉅細靡遺，所以我就以我本身的專案導入現況以及每次推進的內容逐一分享給同事。
這一篇是介紹「Fluent Assertions」這個好用的測試輔助套件，原本早就規劃在部落格文章的寫作時程裡，但是這一年來除了上半年因為工作忙碌而影響了寫文進度，另一方面還是因為變得有點懶，所以文章產量比起以往銳減許多，就在「自動測試與 TDD 實務開發(使用C#)」第四梯次課程裡被 91 哥點名了好多次，因為在 Facebook 有時會對於目前使用了哪些工具、套件而寫些感想，所以讓 91 哥覺得我有寫些工具套件的介紹文，不過既然被 91 哥點名了，這也提醒我要趕快把這些文章給補一補。
題目有點難定，這麼做個簡單的說明，在一個使用情境裡會使用到同個類別的同個方法多次，然後第一次執行的結果與後續幾次的執行結果會有所不同。例如在一個使用情境裡，方法裡會使用到一個物件 collection，然後會去使用另一個類別的方法做多次處理（比方說，刪除），執行第一次與後續幾次的執行就會有不同的回傳結果。
如果要對這個使用情境去做單元測試時，以上的那個執行多次的類別方法是需要被隔離，使用 NSubstitute 建立 stub 與預期回傳值，那麼應該怎麼處理呢？
前面幾篇文章都是一直在介紹 Dapper 的相關功能，不過都是屬於基本的應用，Dapper 也是有很多的進階使用方式，不過這邊就不繼續介紹而是讓各位去發掘與找出適合自己專案的做法，這一篇文章基本上跟 Dapper 沒有直接關係，因為產出對映查詢結果類別的這一個功能並非使用 Dapper，因為 Dapper 只是一個優化 ADO.NET 操作 T-SQL 以及對映類別的一個 Utilities，本身並沒有提供什麼神奇的功能，但是很多人從傳統 ADO.NET 操作並且使用 DataSet DataTable 弱型別的方式改為使用 Dapper 以及強型別的時候，普遍都會遇到一個最大的困難…… 「建立類別」。
這一篇文章的內容算是拾人牙慧，只是跟大家說別人有提供了方法可以讓我們能夠快速地從 SQL Command 去建立相對映的類別，雖然不是我寫的方法，但還是希望大家可以及早地從弱型別的地獄中快點逃離出來（雖然這麼說是有貶抑弱型別的意味，但看了這麼多年以及很多人所開發的專案，發現到很多問題都是從濫用 DataSet DataTable 等弱型別開始）。
接連三篇有關 Dapper 的文章，都是使用 LINQPad 向各位說明，對於有些開發者來說可能無法馬上可以體會，因為沒有一個明確或是簡單的應用範例，所以感覺就會有點在空談，所以這一篇就用一個簡單的 ASP.NET MVC 網站範例來做介紹，之前曾經在 twMVC #10 裡有分享過「ASP.NET MVC Model 的設計與使用」這個主題，然後又在部落格裡寫了以「ASP.NET MVC 的 Model 使用 ADO.NET」為題的五篇系列文，這一篇的範例文章就以那五篇系列文最後所完成的簡單範例做修改，在方案裡添加使用 Dapper 的 Repository 專案，並且讓 ASP.NET MVC 與 WebForm 網站都可以直接使用。
關於定義類別這件事，尤其是裝載資料的 Model 類別，在開發的過程中算是稀鬆平常的事情，但如果你的開發是習慣使用弱型別並且從頭到尾（從資料庫取得一直到資料顯示在頁面上）都使用弱型別，那麼建立 Model 類別的次數就會相對地比較少，因為會用到的情況比較少，但如果你已經試著在專案裡使用 Dapper 開發或是早已經使用 ADO.NET + T-SQL 然後自行處理資料對映到類別的操作，那一定會遇到一種情況會讓人相當猶豫不決，那就是查詢所取得的欄位數量不多時，實在是不想再去建立一個新的類別（因為建立的類別已經一堆了，再新建下去就搞不清楚了）。
Dapper 有提供查詢結果對映到 dynamic 型別，上述所遇到的狀況就能提供方便的處理，如此一來就不必每個查詢都需要建立一個新的類別，減少管理及維護上的困擾。
前一篇已經向大家介紹了 Dapper 這一個資料存取套件，可以作為解決專案仍須使用一般 T-SQL 操作但是又不想直接處理弱型別的情境，尤其是在比較強調使用「強型別」的 ASP.NET MVC / Web API 專案裡，可以不必硬著頭皮使用 Entity Framework（因為許多企業的系統環境不允許），而且也可以兼顧既有的商業邏輯包袱（都已經說是包袱了，還是希望可以早點解下並丟開）。
其實 Dapper 並不需要太多的介紹與教學，其實對於既有 ADO.NET + T-SQL 已經相當熟悉的開發者應該可以短時間上手，我所看到最多的問題應該會是在「物件導向」的觀念與使用，畢竟之前使用 ADO.NET + T-SQL 的操作處理都是直接使用弱型別，從取得資料一直到資料的顯示輸出，甚至資料的輸入，都沒有什麼機會用到所謂的物件導向，另外要特別強調的就是，不是在專案裡建立了好多個 class 然後使用類別在程式裡傳來傳去就可以叫做物件導向，例如你在一個類別的建構式裡塞了成千上百的程式然後又直接跟資料庫串接並且又有商業邏輯的處理，這完全不是物件導向，還是依然是在程序導向的開發。
嗯…… 這一篇所要講的跟上面所講的沒什麼關係（只是單純地抒發想法），Dapper 對於一次新增多筆資料的做法是相當簡單的，這篇也跟大家介紹如何處理一次新增多筆且大量的資料新增。
這一篇文章的內容是依據我在公司裡所分享的主題「ASP.NET.MVC / Web API 另一種存取方式」再加以整理。接觸 Dapper 這個資料存取套件是有一段時間，但一直都沒有機會使用上，因為之後所做的專案多半都是使用 Entity Framework，而在去年要開始做新專案的時候，因為系統環境以及舊有包袱的緣故，於是我就想起了 Dapper，也的確解決了許多原有的問題並且大來很大的效益。
這一篇介紹 Dapper 並不會有特別深入的使用介紹，大概只能算是入門介紹，最主要的目的是要讓大家能夠知道在現有環境無法使用 ORM 的情況，尤其又是開發 ASP.NET MVC / Web API 的專案，除了 Entity Framework 之外能夠有其他的替代方案。
注意，並不是說 ASP.NET MVC / Web API 才能夠使用 Dapper，任何你之前使用 ADO.NET + T-SQL 所開發的專案都可以使用（一定要先這麼說，不然一定很多人會有所誤解，這是寫部落格文章四年多來，接到無數回應、詢問所得到的心得。）
之前有介紹過如果我們要做程度碼度量，在 Visual Studio 裡可以使用內建的「計算程式碼度量 （Code Metrics）」功能，另外我也在這一篇「Visual Studio 計算程式碼度量 - Code Metrics Viewer 2013」介紹另外一個工具「Code Metrics Viewer 2013」也同樣是在做程度碼度量計算的工作，兩個功能其實都是差不多的，只是要看這些程式碼度量的數據都是要經過工具的計算，而且無法馬上或是隨時看到，比較重視這些數據的開發者是會感到有些不方便。
這篇要介紹的「Microsoft CodeLens Code Health Indicator」能夠將程式裡每個方法的程式碼度量給顯示在 CodeLens 上面，是個蠻方便的工具。
當我們在 Visual Studio 裡開啟了一堆檔案時候，有時候想要去方案總管裡查看目前所編輯的檔案是在哪一個專案、哪一個資料夾裡，通常就會看到很多開發者開始在方案總管裡翻箱倒櫃，如果只有一個專案，甚至專案結構比較簡單的，那麼就能夠很快地找到，但如果是比較大型的專案，或是拆解得相當瑣碎的專案，要找到目前編輯檔案的所在位置就是一件大工程了。
這個功能的操作，我都是使用工具來做處理，但如果是沒有使用到這些工具時，就沒有辦法可以使用比較快速方便的方式來解決嗎？
這一篇就告訴大家可以做些什麼樣的調整，讓我們的操作可以一樣達到相同的效果。
這是個小功能，但卻是可以讓開發者能夠節省很多時間的功能，所以別小看。
我在使用 VS2013, VS2012, VS2010 開發的時候，我都會安裝一套 Visual Studio 的擴充工具「VSCommands」，這個工具有提供相當多的功能，也因為已經長久習慣在 Visual Studio 裡使用，所以有很多由 VSCommands 所提供的功能都讓我一直以為那是 Visual Studio 內建提供的，這是一個需付費購買的工具，不付費與付費版本會有蠻多的差別。
但是到了 VS2015 之後 VSCommands 就不再繼續發佈相對應的版本，這對於已經習慣使用的我來說就有許多功能就必須要找替代方案了，其中的「Restart Visual Studio (Elevated)」快速以系統管理員身份重新開啟 Visual Studio 這個功能就是我時常都會用到的，雖然 VSCommands 沒有相對應 VS2015 的版本，不過還好有找到一個功能相近的 Extensions，在這邊介紹給大家。
我所使用的 Visual Studio 2013 環境色彩佈景主題是使用「藍色」，這佈景主題顏色也是我一直從 Visual Studio 2005 一直沿用到現在，當然在 VS2005, VS2008 是沒辦法選擇更換，到了 VS2010 之後就有了可以更換各種 Theme 的擴充功能，不過大多數的人還是使用藍色為主，然而到了 VS2012 後就變成可以選用 Dark 或 Light 的主題，但是這兩種我都不喜歡，Dark 太黑了，連選單都是黑的，常常找個東西要找很久，但是 Light 又太刺眼了，看久了眼睛會相當疲累，所以我就會使用 Color Theme Editor 選用已經習慣使用的藍色主題，不過之後藍色主題又重新回到 VS2013 預設環境主題之一，在此之前無論用什麼主題然後再去套用不同的文字編輯器顏色設定都不會有太大問題，為此我還有寫了一篇文章作介紹：mrkt 的程式學習筆記: Visual Studio 2013 佈景主題與 Code Style
但是到了 Visual Studio 2015 卻出現了一點點的不一樣，因為找不到怎麼修改，所以就在這一個月裡都是使用 Dark Theme，但真的是相當不習慣呀，所以認真的找了一下怎麼修改，總算又可以使用 Blue Theme 並且使用 Son of Obsidian 的 Code Style，為此寫篇文章做個記錄（其實還蠻簡單的）。
繼續上一篇「NSubstitute 練習題 - void 不回傳值方法但有使用到 out 參數」最後所提到的，當測試對象裡所使用的其他類別方法拋出錯誤時要怎麼去做這個情境的測試。
一樣是使用 NSubstitute 完成這一次的練習。
嗯…… 好久沒有寫文章，再次寫文章的題目卻讓人搞不太清楚，簡單來說就是看下面圖會比較清楚，
不要問為何會有這樣的程式，又為何要這麼樣設計與使用，那個不是重點，重點在於怎麼去對這一段程式去做測試。
這一篇其實並不會像前兩篇講太多有關工具設定或調整的內容，著重在一個重點「快」。很多人都會問我「要怎樣才能快速產出？」「要如何才能有效率的開發？」，要不然就是跟我直接說要我教他們如何快速寫程式。
其實這有很大的誤會，因為熟悉我的人都會知道我其實寫程式是很慢的，慢就算了，而且會非常吹毛求疵，因為我不希望我所寫的程式在交付上線之後會有嚴重的問題出現，所以我會很嚴謹地寫程式，尤其現在我已經在專案開發導入測試之後，我一定會在交付前將所有功能的測試給完成並通過後才會交出去，所以我寫程式會快嗎？當然不會有多快，但是我還是可以在同樣的時間內將功能給完成而且還包含測試，這並沒有什麼魔法或奇蹟，只是開發習慣的養成而已。
West Wind Web Surge (以下簡稱 WebSurge) 不只是用於 ASP.NET Web API 的壓力測試功能，也可以對 ASP.NET MVC, ASP.NET WebForm 或是其他網站應用服務進行簡單的壓力測試，而 Load Testing 也僅是 WebSurge 其中的一個功能，WebSurge 也有類似 Telerik Fiddler 的功能，可以針對指定的瀏覽器所發出的 Request 和接收的 Response 進行擷取，有興趣的朋友可以去 WebSurge 的官方網站裡進行瞭解。
不過這一篇文章只針對 Load Testing 這個功能作簡單的說明。
我在開發專案的時候一定會用到很多的介面，可以從我的一些系列文章裡可以看到，對於系統的抽象化是否能夠瞭解、掌握與充分使用，對於大型、複雜系統的分解與後續的測試都會有相當大的幫助，如果你對於系統抽象化的分析與解構都能夠相當上手，很多看似複雜、難以處理的問題都可以迎刃而解。
話雖這麼說，還是很多人對於物件導向的抽象化還是相當模糊，更別說將抽象化的概念去轉化到實際的專案開發裡頭，所以一個很直接的點就可以看出系統的結構是否良好以及後續的維護，甚至於是否具有可測試性都可以看出，就是看專案裡頭有沒有使用到「介面 Interface」，我知道這一段說法相當武斷與偏頗，不過就我目前所接觸到的情況都能夠看出端倪與跡象。
很多人對於介面，因為不瞭解以及不知道如何應用在實務上，所以就乾脆選擇不用。而另外一種狀況則是當專案使用了介面之後，在進入偵測模式或是在 Design-Time 時，當想要去看某個繼承於介面的方法時，按下 F12 後就會直接移到介面的定義裡，而不是繼承實作類別裡，然後為了要找真正的實作方法就要找很久 …… 不要認為有人因為這個理由就不使用介面，我還真的有碰到一個團隊因為這樣而禁止在專案開發時使用介面，夠瞎吧，我只能說世界之大、無奇不有，其實這肇因於對於 Visual Studio 的不熟悉以及個人觀念的不好而犧牲了讓系統邁向良好架構的機會。
LINQPad 的好用以及它是 .NET 開發人員必備的工具，這些我想就不用一再地強調，如果你還真的不知道為何 LINQPad 是如此必須的話，請參考這部落格裡有關 LINQPad 的文章。
另外不要只是用著免費版的 LINQPad 然後跟我靠北說很難用，已經再三強調免費版給你基本的功能，但是要能夠發揮其最大的效用就必須購買使用付費版。另外也要說，不要想著去找破解版，身為一個資訊開發人員，請先尊重別人的專業與智慧財產，使用者付費的觀念要落實，學會尊重別人的專業，才能讓別人也尊重你的專業。
再過不久 LINQPad 5.0 將會推出正式版，其實目前 5.0 Beta 也已經發佈一段時間了，所以想要嘗鮮的朋友可以前往 LINQPad 的官網下載，雖然 LINQPad 5.0 的新功能裡有幾項是比較引人注意的，就來看看有哪些新改變。
在上一篇「測試專案使用 LocalDB - 使用 Entity Framework 的情境」說明了測試專案裡如何有 LocalDB 的類別庫專案加入參考引用，然後在做一些設定處理後就可以讓測試專案使用 LocalDB 去對有使用 EF 的程式作單元測試。
但如果跟我一樣在開發時有使用 NCrunch 的朋友，可能就會遇到跟我同樣的問題，那就是在 Visual Studio 裡的測試總管執行測試都是正常的，但是使用 NCrunch 狀況下就是給你亮紅燈，測試程式並沒有任何問題，這是 NCrunch 的設計上以及預設設定所造成的執行錯誤結果。
如果沒有特別去做處理的話，很多人因為不得要領就可能會選擇讓 NCrunch 忽略有使用到 LocalDB 的測試，這還蠻可惜的，因為 NCrunch 的確是個相當好用的工具，所以就必須要想辦法讓一般使用的測試總管的執行可以正常之外，也必須要讓屬於設計期間的測試輔助工具 NCrunch 一樣可以正常的執行。
測試要與外部資源做隔離，這包含了專案所使用的資料庫，那要如何測試呢？其實這邊可以使用 LocalDB 在測試專案裡取代專案使用的資料庫，不過在使用上並不是那麼單純，因為 LocalDB 並不是在每種專案類型都可以加入使用的，像「測試專案」無法直接加入使用，不過可以改用別的方式作處理，這邊就說明測試專案如何使用 LocalDB。
這個部落格裡有關 DropDownList 的文章就寫了相當多，也因為這樣每天就可以看到有很多的流量都是來看這些相關文章，不過因為 DropDownList 的文章在每個不同的時期都有寫，有些文章會有提供比較完整的範例，而有些只有提供部分的內容，於是就乾脆把這些文章裡所提到的內容與程式都做了整理，然後把這些文章的範例程式都集中在一起然後放到 Github 上，讓大家可以方便去做瞭解。
這些範例程式有些部分是去年（2014） SkillTree 的 ASP.NET MVC 5 實戰營課程裡的範例，但不盡然全部相同，有做了部分的修改，這些大概只有佔 50% 左右，而另外則是重新部落格文章的範例程式。
在上一篇「Visual Studio 2013 - 建立 GUID」說明了當你的 Visual Studio 2013 裡找不到「建立 GUID」的功能選項時，應該如何重新找出這一個功能，然後在文章的後面也介紹了如何使用 ReSharper 的內建功能，快速產生不同格式的 GUID。
但是第一種情況並不一定每個人的環境都會遇到「建立 GUID」這個功能選項消失的狀況，而且內建的「建立 GUID」功能也算不上好用與方便，然後第二種使用 ReSharper 產生 GUID，並不是每一個開發者都有 ReSharper 的 License（因為這套件不便宜呀），所以這一篇就來簡單說明透過安裝擴充套件的方式來快速產生 GUID。
原本 VS2010 在工具選項底下還有個「建立 GUID」的功能，但是在 VS2012 之後這個功能就不見了，有時候為了要單純產生一個 GUID 或 GUID 字串還必須要多繞一點路，還真的有點麻煩。
這邊就來看看有哪些方式可以在 VS2012, VS2013 裡快速產生 GUID。
距離「ASP.NET MVC 專案分層架構」系列的第六篇到現在已經有兩年都沒有再開新篇，本來應該是要接著再寫第七篇，起初是因為沒有時間而一直延宕，但後來開始覺得我不曉得要如何寫接下來的內容，以致於這兩年多來都沒有任何的動作，一直到了今年 twMVC 的第一場研討會，才藉著這個機會將這個系列從第一篇到第七篇（只限定在研討會的 Part.7）給做個整理與說明。
時常會看到初學 ASP.NET MVC 的朋友在一開始進入學習或實作時總是會不知所措，如果是有 ASP.NET Web Forms 開發經驗的人但是對於物件導向、ORM 觀念和 LINQ 操作都不熟悉，之前比較擅長的資料操作就是 DataSet, DataTable，網頁就是在各種伺服器控制項或是在 Code-Behind 組字串並拋到前端處理，這樣類型的開發者在轉換到 ASP.NET MVC 時都會想要將以往 ASP.NET Web Forms 的開發經驗給轉移過去，但是兩種開發模式相差蠻大的，再加上觀念也有差異，所以在開發上就很容易陷入困境。
另外一種就是完完全全的初學者，可能之前沒有接觸過任何的網頁程式設計，或是有開發過其他技術的網頁程式，但是對於 .NET 這一塊領域並不熟悉，所以在很多觀念與操作上都相當生疏。
其實我一再地說，其實網路上有很多學習資源可以加以利用，只要肯花時間去從頭開始學起，基本上很多問題都會迎刃而解，但實際情況往往都是很多開發者都想直接跳過入門學習的階段，而想要直接實戰下去，這樣的學習往往會弄得自己千瘡百孔，搞到最後不是興趣缺缺、對 ASP.NET MVC 多有微詞之外，最怕的就是為了產出結果而搞出一些怪招怪式，這在往後的開發上是一點幫助也沒有。
這邊就直接以最基本的使用基架建立 C.R.U.D（Create, Read, Update, Delete） 的方式來認識怎麼開發 ASP.NET MVC 的第一課。
使用 CsvHelper 的讀寫操作在前兩篇都已經有說明了，如果需要更進階的操作說明，可以直接參考 CsvHelper 的文件檔或是直接到 Github Repository 裡面的單元測試專案裡去看，而這一篇則是再補上一些在處理 CSV 檔案讀寫時的方法操作說明。
使用 CsvHelper - Part.1 資料寫入
使用 CsvHelper - Part.2 資料讀取
上一篇介紹了如何使用 CsvHelper 將資料輸出到 CSV 檔案，既然有輸出，相對就會有讀取的需要，所以這一篇就說明如何使用 CsvHelper 將 CSV 檔案裡的資料給讀取出來。
最近有個要將資料寫入 CSV 檔案的需求，一般大家對於 CSV 檔案的處理應該就如同處理文字檔的方式一樣，但因為我需要寫入的資料並不是固定的一個類別，而是會因為不同資料處理而會需要將不同類別的資料給寫入到 CSV 檔案裡，像遇到這種需要處理不同類別的狀況時，我比較常看到的就是針對一個類別然後去寫一個相對應的方法去做處理，另外還有看到的就是建立一個很大的方法，在這個方法裡用 switch case 方式先判別進來的資料是哪一種類型，然後再去個別的做處理，其實第二種方法跟第一種方法並沒有什麼分別，不同的地方只在於第一種方法是分散的，而第二種方法是將第一種方法裡分散四處的 method 給集中在一起而已。
我是一個很懶惰的人，對於這樣的需求，我不太喜歡花太多時間去想應該怎麼解決，或是自己動手去寫程式來處理，因為我知道對於處理 CSV 資料的讀寫，一定早就有人去寫好程式，而我所採用的處理 CSV 資料讀寫工具程式就是「CsvHelper」，老早就已經注意到，只是一直沒有專案能夠用上，剛好現在的專案可以讓我實際的應用，所以就在這邊做個簡單的介紹。
這個系列的上一篇是在兩年多前，那個時候 ASP.NET MVC 還不算是太多人使用的開發技術，多數人還是在觀望的階段，但是這一段時間已經越來越多企業與開發者都已經將 ASP.NET MVC 技術應用在專案開發裡，而且在之後的 ASP.NET 技術發展中，似乎只有看到 ASP.NET MVC , Web API , SignalR 等的身影，而 ASP.NET Web Forms 卻不在其中 (?)，越來越多人投入 ASP.NET MVC 的開發領域裡，對於身為推廣 ASP.NET MVC 技術的一員，是很高興能夠看到這樣的情況，但另一方面憂慮的是，對於大部分想要踏進這個領域的開發人員來說，ASP.NET MVC 真的是進階不少（相對於 ASP.NET Web Forms）。
上網找文章、找線上教學課程、買書自學，這是大多數人學習 ASP.NET MVC 的途徑，畢竟實體課程是真的很少（所以有公司願意花一筆錢去找外面講師教 ASP.NET MVC，應該要好好把握機會學習，外面一次課程的學費是很貴的），這兩年多來是出版了一些 ASP.NET MVC 5 相關書籍，但並不是每一本都適合初學者看，甚至有些書也不適合進階開發人員看，而是給更為進階的開發人員看，但是一般開發人員對於這些書並無法分辨與選擇哪一本才是比較適合的，再加上前陣子有網友提出了這樣的問題，所以這一篇就針對正體中文（應該要正名為繁體中文）、簡（殘）體中文、英文有關 ASP.NET MVC 5 部分的出版書籍來說介紹（不是評論喔，因為我也不是每一本都看過）。
前幾天同事遇到了一個問題，在 ASP.NET MVC 網站裡要如何能夠正常的讀取放在 Area 根目錄下的靜態檔案？
如果靜態檔案是放在 ASP.NET MVC 的根目錄下的話，這還好解決，但問題是當這個靜態檔案是放在 Area 裡面的時候就會變得有些棘手，因為原本可行的解決方式在 Area 裡是行不通的，於是在就開始四處尋找能夠解決的方法，在搞了一個下午（中間還離開一個小時去開會以及進來好幾個需求插件），最後總算找出了一個解法，這邊就做個記錄，提供給大家作為參考，也尋求是否有更好的做法。
這句話對於終日面對電腦螢幕並且埋頭寫程式的開發者來說，應該是常常會被周遭的親朋好友甚至於是跟你不熟的人給問過吧，「你是程式設計師，這樣每天 Coding 的日子不會覺得很枯燥嗎？難道你要一直 Coding 下去嗎？」
這十多年來資訊產業蓬勃發展，但就本質而言，資訊業開發單位的職位與職務並沒有什麼巨大的差別，以致於會讓人覺得好像程式開發人員就得要每天 Coding，然後沒有任何的發展，最後就會想要轉換跑道去嘗試別的職務，甚至是乾脆轉行不再寫程式，比較極端的就是去賣雞排，當然不是說賣雞排不好，而是當你放下多年的專業然後轉換另一種工作，需要從頭熟悉與你原有專業技術相差許多的技能，這過程是相當艱辛的。
當你開始對工作厭煩然後開始經常沒來由的問自己「我還要 Coding 多久?」時，你已經陷入了自我質疑的迷思之中，開始懷疑自己的能力、質疑自己的工作、抱怨環境、抱怨同事等等等，除了這些懷疑、質疑、抱怨之外，你還可以做些什麼呢？
上一篇「調整你的 Visual Studio - Part.1」介紹了一些有關我常用的 Visual Studio 配置設定，以及我所使用的擴充功能，就如同在那一篇的開頭所說的，並不一定我所使用的配置設定就適合所有人，也不一定每個人都能夠認同，就拿文字編輯器的行號顯示來說，就有些朋友認為不需要讓行號顯示出來，因為會讓他們覺得礙眼，還有就是顯示行號會佔用了文字編輯器的顯示空間，諸如此類，我所介紹的內容只是讓大家做個參考，如果你們已經有習慣並且有更好的配置設定，就不需要去做改變，如果你的配置是沒有做任何的改變或是調整，那麼可以嘗試我的介紹，並且去習慣這樣的改變，相信這樣的改變會讓你在開發上有更好的幫助。
上次有講到「Productivity Power Tools」這個幾乎是每個使用 Visual Studio 的開發者必裝的套件，其實還是有些配置設定是可以介紹的，這次會做一些說明（但不會說得太多）。
這個跟前一篇「調整你的 Visual Studio - Part.1」並不是同一個系列的，這一篇純粹在說程式碼度量（Code Metrics）這件事，相同主題的文章其實 91 哥就有寫過並且說明程式碼度量裡各種指標所代表的意義，
[Tool]Visual Studio 2010 - 程式碼度量 - In 91- 點部落
這篇除了會說明怎麼在 Visual Studio 裡使用程式碼度量之外，也將會介紹另一套同樣是作程式碼度量的擴充套件「Code Metrics Viewer 2013」
這個題目很難定，因為每個人的 Visual Studio 開發環境不盡相同，我所建議的調整項目不見得適合每一個開發人員，有些大師使用著初始預設值設定的 Visual Studio 進行開發也一樣能夠寫出高深莫測的專案，但這是少數中的少數，並不是所有的開發人員都可以跟大師一樣，每個人完成安裝 Visual Studio 之後一定會做些環境設定調整、安裝熟悉以及慣用的套件，但還是有蠻多開發人員並沒有好好地將 Visual Studio 做調整與修改，反而浪費了有著地球上最強 IDE 稱號的 Visual Studio。
所以這邊提供我的 Visual Studio 環境設定項目，包含了曾經陸續發表的一些文章，例如 Visual Studio 套件、設定等，將這些調整給大家做為參考，這個主題應該會成為系列文章，畢竟安裝的套件以及修改的設定也不在少數。
有關資料分頁的做法已經寫了許多篇文章來說明，而這一次的做法其實跟之前的也沒有什麼不同，使用的方法也沒有什麼不同，這邊只是使用「ASP.NET MVC 使用政府公開資料」這個範例繼續做延伸，在現有的範例程式裡再去做變化，而且「ASP.NET MVC 使用政府公開資料」這個範例有使用到 Async/Await 的非同步做法，不過實際在做的時候其實也與沒有使用非同步的一般做法是沒有多大的差別。
ASP.NET MVC 使用政府公開資料
ASP.NET MVC 資料分頁 - 使用 PagedList.Mvc：AJAX
這一篇所使用的範例程式將會延續之前文章所使用的程式內容：
ASP.NET MVC 使用 Entity Framework Code First - 基礎入門
ASP.NET MVC 使用 Entity Framework Code First - 變更多對多關聯資料
ASP.NET MVC 實做具有多個角色權限的登入功能
另外文章裡將會使用到「devart LINQ Insight」這個工具，之前也曾經有寫文章介紹過：
對於一直習慣操作資料庫 T-SQL 語法來存取資料的開發人員來說，因為在開發系統時，對於程式裡需要什麼樣的資料都會使用 T-SQL 語法組合出查詢指令碼然後放到程式裡，最後就是直接使用 ADO.NET 去取得想要的資料，但是對於要轉用 EF 去使用 LINQ 下查詢，在各個物件關聯裡去取得想要的資料，很多人就會有相當大的觀念衝突出現，尤其是這種多對多的資料查詢與取得，就會讓許多人卡很久。
在這篇文章作簡單的說明，如何在多對多關係裡去取得擁有指定系統角色的所有系統使用者資料。
