軟體主廚的程式料理廚房

部落格的文章我一直是用 Markdown Monster 寫完後，直接 Ctrl + Shift + C，Markdown Monster 會直接幫我將文章轉成 HTML 內容寫入到剪貼薄中，接著在點部落的編輯器上切換原始碼，再把 HTML 內容貼上去，但是最近點部落的編輯器改版了，沒辦法直接貼上 HTML 原始碼，可是 Markdown Monster 複製的 HTML 內容居然貼得上去，這其中必有緣故。

最近 IL Code 寫得比較多，主要是在練習，目的是希望自己將來遇到效能議題的時候，還有招數可以施展，剛開始練習寫 IL Code 的時候，是先從存取一個 instance 的公開或私有的屬性及欄位開始，這讓我想到一個套件 - FastMember，作者已經至少有 2 年沒有更新了，既然會一點 IL Code，那我能不能弄一套屬於自己的 Chef.FastMember 呢？

在先前的文章有提到過「在執行時期憑空捏造一個組件」這件事，我是用在自己打造的 Library 之中，而做這件事的最主要目的是在執行時期產生一個類別，用來產生使用端類別的替身，或是用來做一些特殊的識別，我們就來看一下，要在執行時期產生一個類別，需要做哪些事情？

上一篇文章有提到學著讀或寫 IL Code，對我們在程式執行狀況的掌握，有正向的提昇，那麼其中一種學習方式，就是透過我們平常撰寫的程式碼，看看它編譯出來的 IL Code 長什麼樣子，藉此來理解 IL Code，本篇文章就來介紹兩種查看 C# 編譯出來的 IL Code 的方式。

程式寫多了，我們多多少少會開發一些 Library 來輔助我們讓程式寫起來更方便一些，這些 Library 通常都獨立於專案之外，除了使用上的彈性之外，還有一個我們會關注的大概就是效能了，既然提到了效能，我們腦海中閃過的解決方案應該會有「撰寫 IL Code」這個選項，IL Code 雖然可讀性極差，但是如果我們有能力可以讀得懂，甚至使用 IL Code 撰寫程式的話，對我們在程式執行狀況的掌握，絕對有正向的提昇。

我就用 IL Code 撰寫一段將值指派給私有欄位的程式來當個起頭，之後如果還有遇到 IL Code 可以發揮的地方，我也會儘量整理成文章分享給大家。

最常見的依賴注入（Dependency Injection）方式，就是從建構式上面，將依賴的服務一一注入，但是實務上多多少少會有一部分的 Instances，在服務被釋放之前都沒有被用到，雖然一般來說，產生 Instance 的成本不大，不過我還是想試一下，能不能將依賴注入這件事移到執行的目標方法裡面，在方法裡面有用到的服務才注入，所以就有了「延遲依賴注入（Lazy Dependency Injection）」這個題目。

在 .NET Framework 中，無論是 App.Config 或 Web.Config，均有保留 <configSections> 讓我們可以自訂設定區塊（ConfigurationSection），由於曾經看過有一些 Library 把設定值放在節點之中，像這樣：

等到要自己弄的時候才發現，似乎沒有那麼簡單，網路上搜尋到的有關於自訂 ConfigurationSection 的文章，大都沒有提到這一塊。

這是無意中發現的一個語法，它的使用情境是這樣的，如果我們有一個型別是自訂類別的屬性，並且在建構式中有針對該屬性做初始化，在初始化後想要接著修改該屬性中裡面的屬性值，C# 的 Object Initializer 有一個簡便的語法 Xyz = { ... }。

看到 Bill 叔在 twMVC#39 講的 Compile-time weaving 的 AOP 框架 - PostSharp，勾起了我的 AOP 魂，隨手 Google 了一下，讓我找到了一個 Open Source 的框架 - AspectInjector（看名字我還以為是某個 Dependency Injection 的套件），看它在 GitHub 的介紹裡面下了 postsharp 的標籤，似乎有向 PostSharp 看齊的目標。

使用 log4net 有好些年了，但是這個開源專案目前處於休眠的狀態，慢慢凋零了，所以決定將手上的專案轉使用 NLog，過去開發的幾個在 log4net 上的 Appender 現在必須要轉成 NLog 的 Target，我就以 Slack 的 Incoming WebHooks 為例，將它做成一個 NLog 的 Target。