在這個時代做程式設計，通常不會自己造輪子，都是使用別人做好的工具居多，難免會出現鬼打牆的情況，倒不見得是工具本身有 Bug，大多是我們對於工具內部的運作機制不熟悉的關係，這時候有原始碼可以參考的話，就能方便我們去處理問題，如果還能建置起來進去工具內部追蹤程式碼，更能加快處理問題的速度，以避免鬼打牆的情況持續太久，這篇文章就來記錄一下如何用 Visual Studio 2019 建置整個 ASP.NET Core 框架？
這件事情是這樣的，在 ASP.NET MVC 有一個 Display Mode 功能，我們公司把它應用在 AWD（Adaptive Web Design） 機制上，雖然在 ASP.NET Core 被拿掉了，但是我們可以實作 IViewLocationExpander 把它給弄回來，某天發現某個 Mobile 網頁的內容套到了 Desktop 版的 Layout，百思不得其解，最後爬了 ASP.NET Core 的原始碼才知道怎麼回事。
當我們把大部分的運算移往前端瀏覽器時，難免會遇到需要一個相對準確的當下時間，我們都知道客戶端的時間是不可信的，有可能使用者從來不校時，或是使用者有屬於自己的時差，又或者使用者與之校時的伺服器，其時間根本就是錯的，種種原因都造成客戶端的時間不可信，面對這個問題，我們第一時間想到的大概就是做一個取得後端伺服器時間的 Web API 給前端使用，這篇文章要來分享儘量不透過後端 Web 應用程式來取得伺服器時間。
一般我們如果打造的系統是給企業內部使用的話，走的是 Intranet，大概不會有程式設計師會去在意網路流量，當應用場景搬到了 Internet，流量成為企業經營成本的時候，那可是能省則省，因為在網際網路上大多數的內容，觀看者是沒有直接為這些內容付費的，成本當然能少一點是一點，這篇文章就要來介紹 WebMarkupMin 這個套件，將我們的 HTML 內容做最小化，減少不必要的傳輸流量。
關於如何發佈 ASP.NET Core 應用程式到 IIS 上，官網上的這兩篇文章說得很清楚。
照著官網的步驟弄，一切還算順利，但還是遇到了一個小亂流，在執行 WebDeploy 的命令時，出現了「error MSB6006: "msdeploy.exe" 以返回碼 -1 結束」的錯誤訊息。
我們有使用 Bundler & Minifier 來幫助我們將自己撰寫的 JS/CSS 檔案打包跟做最小化，但是 ASP.NET Core 專案在發佈的時候，預設會連同原始檔案也一併發佈出去，多了一些無謂的檔案，因此我們會希望專案在發佈的時候，不要輸出這些檔案。
以往我們都是透過組態（Debug|Release）來輸出不同環境的設定，這件事情到了 ASP.NET Core 則改由環境變數（Environment Variables）來控制，至於 Console App，網路上查到的資料也都是教我們用環境變數來控制設定的輸出居多，難道我們不能跟以前一樣使用組態來控制嗎？
ASP.NET Core 在發佈的時候，會將 Razor View 採用預先編譯的方式，這一點改變讓 Web 應用程式啟動得更快，但是在開發時期也是這樣就讓我挺不習慣的，原本我以為在開發時期即時編譯 Razor View 的功能，會在 Visual Studio 2019 v16.6 加進來，不過它似乎提早了
ASP.NET Core 的 ResponseCache 觸發伺服器端快取的條件尤為嚴格，限制很多，這也是它跟過去我們所熟悉的 OutputCache 特別不一樣的地方，所以 ResponseCache 我們也沒辦法就這樣直接當做 OutputCache 來使用，缺的部分我們只好自己來補足。
之前有寫過一篇在 IIS 用 URL Rewrite 解決 SEO 要求網址全小寫及有無斜線結尾的問題，到了 ASP.NET Core 雖然沒有 URL Rewrite 擴充套件可以安裝，但是有一個 URL Rewriting Middleware 可以來幫助我們做到一樣的事情。
