在Unit Test時最讓我煩惱的是測試時的測試資料，為了讓每一次測試是一致的受測資料，且不被外在環境干擾，有試過很多方法，如在開始測試時新增測試資料到資料庫，測試時只用這些資料，結束測試時刪除測試資料，或是先準備好內有測試資料的mdb每次測試時複制mdb，不斷的掛載與卸離mdb，說真的這些方法都很蠢，不好維護且各個測試又容易互相影嚮(本測試寫了一筆資料，可能影嚮了下一個測試的結果)，寫到最後我就放棄寫需要連資料庫的任何Unit Test，直到前陣子看到有人使用Entity Framework然後使用Mock ObjectContext，決解了測試時需要使用到資料庫這個外部資源，讓Unit Test更Unit，我又開始在新的專案中寫Unit Test。
我想在大量Ajax的網站中，一定時常以Json做為資料傳遞，但預設的情況下，Json的資料不會對應到參數，必需寫程式做額外的轉化，有點麻煩，而且也限制了參數的格式，但MVC 3增加JsonValueProviderFactory解決了這問題。
有個外包專案，用TFS管理Code快一年，後來客戶接手回去，希望有歷程記錄，但覺得TFS 2010太貴了不想買，希望轉成SVN給他們，我就找了一下網路上的轉檔程式，雖然有不少如tfs2svn，但都只支援TFS 2008，這時我會成為Developer的理由又出來啦，沒人寫，難到我不能自己寫嗎!!就把tfs2svn的源始碼下載(Open Source真好)，修修改改快一個星期，終於可以把 "這個專案" 從第一個Changeset 完整的轉到最後一千五百多個Changeset，所有的歷程都有保留，用WinMerge比較TFS與SVN的最後一個Checkout，100%相同，不過呢?當寫完熱忱好像也用完了，一點也不想把他美化與增加UI，但是呢?這個專案本來就是分享別人的成果改的，我想也應該把他分享出去，一般的TFS 2010的專案我想應該都可以轉換，不過畢竟我只測試過一個專案而以，不保證一定可以轉成功，這時如果你也是Developer就可以下載源始碼來修改。
這是小弟第一個Visual Studio 2010 Extesnion的程式，寫起來不難也不花俏，但滿實用的小套件。
寫這個套件的最初的理由是希望一行Code都不改，就可以將清單匯出成Excel，因為原本每一個匯出Excel的需求，都要額外寫一個Action去處理，非常的麻煩，而且大多數的Code都是雷同的，所以就想了個辦法做抽離，讓整個站台完全不用寫任何的額外Code(或是改一點點)，再搭配這篇所寫Excel產生器，達到快速匯出的功能。
因為客戶太多的匯出Excel的需求，每次都要寫一大串的Code去處理，越寫越多就覺得自己很笨，寫了一堆重覆Copy-Paste的Code，因此想了一個以Template的方式，不同的需求只要寫不同的Template，只要改一下Template就可以快速產生不同的Excel，Code變漂亮了，也大量減少了這類需求的工作量。
有時一些簡單的流程控制，會把一些條件判斷寫在Database或config中，程式在執行時再剖析條件，來判斷流程是否可以進行，最早是自己寫剖析器然後反射取出值後在比對，因為自己功力有限，剖析的內容也有限，後來有嘗試使用CodeDOM，但使用上太麻煩，而且只為了短短的幾行，有殺雞用牛刀的感覺，後來.Net Framework3.5推出LambdaExpression後，這輕巧可以動態編譯產生Delegate，太適合用在這種情況，但是內建是沒有剖析器的，不過還好有現成的組件，可以輕鬆的將String轉成LambdaExpression。
這是Entity Framework批次Update與Delete這一篇的改進版，程式碼重構與加強了Expression Tree的解析，常見的情況都有支援，改用ADO.NET內建的參數。
前陣子在使用Microsoft Ribbon套件時，很簡單的就把自己的程式的樣式，用的像Windows Live Writer 2011一樣，而且一點也不覺得很突兀，那時就很好奇它是如何在視窗的標題列上加入控制項的，如果我不用Microsoft Ribbon我要怎麼樣做到同樣的效果，搜尋後找到原來是使用Desktop Window Manager(簡稱DWM) APIs，DWN APIs可以讓我們的程式使用Windows內建的框架，不用自己處理關閉或放大縮小等事件，可以在現有的機制上擴充按鈕或其他控制項，除了可以大幅增加設計的空間外，有時候把全域的控制選項放在邊框上，還可以大大的增加使用的便利性。
Core Audio APIs是在Windows Vista之後新增的API，主要是用來音效的處理，例如取得錄音與播放的裝置與資料與設定，聲音音量的控制與混音器，Stream的播放與錄制等等功能，在多媒體APIs中它是屬於比較低層的API，如果是要錄音或播放聲音，用這個API操作上會複雜些。
因為希望某一個相關的程式寫好，不用做任何的設定就可以直接使用，這個需求我使用搜尋整個AppDomain下的Type，只要符合我自定的Interface或Base Class，就可以運作，這方法雖然有點取巧，但還滿好用的
因為覺得Console程式在執行時，Titlebar與Taskbar上都出現預設的Icon有點醜，就研究一下怎麼設定，還滿簡單的。
因為工作中的專案有二台不同地點的主機，有資料同步的需求，而這個專案中我們是用WCF + MSMQ來處理資料交換，為了確保資料的完整性，有使用交易性的MSMQ，在WCF的預設機制下一個Message交易失敗十幾次後會把Message移到Poison的目錄下，可以知道有那一些Messqge處理失敗，但是用Windows的工具非常不易閱讀Message的內容，而且某些設定還會使得Message經過編碼，這時就很難看出Message的內容，本篇主要介紹如何用程式把Messge讀出並解碼。
前陣子團隊中有用XmlSerializer將物件轉成XML存檔後，上傳給另一家公司，對方卻一直回報我們XML有問題，用文字編輯器看格式都很正確，但用XML的編輯器卻會出錯，發現原來是BOM害的。
IoC(控制反轉)是時下很流行的設計模式，它可以大大的簡少程式之間的相依性，有點像工廠模式，在Class中操作的都是Interface，而Interface與Class的對應與建立實例都是由IoC Framework處理，光是在.Net Framework下的IoC Framework就有近10套，每套都有各自的優缺點，呼叫方式也略有不同，切換IoC Framework是非常麻煩的，或是開發組件(Assembly)，組件也是使用IoC，但是又不能限制使用端用特定款IoC Framework，這時候可以考慮使用IoC的中繼器:CommonServiceLocator來解決這個問題。
有時Web Project會有一些檔案在不同專案間共同使用，如Javascript檔、圖檔、第三方套件等等，如果每一個專案都放置一份，很容易照成維護上的麻煩(如修改A專案的檔案，忘了複製到B專案)，這時可以調整一下檔案的結構與修改一下專案的設定來解決這問題(這是小弟最近建方案的心得，不一定是最好的)。
在與很多系統做資料交換，有些交換檔是以Big5編碼固定Bytes的定寬格式，因為在.NET中任何文字包含中英數字或符號都是一個Char，但Big5編碼英文是1Byte、中文是2Byte，所以不能以文字的長度來截字或補空白，小弟我想到的是轉成Bytes來處理。
因為Moles官方暫時還沒有辦法解決，讀取測試專案的app.config問題，我只有以繞遠路的方式去跳過這個問題，我最早的方式是手動去改Microsoft.Moles.VsHost.exe.config(詳情可參考Moles - Isolation framework for .NET介紹)，而我們專案成員有5個加上1台Build Server，所以我要設6次，本以為設定一次就搞定了，但因為前幾天app.config的設定有變更，我一想到要改6台我就累了，而且當方案一多切換也是個麻煩，所以我想到以Post-build Event的方式，當從版本管理簽出後編譯完成時將測試專案的app.config去覆蓋Microsoft.Moles.VsHost.exe.config。
有時專案載入了有x86版與x64版的組件，因為萬惡的Visual Studio 2010是x86版，所以在開發時必需使用x86版本的組件，但是Moles預設是使用x64的執行檔，所以二著相衝，編譯就失敗了，不過還好可以在MSBuild中設定來解決問題。
在與很多系統做資料交換，有些交換檔是以Big5編碼的固定Bytes的定寬格式，因為在.NET中任何文字包含中英數字或符號都是一個Char，但Big5編碼英文是1Byte、中文是2Byte，所以不能以文字的長度來截字或補空白，小弟我想到的是轉成Bytes來處理。