這是一個不錯的 .NET 學習網站，網站雖然是英文內容，不過使用的英文語句淺明，很容易閱讀。它可以讓一個新手很容易的瞭解甚麼是 .NET，也可以從中學習，由一個新手到進階的 .NET 程式開發者。另外，我在裡頭也發現了寶，底下這一篇關於 C# Coding Standards 的文章: http://www.dotnetspider.com/technology/tutorials/bestpractices.aspx 閱讀完給了我很多的感想，即使你認為自己可以很順手的使用 VS.NET 進行程式的開發，也需要看看這個文件。
寫 .NET 應用程式也有一段時間了，大多數的應用程式都是放在 Server 端的應用，如 SharePoint Webpart 及 Web Service 等，最近的一個專案是較另類的，寫的是視窗的應用程式，由於是要將程式 Deploy 到使用者手上的，特地將以前不是那麼在意的 De-Compiler 程式找了出來跑跑看，嚇了我一大跳，這玩意兒不就是 Open Source 嘛?! 我使用的是 Remotesoft 的 Salamander .NET decompiler，先前曾經嘗試著用它來 De-Compiler 幾個 SharePoint 2003 Server 的應用組件，為的是瞭解原 Class 的運作模式，現在應用到了自己寫的視窗程式中，發現所有程式碼都露了出來。本來在 Deploy .NET 的應用程式的時候，我們通常都會使用 VS.NET 2003 所附的 Dotfuscator Community Edition 來對 MSIL 進行模糊化的動作，但是，這個動作並不會對程式中的字串進行編碼，其它商用的模糊化工具或許可以增加點閱讀難度，但是還是會使這些資料曝光，實際上是，只要 .NET Framework 可以解釋你的 MSIL，那就可以利用軟體反向工程來作解碼的動作。某些敏感性高的字串資料，如 SQL 的連線 UserID / Password 放在程式碼中是很不安全的!!記住，無論使用了多高明的模糊器，你只能拿來欺騙自己，讓自己多一份安心。 我們可以由 .NET 執行的機制中清楚的知道，在你編譯你的程式碼之後，所得到的並不是一個 Native Code，它實際上是一個 MSIL，當你執行 MSIL 的時候，你的 .NET Framework For Windows 會轉換它，成為該平台上的 Native code (這時就跟 CPU 與硬體有關了) 然後再執行。所以只要 .NET Framework 可以解釋 MSIL，反組譯當然也不成問題。這個機制也成就了另一個好處，那就是『跨平台』，.NET 應用程式實際上是可以跨平台執行的。如果有一個 .NET Framework For Linux (微軟不開發，但是我們已經有了個 MONO 的 Open Source Project)，相同的 MSIL 程式也會由這個 Framework 來解釋為該平台上的 Native code (硬體系統架構不同) 執行，所以你的程式才能夠跨平台執行。 ...
有的時候你只是要寫一段簡單的 Code 來測試功能，開啟 VS.NET 這個龐大 IDE 怪物的速度常常讓你受不了，這個時候你可以使用 Snippet Compiler 這一個簡單的 IDE，嚴格上來說，它挺適合用來寫 Console 程式的。Snippet Compiler 是我在讀其它 .NET Programmer 的建議工具裡頭看到的，自己平常就會寫一些簡單的 Console 程式來作為應用系統的 Admin Tool 或是 Conversion Tool，後來拿這個工具寫幾個 Function 並測試比較 Function 間執行的速度，發現也挺好用。 當然你也可以拿 Snippet Compiler 先撰寫，並測試好一個可用的 function，然後再貼到在 VS.NET 上的專案中使用。最少，它的開啟速度比起再開一個 VS.NET 要快得太多了。也許以後它可以用來取代 VS.NET 的 IDE 也說不定呢!!目前來說，在寫 Console Application 是如此。 下載點: http://www.sliver.com/dotnet/SnippetCompiler/ 作者網頁上還有很多好玩的東西: http://www.sliver.com/dotnet/
今天在跟微軟的人開會的時候，吉米老兄提出了一個問題，就是在應用系統中若使用 AD 整合認證的話，有沒有可能使得 Active Directory 的管理者擁有專案系統的最大權限，造成機密資料的外洩？台灣微軟人員提出了一個合理的解釋: 我們應該將這種情況分兩個動作來解釋，那就是『認證』及『授權』，一般來說 AD Server 只是處理了認證的問題，真正需要授權給登入使用者的是應用系統本身。 這是一個很合理的解釋，在系統設計的邏輯方面也能夠說得通。一般來說應用系統的管理人員不一定就是 AD 的管理人員，應用系統管理人在自己的系統中可以自行設計權限管控的群組分類以及指定群組人員，不受到 AD 的限制，當然，他也可以把 AD Administrator 排除在應用系統的管理者群組之外。但是，吉米老兄的懷疑也不一定是錯誤的，既然 AD 管理者所擁有的權限可以至 AD 層面，我們的應用系統也是處於完全相信 AD 所進行認證的結果，那麼，是不是有甚麼邏輯上的漏洞會產生?? 會中微軟人員的說法是，AD Administrator 雖然是一個 AD 的管理者，但是他並不能夠假冒任何人的身份進行登入，這也是一個很合理的說法。會後，我再仔細的想了一下，這種設計的確是有邏輯上的漏洞，首先，當應用系統設定了 AP_ADMIN 的群組，並將此群組設為應用系統的 ADMIN，AD Adminstrator 肯定擁有 Account Operator 的權限，他可以設定或指派某人加入 AP_ADMIN 的群組，若他存有不道德的私心，他可以將自己的帳號設定進這個群組中，當得到機密資料，並刪除登入及動作的日誌後再將帳號自管理群組中移除。 應用系統管理者要避免這種情況，首先自己的應用系統不能完全的相信 Domain Admin，在設定 High Confidential 群組時，應該避免指派 AD 中的群組，而直接分別指派 AD User。但是，我們並不能避免 AD Admin 嘗試修改 AP Admin Users 的密碼來達到其獲取進入系統特殊權限的目地，也就是說，無論如何此種威脅都是存在的。 這個問題的答案已經很明顯。 企業主若不相信單位中的 AD Admin，建議你換個可以信任的人，以免夜長夢多。若是真有非常敏感的資訊，而單位 AD 中的 User 數量又非常多，怕不好管理的話，可以嘗試將 AD 進行分支管理，讓最上面的管理者是個可以相信的人，大量的，不敏感的人員資訊可以分屬在某個分支交給其它管理人員管理，而具有高機密群組及人員，另外放在專屬的分支控管，這樣會比較容易些。 突然間想到電影 Spider Man 2 裡頭的這一段話，作為標題。IT 人員的責任也是取決於自身在電腦工作環境上呼風喚雨的能力，會這樣被 User 懷疑也是沒有辦法的事呀… ...
很多範例程式都要用到這一個資料庫檔案，乾脆在這裡放一份好了。 Download file
在前面一篇 DataGrid 欄寬自動對齊 (Autofit) 中提到了欄寬自動對齊的方法，這是一個在討論區中找到的一段程式，相同的一段程式碼，日前運用在工作的專案中列印功能時，發現它有一個小小的 BUG，就是它在比對字串的時候沒有使用字串圖形寬度作比對，而是用字串本身的字元長度作比對，這其實會造成比對結果的失誤，因為字串顯示在螢幕或是列表的時候，是以圖形寬度放置的，針對不同的字形，寬度比對會有問題。所以我對該段程式再作了一點小修改，使用了圖形比對方式，讓它可以實際的應用在螢幕上的呈現及列表應用而不會出狀況。 以下為修正後的程式碼，使用 C#: private void AutoFitDataGrid(DataGrid oDataGrid, System.Data.DataTable oData, int nColumnPadding) { int nColumnWidth; int nHeaderWidth; Graphics g = null; string strValue; int iMax = 0; int iStr = 0; DataGridTableStyle dgts = new DataGridTableStyle(true); dgts.MappingName = oData.TableName; oDataGrid.TableStyles.Clear(); oDataGrid.TableStyles.Add(dgts); try { g = CreateGraphics(); foreach(DataGridColumnStyle oColumnStyle in oDataGrid.TableStyles[0].GridColumnStyles) { foreach(DataRow row in oData.Rows) { try { strValue = row[oColumnStyle.MappingName].ToString().Trim(); iStr = g.MeasureString(strValue, oDataGrid.Font).ToSize().Width; if (iStr > iMax) iMax = iStr; } catch { iMax = 0; } } ...
這兩天發現 Visual Studio .NET 2003 在啟動的時候會延遲個將近一分鐘，本來以為是系統的問題，重新執行安裝程式中的修復功能(未解)，重新安裝中文版本(未解)，再裝回英文版本也未解決此問題(裝過的朋友知道這樣的過程至少得花上三個小時)，另一台電腦上的環境則正常。後來 Google 了一下，發現有許多人有相同的問題，感覺這應該是 VS.NET 2003 開發環境的 BUG，但是微軟並未因此而有更新程式。網路上眾多程式開發者的解法都是相同的，最簡單的方法是使用 Developer PowerToys 網頁中的 VSTweak，將 MRU 的 Files 及 Projects 清空，應該是 IDE 啟動後有嘗試在讀取 Most Recent Unit/Projects 方面的程式出了問題吧!!希望 2005 版不要再有相同的情況囉。 Developer PowerToys: http://www.gotdotnet.com/team/ide/ VSTweak Download: http://www.gotdotnet.com/community/workspaces/viewuploads.aspx?id=b9330ea5-096d-45b7-8a5b-17450d7a0d5a PS. 我曾嘗試使用 RegEdit 清空此程式在 Registry Key 中的 MRU 相關鍵值，但未解決此問題，VSTweak 卻可以刪? 不曉得這是甚麼原因呢!!… :p
昨天下午 Notebook 狂當，藍底，沒有自動 Reset，還得按著開關四秒才會斷電，重開機成功的機率約為 1/15，回家後還是搞定不了它，決定送修。Check 了一下 COMPAQ Care 的電話，打過去的語音說明了服務時間是 10:00 AM – 08:00 PM。今天早上撥電話過去確定了地址後送修。 服務中心接下電腦後問明原因，告訴我是要拆機才能夠確定問題，我說明了我很急著使用電腦，工程師出現，進行初步的檢修，發現是主機板的問題，幫我詢問是否有料件可以更換，約需一個小時的時間，填單 (10:50 AM 收單)。在光華商場附近晃了一下，等著服務中心的回覆，11:20 通知有料可以更換，12:40 通知可以取件。 感謝 COMPAQ Care 服務人員的辛勞，你們快速親切的服務令人難忘。 Thanks AGAIN!! PS. 機器取回後處理速度變快了，不曉得是不是壞掉前就已經開始老化致使速度變慢。 送修機型為 EVO N1020V，工程師說損壞原因是 “自然損壞“… -.-” 保固內維修，It’s Free, No charge !!!
本來是想寫個 V1.0 正式版的消息，但是漲價的消息比正式版本發佈要來得令人震憾，原本還怕會打不完已經買了的 Credit，沒想到費率不降反漲，現在看來不怕打不完了。Skypeout 服務不曉得甚麼時候漲價了，剛剛 Rickz 在 IRC 說了我才看到，發現 Global Rate 已經漲到 0.017 歐元，也只含蓋到了 22 個地區，有許多原來在 Global Rate 中的地區已經被排除了，請使用 Skypeout 的朋友要記得時常查看一下費率。目前中國大陸費率為 0.022 歐元，至於台灣的市內電話跟行動電話都已經不符合經濟效益了，很令人失望。 新版本 V1.0 發佈了，已經不是 Beta 版了… 嗯，比較沒有興奮感。 目前費率請見: https://secure.skype.com/store/help.pricelist.html?service=pstn
在 MS-SQL 中資料庫的 Log 使用越久會越來越大，某些時候我們是不需要這個 Log 中的資料，這時我們就可以使用 Database Shrink 來將這些資料移掉，最簡單的方式是設定一個批次檔 (Shrink_Log.BAT): REM This is for shrink the log size of DB osql -U sa -P password -s servername -Q “BACKUP LOG dbname WITH NO_LOG” osql -U sa -P password -s servername -Q “DBCC SHRINKDATABASE (dbname, NOTRUNCATE)” 將以上的 password, servername, dbname 取代為你的環境即可。