在上回合中，我們不痛不癢的把小泥鰍的數據庫從只能供在Windows下運行的Access數據庫改為支持跨平台的MYSQL數據庫，毫無營養的修改，本回合中，我們將把我們修改后得來的項目往Linux中部署、調試，讓它適應Linux.NET的運行環境。
在本回合中，我們將討論研究：
1、由一個謊言引出另一個謊言
2、遭遇大量大小寫問題怎么辦
3、requestValidationMode？
4、同一個房頂，卻是不同的房間
1、由一個謊言引出另外一個謊言
當我們把小泥鰍部署上Linux之后，首頁一般是沒有問題的（首頁能夠打開，並且能夠閱讀里面的文章），但是當我們點擊后台管理時，頁面就開始變得奇怪起來，它沒有像我們想象那樣，出現一個填寫用戶名密碼的界面，而是如下圖所示的“問題”頁面：
通過閱讀堆棧跟蹤，我們大概知道程序用一個“AdminPage.CheckLoginAndPermission”的地方進去之后就開始報錯，為此，我們需要先確定這個叫做“CheckLoginAndPermission”的東西到底是Mono或其他三方類庫里的東西還是我們代碼里的。
判斷的方法也挺簡單，對着Visual Studio 按“Ctrl+Shirt+F”，沒錯，就是查找功能，只要我們能夠在項目中找到相關的代碼，那就證明改方法是我們項目中自己的東西。
通過搜索，結果還真讓我們找到症結的所在，於是，我們就順藤摸瓜的進入到該方法里面，該方法的代碼如下：
/// <summary> /// 檢查登錄和權限 /// </summary> protected void CheckLoginAndPermission() { if (!PageUtils.IsLogin) { HttpContext.Current.Response.Redirect("login.aspx?returnurl=" + HttpContext.Current.Server.UrlEncode(RequestHelper.CurrentUrl)); } UserInfo user = UserManager.GetUser(PageUtils.CurrentUserId); if (user == null) //刪除已登陸用戶時有效 { PageUtils.RemoveUserCookie(); HttpContext.Current.Response.Redirect("login.aspx?returnurl=" + HttpContext.Current.Server.UrlEncode(RequestHelper.CurrentUrl)); } if (StringHelper.GetMD5(user.UserId + HttpContext.Current.Server.UrlEncode(user.UserName) + user.Password) != PageUtils.CurrentKey) { PageUtils.RemoveUserCookie(); HttpContext.Current.Response.Redirect("login.aspx?returnurl=" + HttpContext.Current.Server.UrlEncode(RequestHelper.CurrentUrl)); } if (PageUtils.CurrentUser.Status == 0) { ResponseError("您的用戶名已停用", "您的用戶名已停用,請與管理員聯系!"); } string[] plist = new string[] { "themelist.aspx", "themeedit.aspx", "linklist.aspx", "userlist.aspx", "setting.aspx" ,"categorylist.aspx","taglist.aspx","commentlist.aspx"}; if (PageUtils.CurrentUser.Type == (int)UserType.Author) { string pageName = System.IO.Path.GetFileName(HttpContext.Current.Request.Url.ToString()).ToLower(); foreach (string p in plist) { if (pageName == p) { ResponseError("沒有權限", "您沒有權限使用此功能,請與管理員聯系!"); } } } }
咋眼一看，一個驗證賬戶登錄與權限的方法，如果不滿足則自動的跳轉到各自的頁面，沒有什么特別的，也沒有什么問題。但是，程序的異常就是出現在這里，因此我們需要把他找出來。
各位讀者第一時間想到的可能是馬上按“F5”或者“附加到進程”，依賴Visual Studio 這個強大的IDE來定位哪一步出了問題。但是，別忘了，我們的程序在Windows下是沒有問題的，並且當前的操作系統也不是Windows，因此Visual Studio的功能我們是無法使用的。或許，有些讀者還知道有“Mono Develop”這個IDE，該IDE可以在Linux中使用，可惜，我們的Linux中並沒有安裝這個工具，甚至連Xwindows也沒有安裝，Linux的運行級別也只是“init-3”級別，要弄“Mono Develop”太麻煩了，我們需要一些有趣的手段來定位我們的問題。
先回想一下，既然成功發布，那就證明項目是成功的編譯，而在運行時出現卻報錯，則表示，這個是一個運行時異常。運行時異常，其實我們也會經常遇到，譬如讓程序讀一個不存在的文件、數據庫連接字串寫錯之類的，這些都屬於運行時異常，只有程序運行到這一步出現錯誤的時候，程序才終止繼續運行並提示錯誤。
根據這一原理，我們可以自己定義一些“謊言”（手動的添加一些運行時錯誤），讓程序運行到此處終止並提示錯誤，通過比較程序提示的錯誤，我們就可以定位到項目中發生錯誤的哪一行代碼了，通過一個謊言來引出另外一個謊言。
譬如我在檢查是否登陸這里添加一個“謊言”。
/// <summary> /// 檢查登錄和權限 /// </summary> protected void CheckLoginAndPermission() { if (!PageUtils.IsLogin) { HttpContext.Current.Response.Redirect("login.aspx?returnurl=" + HttpContext.Current.Server.UrlEncode(RequestHelper.CurrentUrl)); } UserInfo user = UserManager.GetUser(PageUtils.CurrentUserId); //在這里添加謊言 var a = decimal.Parse("小蝶驚鴻"); if (user == null) //刪除已登陸用戶時有效 { PageUtils.RemoveUserCookie(); HttpContext.Current.Response.Redirect("login.aspx?returnurl=" + HttpContext.Current.Server.UrlEncode(RequestHelper.CurrentUrl)); } if (StringHelper.GetMD5(user.UserId + HttpContext.Current.Server.UrlEncode(user.UserName) + user.Password) != PageUtils.CurrentKey) { PageUtils.RemoveUserCookie(); HttpContext.Current.Response.Redirect("login.aspx?returnurl=" + HttpContext.Current.Server.UrlEncode(RequestHelper.CurrentUrl)); } if (PageUtils.CurrentUser.Status == 0) { ResponseError("您的用戶名已停用", "您的用戶名已停用,請與管理員聯系!"); } string[] plist = new string[] { "themelist.aspx", "themeedit.aspx", "linklist.aspx", "userlist.aspx", "setting.aspx", "categorylist.aspx", "taglist.aspx", "commentlist.aspx" }; if (PageUtils.CurrentUser.Type == (int)UserType.Author) { string pageName = System.IO.Path.GetFileName(HttpContext.Current.Request.Url.ToString()).ToLower(); foreach (string p in plist) { if (pageName == p) { ResponseError("沒有權限", "您沒有權限使用此功能,請與管理員聯系!"); } } } }
編譯發布后再刷新頁面
我們得到了這個運行時異常，圖明顯的跟之前的不同，那就證明，剛才的異常在此“謊言”的下方。
我們不斷的把我們的“謊言”（手動添加的運行時錯誤）往下挪，直到它把真正的“謊言”（原本的運行時錯誤）引出。
通過這種方法的迭代，我們大概定位到這里：
再結合它報給我們的錯誤“Object reference not set to an instance of an object”（未將對象實例化），我們可以推演出，這里有東西為null。在這里，只有user為需要實例化的類（PageUtils.CurrentKey是一個static的屬性），我們可以猜或許是user為null。
為了驗證，我們可以做如下動作：
通過驗證，我們發現我們的推理是對的，就是user為null造成了此處的失敗。
但是，為什么user為空呢？或者說，難道說小泥鰍中原程序中沒有對user作出checknull的判斷嗎？我們先追述一下user的來源，user來自於本方法中：
通過傳入一個CurrentUserId，來獲得user類，而在GetUser方法中，代碼如下：
/// <summary> /// 獲取用戶 /// </summary> /// <param name="userId"></param> /// <returns></returns> public static UserInfo GetUser(int userId) { foreach (UserInfo user in _users) { if (user.UserId == userId) { return user; } } return null; }
CurrentId實際上還是一個userid，通過比較兩個userid的值來獲得user實例。還在想為什么沒有得到null嗎？這里是一個陷阱，我們根本就沒有登陸，所以根本就沒有CurrentUserId（或者說userid的值為null），因此，GetUser方法的輸出東西應該也是為null。
難道小泥鰍沒有對輸出為null的情況作出處理嗎？答案是否定的，小泥鰍中已經有判斷，不然在Windows中就已經報錯了，如果用戶沒有登陸（沒有登陸就必定沒有CurrentUserId了），頁面就跳轉到“login.aspx”頁面（登陸頁面）。
邏輯上當然是這樣的，但是現實卻並非這樣，頁面沒有發生跳轉，或者更確切的說，程序沒有到達Redirect方法之后進行重定向並終止“CurrentUserId”方法中接下來的代碼。看清楚幕后的“元凶”之后，想要對付它也變得簡單起來，我們只需手動的讓它終止運行方法內接下來的代碼就可以了。
在Redirect下方加上Return（方法內所有的Redirect都加上）：
然后再次編譯發布，我們就可以看到我們的登陸頁面了。
2、如果遇到大量大小寫問題怎么辦？
我們進入后台管理頁面之后，嘗試添加一篇文章：
為了添加圖片，我們需要點擊“插入圖片/文件”：
然后就……，上面說“'UserControls/upfilemanager.ascx”不存在。
典型的大小寫問題，"UserControls"文件夾的大小寫。解決辦法很簡單，把文件夾名按照大小寫改好就ok。
正如我上回合中說的，小泥鰍的大小寫還是比較嚴格的，基本上都是大小寫敏感，但是，如果我們現在面對的不是小泥鰍，而是一個比較麻煩項目，里面充斥着大量的大小寫問題，我們再對此進行地毯式的搜索並修正就顯得可行性極低了（還不如推倒重寫呢）。
面對這種情況，我們也是有“作弊碼”可以行的，我們可以通過修改jws的腳本文件，讓Mono對文件目錄不區分大小寫（注意，是文件目錄，SQL語句還是區分的，因為解析SQL語句是數據庫的事情，而不是Mono的事情）。
我們只需打開“jws”文件，並把Mono的IOMAP設置為all即可（jws中只需刪掉“#”號）。
重啟一下Jexus，再嘗試添加：
ok，我們又搞定了一個問題。
3、requestValidationMode？
也不記得從什么時候開始，大概是.NET FrameWork 4.0 吧，我們使用富文本編輯器的時候，提交時會出現“Form表單有危險……”之類的提示，.NET也自動的幫我們驗證從頁面中Post回來的報文，有尖括號之類的敏感字串會自動的被.NET拒絕接收，解決的辦法也很容易，網上是大把大把的，基本上就是把驗證的模式從“4.0”（或更高）改為“2.0”就ok了。
但是，在我們這里，小泥鰍是基於.NET 2.0哦，所以應該就不會出現上述這種情況吧？！我們先試着添加一點東西：
然后再點擊提交：
片刻的廣告之后，我們只能說“嘿嘿~~”了，Mono把小泥鰍用ASP.NET 4.0 來運行了，既然它是使用.NET FrameWork 4.0 的模式來運行，那么我們也只需使用相應的解決辦法即可。
我在“web.config”中的“httpruntime”節點中加上“requestValidationMode”（在這里，我直接就用VI加了，無需重新編譯發布）：
然后我們重新添加文章並保存，就可以在首頁中找到了我們的文章了：
4、同一個房頂，卻是不同的房間
整好了小泥鰍在Linux.NET中的運行異常之后，我們還需要增加一個對Sqlite數據庫的支持，雖然平時經常聽到這一款的數據庫，但是卻從來都沒有真正的接觸過，直到開始增加此擴展的時候還是第一次（初體驗？！），多虧了通用性高的SQL語句和ADO.NET，使我在僅僅知道它有五種數據類型並從Nuget哪里獲得驅動的情況下就做好了對Sqlite的擴展（於是悲劇來了）。
在Windows中測試通過之后，我們迫不及待的往Linux中發布，然后就：
在Linux.NET中，如果遇到DLL明明就在bin目錄中，但是程序卻報找不到或者無法加載之類的，一般要么就是DLL真的找不到（文件大小寫問題）、還有其他依賴的DLL沒有成功加載或者是直接不兼容造成的。排除了大小寫問題之后，我們找找Mono中有沒有帶有對Sqlite作驅動的dll。
可以發現，Mono中已經自帶了Sqlite的驅動，並且與在MS.NET中是處於兩個不同的命名空間。此外，這里還有一個圖片需要讓讀者們看看的：
不僅命名空間不同，大小寫也是有點點差別，所以，千言萬語都不說了，改吧~~！
至此，小泥鰍的改造基本上完成了，需要代碼的讀者可以在GitHub中找到（地址在上集中有說），能力有限，如果寫得有不對的歡迎各位讀者留言，有建議或者意見的也歡迎留言，我們下回見~~！
PS：今年是“碼”年，在這里小蝶驚鴻給各位讀者拜年，祝各位讀者新年快樂，恭喜發財。