[WorkLog] Testing Gmail SMTP utilize SmtpClientTest : 使用 SmtpClientTest 測試 Gmail SMTP

Combo2

今天早上協助客戶排除電子報系統無法寄送 Email 的問題，處理的差不多之後發覺這系統的 SMTP 設定還是得加個可輸入帳號密碼去做寄件驗證的功能（對！本來沒做 = = 但其他用相同系統的專案也是活得好好的...），不然的話正式上線時問題會更大。

相關程式加上後，在我的本機（Win7 Pro 64-bit）試著用 smtp.gmail.com 加上我個人的帳號密碼去測試寄件驗證，嗯～一切正常，該寄送就寄送，該失敗就失敗。就繼續更新到測試機上（Win2008 64-bit），結果，寄送失敗 Orz

Spring.NET Objects Checker 用來檢查你的 spring-objects.xml 內容是否正確

這幾天花了點時間寫了這個工具，主要原因是自從我在新公司開始接觸 Spring.NET 後，
在於團隊開發後的除錯(Debug)上，有時候會在 Spring.NET 的物件定義 XML 設定檔這
花上不少時間，大概情形如下，

『用了 Spring.NET 的 XML 設定後，衍生的特性是
「建置(Build)成功的定義不一樣了」，
原本的建置成功代表的是「程式中類別、方法的定義，使用端的呼叫都正確」，
現在的建置成功只有代表「程式中類別、方法的定義都合乎語法」，
「使用端的呼叫是否正確？」請執行已建置好的執行檔或網頁，We will see.
這產生了一個新的現象，專案開發中，發生
「建置成功，但不能執行」的機會提高了，變得更容易發生的原因可以很簡單，
例如：
　我寫了某支規格的 Dao.cs, IDao.cs, Domain.cs, Service.cs, IService.cs, (Spring)Objects.xml, Core.csproj, UI.aspx，
建置並執行沒問題後，Commit 到 Subversion 時漏掉了其中一個或以上的檔案（通常是 Core.csproj）， 然後繼續做下一支規格。（這代表的是，下一個 Commit 的人要倒霉了，不，也許是下下下一個 Commit 的人）」
至於下一個 Commit 的人為什麼會倒霉，這邊我就不詳述了。

而我對於這個情形的結論是「在還沒有適當的工具可以一次找出 objects.xml 中的錯誤之前，就只能請 Program Analyst 的要求再多一點了』
以上，既然還沒有適當的工具，那麼...就自己寫吧！