上一篇提到我們可以把 ASP.NET Core Feature Flags 的設定，儲存在 Azure App Configuration（應用程式組態）裡面，現在再進階一點，我們可以實作 IFeatureDefinitionProvider 建立一個 Feature Definition Provider，讓 Feature Flags 的設定可以儲存在我們想要的地方。
ASP.NET Core 的 Feature Flags 設定，在這之前的範例都是存放在 appsettings.json 裡面，在官方的文件中是建議我們把它存放在外部的儲存空間，這樣我們可以隨時修改 Feature Flags 的設定，也方便我們管理，那我們就跟著官方的示範，將 Feature Flags 的設定存放到 Azure App Configuration（應用程式組態）中。
上一篇文章對 Microsoft.FeatureManagement.AspNetCore 這個套件做了一個最基本的介紹，但是 Feature 只能設定開啟或關閉，顯然地這有點不夠用，所以套件有提供了一些 Feature Filters 用來實作有條件地開啟或關閉 Feature。
Feature Toggle 這個議題最近挺夯的，它達到的效果就是我們透過設定，就可以輕易地開關應用程式上的功能，讓開發好的功能可以真正地發佈到 Production 上，但是不相關的使用者不會受到該功能的影響，也方便我們去測試只有在 Production 上才能測試的案例，而 ASP.NET Core 已經有套件支援 Feature Toggle，我們來看一下怎麼做？
在這個時代做程式設計，通常不會自己造輪子，都是使用別人做好的工具居多，難免會出現鬼打牆的情況，倒不見得是工具本身有 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 專案在發佈的時候，預設會連同原始檔案也一併發佈出去，多了一些無謂的檔案，因此我們會希望專案在發佈的時候，不要輸出這些檔案。
Developer Technologies (2016-2024)
