The Will Will Web

Mono 2.4.2 已釋出，除了修正超過 150 的 Bugs 外，這一版還有個特點就是正式支援 ASP.NET MVC 的執行環境，以及 C# Shell 可以讓你把 C# 程式碼檔 Shell Script 來執行，而這兩個功能正是我想要的。

目前來說 Mono 還算有些大大小小的 Bugs，我個人是不建議用在正式環境(Production)，不過有空的時候玩玩倒是可以。

相關連結

• Release Notes Mono 2.4.2

在 IIS 中，應用程式集區使用的身份識別為 Network Service，而 ASP.NET 應用程式預設的執行權限也是這個身份，當我們需要以非預設的權限執行 ASP.NET 時通常有兩種作法：1) 修改 應用程式集區的身份識別、2) 設定 web.config 中的 <identity> 參數。

針對第一種狀況，除了要參考我另一篇【IIS應用程式集區自訂身份識別後如何讓 ASP.NET 正常執行】文章之外，在該文章「備註二」，可以替換成以下指令：

cd C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
aspnet_regiis -ga User1

在 aspnet_regiis /? 所輸出的說明是

-ga <user>     針對 ASP.NET 所使用的 IIS Metabase 和其他目錄，授與指定的使用者或群組存取權限。

也就是說，只要利用 aspnet_regiis.exe 就可以幫我們設定完所有該設定的權限，不需要額外手動調整。

而第二種狀況，就是修改 web.config 中的 <identity> 參數，如下範例：

<identity impersonate="true" userName="User1" password="MyPassW0rd"/>

若要透過這種方式運作 ASP.NET 一樣會遇到許多權限不足的情況，建議也是透過 aspnet_regiis 幫你設定相關權限即可。

相關連結

• ASP.NET IIS 註冊工具 (Aspnet_regiis.exe)

這好像不是什麼有意義的題目，雖然我知道有 File.Exists 與 Directory.Exists 可用，只是我昨天心血來潮想找找 .NET Framework 中是否有檢查某「路徑字串」是「檔案」或「目錄」的方法(Method)，一開始先猜想 Path 類別是否有相關的 Method，但找不到。

如果你今天得到一個「路徑字串」，光從字串中是無法判定這是檔案或目錄的，「檔案」通常都有副檔名，但也可以沒有；而「目錄」通常都沒有副檔名，但也可以有。所以無論如何都需要有個判斷方法。

既然找不到簡單的方法，就必須用傳統的方法判斷，如下範例：

if (File.Exists(strPath))
{
    // 有效的檔案
}
else if (Directory.Exists(strPath))
{
    // 有效的目錄
}
else
{
    // 無效的路徑(檔案或目錄不存在)或沒有讀取權限。
}

我們在判斷路徑字串時，大多時候得到的路徑字串都是檔案居多，所以應該先判斷「是否為檔案」，然後再判斷「是否為目錄」，當兩者條件都不成立時，就代表該路徑不存在，或該路徑沒有讀取權限。

至於對檔案或目錄的操作，可以多參考以下類別的 MSDN 文件說明：

• Path 類別
• File 類別
• FileInfo 類別
• Directory 類別
• DirectoryInfo 類別
• FileSystemInfo 類別
• FileSystemInfo.Attributes 屬性
• FileAttributes 列舉型別

今天又遇到一個奇特的狀況，之前一個已經跑了將近三年且運作正常的系統，由於該系統必須連接本機的 ADAM 進行身份驗證，卻突然間開始出現【驗證機制不明】的錯誤，讓我丈二金剛摸不著頭緒。

中文錯誤訊息如下

System.Runtime.InteropServices.COMException: 驗證機制不明。

英文錯誤訊息如下

System.Runtime.InteropServices.COMException: The authentication mechanism is unknown.

由於程式在進行任何 AD 節點(Node)操作時都必須先透過 Binding 的程序，並傳入帳號密碼登入驗證：

DirectoryEntry dnNode = new DirectoryEntry(BasePath + mCurrentDN, Username, Password);

而我傳入的帳號密碼一直都沒有加上 Domain\ 的部分，例如：

string Username = "LoginUser";

結果，解決這個問題的方法只要加上本機電腦的名稱即可：

string Username = "COMPUTERNAME\LoginUser";

相關連結

• ASP.NET Error "The authentication mechanism is unknown"

.NET Framework 中的 String.Contains 方法從 .NET 2.0 時就開始出現，但你可能從未想過這個問題，這個簡單的 String.Contains 方法到底有什麼該注意的地方呢。先考各位一段簡單的程式碼，並先仔細想想如果以下程式碼執行完後，變數 b 的值應該是 True 或 False 呢？

string s1 = "The quick brown fox jumps over the lazy dog";
string s2 = "";
bool b;
b = s1.Contains(s2);

不蠻各位，連我在寫類似這段程式時，大多從心裡直覺的認為答案是 False，直到上週才發現一個幾個月前完成的專案竟然開始出現一些不合理的結果，原本不應該出現的資料全部都出現了。

我會想說，s1 有一堆字串，而 s2 卻是空字串，當判斷 s1 是否包含「空字串」時，怎麼可能會是 True 呢？

我也好奇的問了多位有在寫 .NET 的朋友，不少都是 .NET 撰寫多年且實力不差的開發人員，大家都一致的回答 False！

我都說成這樣了，還有人認為答案是 False 嗎？除了我親自跑程式驗證過答案是 True 外，也轉貼 MSDN 上關於 String.Contains 方法的說明，如下圖示：

這樣的結果著實讓我匪夷所思，像這種簡單到爆的方法(Method)誰會真的認真到仔細的看這種 Method 的 MSDN 文件，而這種違反直覺判斷的程式行為實在是需要「經驗」，遇到了才知道，即便是如此簡單的字串用法。

※ 2009-06-26 補充說明

我多列出幾個跟 String 類別有關的字串比對 Method，供各位參考：

Console.WriteLine("123".Contains(""));    // True
Console.WriteLine("123".StartsWith(""));  // True
Console.WriteLine("123".EndsWith(""));    // True
Console.WriteLine("123".IndexOf(""));     // 0
Console.WriteLine("123".LastIndexOf("")); // 2

總之「空字串」代表的不是「字串」，而擁有一個特殊的意義，你可以想像著每一個字串在開頭與結尾都會包括一個「空字串」，這個「空字串」本身不佔空間，但卻存在這樣一個虛擬字元，緊緊黏在第一個字元與最後一個字元上。

我不知道這樣說明會不會對某些人來說太複雜，但我自己是這樣想像的，可以幫助我記憶這個現象，這樣想以後寫程式的時候就比較不會出錯了。

相關連結

• .NET Framework 類別庫 - String.Contains 方法