July 2008 - Posts

【茶包射手專欄】Windows桌面開太多東西就"怪怪的"

如果你跟我一樣,有4G以上的RAM,又喜歡在桌面同時開一缸子程式節省來回切換的時間,你應該有遇到以下情境的經驗:

明明RAM還有剩很多,電腦卻開始不聽始喚: 新程式的畫面出不來、程式視窗關不掉(按右上角的X沒用)、選單項目不見、視窗一片空白、右鍵選單出不來... 設法關掉一些程式後,記憶體用得少了,系統就又恢復正常

被這問題困擾很久,也請教不少專家,都沒得到明確的解答,大部分的人刻板印象是: Windows在記憶體用很多時,就會怪怪的,不太穩... 而關掉程式釋放一些Memory後就會恢復,似乎也印證了這個講法有幾分道理。

一直以來,我除了接受這個籠統且對Windows帶點歧視的結論之外,也沒有其他選擇。直到幾前天,我很幸運地在事件檢視器中發現這個錯誤訊息:

Failed to create a desktop due to desktop heap exhaustion.

用這個錯誤訊息Goggle到相關文章,我才搞懂,RAM再多,Desktop Head Size卻是固定的,用完了就有可能導致桌面不正常,例如: 新視窗開不起來。推敲了一下,我覺得這個限制極有可能就是造成RAM剩很多,桌面操作卻開始不正常的元凶!!

另外,我還找到了dheapmon這個好工具,可以測量Desktop Head的用量,就待下回出問題時,再來好好地剖析一下。

昨天,桌面開了一堆東西,想開Word檔案,卻發現Word只出現外框,文件開不出來。機不可失,興奮地用顫抖的手開啟dheapmon檢查:

C:\Program Files\Debugging Tools for Windows\DskHeapMon\x86>dheapmon
Desktop Heap Information Monitor Tool (Version 8.1.2925.0)
Copyright (c) Microsoft Corporation.  All rights reserved.
-------------------------------------------------------------
  Session ID:    0 Total Desktop: (  6848 KB -   10 desktops)

  WinStation\Desktop            Heap Size(KB)    Used Rate(%)
-------------------------------------------------------------
  WinSta0\Default                    3072             99.8
  WinSta0\Disconnect                   64              4.0
  WinSta0\Winlogon                    128              8.2
  Service-0x0-3e7$\Default            512             13.6
  Service-0x0-3e4$\Default            512              3.2
  Service-0x0-3e5$\Default            512              1.2
  SAWinSta\SADesktop                  512              0.8
  __X78B95_89_IW\__A8D9S1_42_ID       512              0.4
  Service-0x0-1eefc$\Default          512              1.2
  Service-0x0-27435$\Default          512              1.4
-------------------------------------------------------------

Bingo!!! 命中要害,Heap用掉99.8%,關掉一些程式,降到86%後,系統就又正常了。由此,我可以確認這個困擾已久的問題,就是肇因於Desktop Heap耗盡。依著MS KB的說明(看英文版比較好,"Out of Memory" error message = 「 郵件答錄機的記憶體 」 錯誤訊息,算你狠!!),調成SharedSection=1024,8192,512(原來的值是3072[註: x64 OS預設20M起跳],原本只敢小小加到4096,但看到有人開到8192也沒事,加上這個數字調大的影響似乎只會影響同時連線的Terminal Service Session數,對我的工作機不是問題,索性就一口氣開上8M),從此就可以盡情地開視窗了,再也不怕桌面瘋瘋顛顛了。

【參考資料】

題外話,很多時候,所謂的"不穩"、"怪怪的"、"見鬼了",多半另有隱情,搞通了就不再詭異,對系統的掌握度也就更上一層樓了。

不過,是否真能揪出背後的元凶,跟追問題者的積極度(像遇到我這種不信邪的瘋子)、錯誤訊息的明確性(例如: 只知桌面不知使喚,沒有任何警告或提示)、有無適當的偵測工具(dheapmon好棒),都很有關係。在本案例,要不是無意發現Desktop Heap耗盡的錯誤訊息,我對此問題的認知,大概永遠只停留在"Windows桌面開很多東西就會不穩"的層次(没給User明確的訊息,Windows背負這個污名也是活該吧XD)。

原來,對茶包射手來說,運氣也很重要!!

關於AssemblyVersion的一點小事

用Visual Studio寫程式的人,不知有沒有注意過AssemblyInfo.cs裡的這個屬性:

[assembly: AssemblyVersion("1.0.*")]

如果你有手動去修改過它,恭喜你! 代表你參與的專案已達一定規模,或是你寫的程式跟元件已經在外開枝散葉,子孫多到要用什麼"字輩"來搞清楚血緣尊卑。XD

不過,或許有些人還不知道微軟版本號碼裡四個數字的用法,可能也不知道Visual Studio專案中版號設成1.0.*時的自動跳號規則。今天剛好有同事問到這件事,我就順手把它整理一下。

微軟慣用的版本編號分為四組數字,例如: 1.0.2553.14653,這四個數字依序是:

  • Major Version: 主版號,大多在大規模的功能、架構變革時才會更動
  • Minor Version: 次版號,用於小規模的功能、架構修正。一般而言,這兩個版號變更意味某些方法參數、型別的變動,有可能導致元件的不相容。
  • Build: 組建,一般用來區別程式是在哪一天組建(Build)的。在軟體工程中,有所謂的Daily Build法,透過每天重新編譯並重新進行測試,確保每天在進行的程式碼修改沒把整個軟體搞爛。而軟體要正式發行時,也會從諸多的Build中挑出一個問題最少,品質最好的先選作Release Candidate。
  • Revision: 修訂,一般保留給為了修復特定錯誤的後續組建,有時也稱作Emergency Bug Fix。(常用於Quick Fix Engineering, QFE, Hotfix的版次標示)

更詳細的資料可以參考MSDN文章: 元件版本控制

想知道.NET程式/元件的版號,我們可以用Windows檔案總管來檢視。EXE、DLL檔案的內容視窗,第二個Tab裡就可以看到版本資訊,還包含發行公司等資訊,且不限.NET編譯的。(這招在調查來路不明檔案時,格外有用。)

了解了版號的意義,另一個有趣的問題是: 當我們設成"1.0.*"時,Visual Studio會如何自動跳號決定Build及Revision?

答案是由Build的日期與時間決定,Build = 以2000/01/01起算的天數,Revision = 以凌晨00:00:00起算的秒數除以2。

用以上的WinForm35.exe來驗算一下,程式的編譯日期時間是2008/07/22 08:08:26,而版號為1.0.3125.14653。所以我們叫出Mini C# Lab,寫個兩行Code:

DateTime d = new DateTime(2000, 1, 1);
Console.WriteLine(d.AddDays(3125).AddSeconds(14653 * 2).ToString("yyyy/MM/dd HH:mm:ss"));
 

薑薑薑薑,計算結果正是: 2008/07/22 08:08:26!

[2008-07-30更新] 感謝Tom補充,AssemblyFileVersion可以避免變更AssemblyVersion衍生的重新編譯需求,在實務上也很常被拿來做成版本識別的依據。引用Tom的說明如下:

"既然提到AssemblyVersion, 我想也可以順便提一下 AssemblyFileVersion.

因為被參考的 DLL 其實會被綁定某個 AssemblyVersion, 所以若因為小修正而改變了 AssemblyVersion, 會造成其他參考他的 DLL 必須跟著重新編譯, 所以我們大都是用 AssemblyFileVersion 來做版本判別.

只有當 interface 改變, 才異動 AssemblyVersion, 否則若只是修正 bug 或是加強內部演算法, interface 不變的狀況下, 都只改變 AssemblyFileVersion."

【瑣事便利貼】
當孝子剝荔枝給兒子吃,吃了兩口,他忽然故做有學問狀,十分認真地"教"我:
吃荔枝的時候要小心哦,裡面的"骨頭"不可以吃...  (哈! 當場全家笑翻)

一般來說,骨頭外面是肉,外面再包覆一層皮。那麼,剥開荔枝"皮",看到荔枝"肉"裡面包的便是荔枝"骨頭"囉? 似乎也有幾份道理。

這孩子果真有邏輯演繹能力,頗有乃父之風,不錯不錯。

Posted 29 July 2008 08:35 PM by Jeffrey | 4 comment(s)
Filed under: ,
Windows 2003 or Vista?

一直以來,我都用Windows 2003當工作機OS,主要的理由是希望自己的工作環境可以跟Production環境一致,這樣在自己的工作機上就能模擬出最逼真的狀況,有利於驗證及偵錯。

Windows 2003上能跑的服務,例如: SQL Server、IIS在Windows XP上也能跑,但還是有些區別,例如:

  1. Windows XP的IIS不能設多個Virtual Web Site
  2. IIS連線數有限制,不能超過10條
  3. Terminal Service不能開多個Session
  4. 3G RAM的限制(x86版本時,且Vista/XP x86皆然)
  5. 某些服務(如WSS)只能在Windows 2003上跑

不過,因為用Windows 2003,一路也吃了不少苦頭,例如: Windows 2003的Driver比起XP/Vista難找許多,當初為了搞雙螢幕,就搞到頭破血流。還有,很多免費軟體多以支援2000/XP/Vista為主,例如: Survey的免費防火牆中,只有Comodo的舊版可以在Win2003使用,而且還一堆奇奇怪怪的問題。看著一堆好用的免費軟體簡介流口水,實在是件痛苦的事呀!

這次將工作機的CPU及RAM升級後,發現x86 OS的4G定址及相關限制常讓人扼腕,枉費我把記憶體加倍。有時桌面程式一多,就會有視窗不聽始喚的狀況。(我很懷疑這跟記憶體管理有關,因為多半發生在RAM用量上升到3, 4G後。而前幾天在事件檢視器中看到Desktop Heap耗盡的警告,更加深了我的懷疑)

於是,我興起了改裝Vista x64版本的念頭。但真的可以滿足我的需求嗎? 朋友chicken在幾個月前就做了x64的開路先鋒,自然是優先諮詢的對象。結論是:

  1. Vista IIS 7可以支援Multiple Website了(不過IIS7與IIS6有點差異,這是額外的新問題)
  2. x64除了支援的記憶體容量大,在記憶體管理上也比x86有效率
  3. 原本的WSS需求可以搞一台VM來解決,現在的RAM有8G,要善加利用才不會遭天讉
  4. Virtual Server 2005可以裝在Vista或XP上沒問題

幾經考量,決定擇時把公司工作機的Windows 2003換成Vista x64。茲事體大,得先搞個實驗驗證一下可以完全取代後,再動手比較保險。

先前換下的E6400+4G RAM,我又補了"幾樣"配備組了一台新機,就先拿來裝Vista x64練功吧。
(原本只是不想浪費換下的CPU跟RAM,一連買了主板、顯卡、Power、Case、HD後,才驚覺當初不想浪費的CPU及RAM市價不及六千,卻又砸了一萬多,這樣真的叫"節省"嗎?)

一路裝下來,還算順暢,並沒有想像中崎嶇,x64之路看來是可行的,不過,大魔王應該還在遠方等著我,未來如有交手,再向大家報告。

Posted 28 July 2008 12:53 PM by Jeffrey | 6 comment(s)
Filed under:
【茶包射手專欄】ProcMon經典案例2: RegSvr32失敗

茶包射手界的一哥,Process Monitor,在本專欄中一向神勇無比,屢破奇案。

繼上回五分鐘破案的經典案例後,最近又有一次漂亮的出擊。

同事在Windows 2003上要安裝一個老元件aspsmartupload.dll,之前在Windows 2000上裝過多次都很順利,但這回下了regsvr32 aspsmartkupload.dll,卻得到LoadLibrary("aspsmartupload.dll") failed - The specified module could not be found.的錯誤訊息。

反覆檢查,DLL檔的路徑明明沒錯,但regsvr32就是會嚷嚷說找不到模組,到底是少了哪個檔案呢?

不慌不忙,打開Process Monitor,設定"Process is regsvr32.exe"的Filter,重跑一次regsvr32 aspsmartkupload.dll。答案揭曉,原來少了侏儸紀時代的VB5 Runtime -- MSVBVM50.DLL。

 

由其他Windows 2000主機找到MSVBVM50.DLL,複製到C:\Windows\System32下,搞定收工,前後不到五分鐘。

核四時代來臨!

我的旗艦工作機XPC SD37P2算算服役近一年半了,除了前些日子在搞TFS VM時感覺4G RAM+E6400不夠力時稍稍心癢(謎之聲: 明明就雞貓子喊叫了大半天,還好意思說是稍稍心癢?),平日只有在貪心同時四五個VS2008會逼近4G上限外,整體表現還足堪日常工作。

對連睡足六小時都嫌奢侈的勤奮中年人來說,連Survey規格、跑光華商場的時間都沒有,無疑是防止墮入敗家阿宅地獄的絕佳屏障。無奈,我有個熱心的弟弟,常不時捎來好康消息: 最近RAM好便宜,DDR2 2G一條只要1100(的確便宜,我想起五年前為了兩條1G RAM就花掉一萬六,不禁又流下兩行清淚)! 最近Q6600已經跌破6000了,再過陣子可能就買不到了!

Q6600 + 2G * 4 算是SD37P2的配備極限,也不枉我當初花了重金買進這台Server等級迷你電腦的苦心。但嘿嘿嘿... 我沒時間去買! 因此想想就好,小朋友們還可以安穩地躺在皮夾裡睡覺。

誰知,最凶狠的大絕招出現了!!

"老哥,我今天要去光華商場,有需要我幫你帶什麼嗎?"

皮夾中的小朋友們聽到這句話,像是上了整天課的小學生終於等到了天籟般下課鐘聲,任誰都攔不住,手拉著手快樂地向光華商場飛奔而去...

不久後,小朋友們用這幕令人感動的畫面向我告別:

Posted 24 July 2008 12:58 AM by Jeffrey | 5 comment(s)
Filed under:
網頁重覆送出問題,IE的專利?

同事負責的系統接到抱怨,資料庫被塞入重覆資料,經過一番追查後,發現是使用者的非常態操作所導致,簡單來說--就是送出鈕連按兩下啦!

程式人員或受過訓練的操作員都已經很習慣"執行動作後等待回應"的過程,在按下送出鈕後,就會靜候程式的回應,不會急躁地狂按送出鈕。不過,在實際世界中,並不是每個使用者都會乖乖依你的預期進行操作(所以我們才需要猴子來幫忙測試),遇到缺乏耐性、搞不清狀況或暴怒的使用者,事情的發展就很難預料。

我一直有個錯誤的印象,使用者在按下送出鈕後,瀏覽器就會結束目前的網頁操作,顯示空白等待Postback的結果傳回(其實我已經被狂電過一次,但顯然還是沒學起來)。事實上,在Postback後,瀏覽器會停留在原網頁上,一直到新網頁內容送達為止,在此之前,網頁仍然可以被操作,這給了使用者重覆按下送出鈕的機會。

不信? 我用了以下的ASP.NET網頁來驗證。

<%@ Page Language="C#" %>
<%@ Import Namespace="System.IO" %>
<script runat="server">
    protected void btnSend_Click(object sender, EventArgs e)
    {
        System.Threading.Thread.Sleep(10000);
        using (StreamWriter sw = 
            new StreamWriter("A:\\Output.txt", true))
        {
            sw.WriteLine("{0:yyyy-MM-dd HH:mm:ss.fff} {1}", 
                DateTime.Now, txtData.Text);
            sw.Close();
        }
    }
</script>
 
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Submit Twice</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:TextBox ID="txtData" runat="server"></asp:TextBox>
        <asp:Button ID="btnSend" runat="server" Text="Send" 
        onclick="btnSend_Click" />
    </div>
    </form>
</body>
</html>

在以上的測試中,程式會Delay 10秒才將結果寫入output.txt並傳回結果,在這等待的10秒內使用者有機會從容地多按幾次Send鈕。大約10秒後,output.txt中就會連續冒出多筆記錄,記錄的時間間隔在10秒內,證明了是網頁內容送抵前多按幾次送出鈕就會重覆送出多次Postback。

去網路上爬了一下文,發現大部分建議的解決方式都是用Javascript在按鈕的onclick事件中將按鈕設成disabled防止重覆按下,甚至有人特別寫了只能按一次的送出鈕

但在我的認知中,這件事本當由瀏覽器處理,而不是靠網頁設計師在每一顆送出鈕上加工;就Postback的行為而論,按下後網頁存在的正當性就消失了,只是看守性質,除了默默等待新網頁內容進行輪替外,什麼都不應該做,更別說每按一次送出就Postback一次。

我原本以為這是網站開發者的宿命,是瀏覽器天性使然,心念一轉,改用Firefox測試一下,卻驚奇地發現,Firefox在等待的10秒內,Send鈕可以重覆被按下,卻不會重覆送出POST Request,這才是我期望的Behavior!! 再追加測試了IE8,發現跟IE7一樣會有重覆送出的行為,有點失望。

綜合了以上的研究,我覺得這是個不合理的行為設計(就跟之前IE6中的下拉選單會浮在任何元素最上層一樣),剛才透過Microsoft Connect提了建議,如果有接到回應,再跟大家報告吧!

想為自己嬴得一套VSTS 2008 + MSDN嗎? 看這裡!!

不要小看這張黑鴉鴉的卡片! 沒錯,它就是文章標題所說的Visual Studio Team System 2008 + MSDN 一年期的啟動函,市價超過十萬元,也是近期即將舉辦的黑暗盃程式魔人賽的獎品!

我們專訪了這位突發奇想的部落格主,談談為什麼想要舉辦這次的活動:

記者(以下簡稱記): 黑暗執行緒先生,可否先談一下你這份VSTS 2008 + MSDN的來歷,會不會害獲獎人被依收受贓物罪名起訴?

黑暗執行緒(以下簡稱黑): (一邊說話一邊擦汗並將露出的手槍與絲襪塞回褲袋) 我在去年參與VS2008 Beta測試,曾經寫了Feedback給微軟RD團隊,之後也沒放在心上。前些日子,忽然收到微軟的感謝函,還附上了這份大禮,致謝函中提及可以自由選定社群的朋友贈送,讓更多人感受Visual Studio 2008的強大威力。

: 既然可以任意挑選贈送對象,為何不辦個抽獎大放送,而要花時間辦什麼鬼程式設計大賽?

: 我不愛用抽獎方式胡亂選人,一來是自己一向沒什麼中獎運,格外痛恨抽到大獎的人(不自覺又摸了摸手槍),二來我認為讓努力的獲得最大的回報才是最公平的,再者,程式大賽可以鼓勵更多人對Coding的熱情,讓開發社群更活躍,也不枉微軟的初衷。

: 聽起來挺官冕堂皇的,但我覺得怪怪的,你其實另有目的,對吧?

: (大驚失色) 算你狠,我裝得這麼誠懇還被你識破! 好吧,其實我是想透過這次活動證明: 全天下還有其他怪胎人跟我一樣,會為了好玩而寫程式(Coding For Fun)。我看過大多數的同事、朋友,多半都把Coding當成工作或作業,只有我常會為了好玩或處理某個日常生活的小問題寫一支程式來用,雖然自得其樂,但久了就會懷疑自己是否天生異類。所以難得有這麼珍貴且有意義的獎品當作誘因,想透過這個活動,認識一些跟我一樣會為了好玩寫程式的人,證明吾道不孤...

: 聽起來挺悲情的。那這次的什麼鬼程式魔人賽,題目是什麼,打算怎麼進行?

: 題目我想好了,就是用.NET寫一隻程式可以用幾A幾B猜出答案的程式,這遊戲大家小時候應該都玩過,規則比較不用費唇舌。但1234這種是人玩的,程式玩的當然要複雜一點,答案可能是3A-5F-66-87-C5-DF-EE-69-... ,提示是15A8B這種多位數、大範圍的挑戰,到時要比誰的程式猜的次數少、速度快、用的記憶體少。冠軍就可以抱走VSTS + MSDN,細部的規則我還在構思中,大約八月上旬會丟個比賽規則RFC,聽聽大家的意見後再做最後定案。

: 為什選幾A幾B這個題目,感覺上並不怎麼有深度?

: 題目的挑選上,希望不要變成太高的門檻,讓多一點人可以參與,如此才能證明"老爸老媽、大哥小妹、男孩女孩,只要有心,人人都可以是程式魔人"。(說罷,眼神飄向遠方...)
另外,這個題目對我有特別的意義...
記得在專科時,工專生人手一台工程用計算機,我當時買的是CASIO最陽春的FX-3600,有幾位好野同學買的是可以顯示ABCD還可以寫有字數限制簡單程式的豪華版FX-4000,有一次我就利用上課時間跟同學借了計算機來玩,一個字母一個字母拼指令,寫出一個出題目給使用者猜幾A幾B的小遊戲,同學驚訝之餘,應該暗地裡覺得我是瘋子... 由於我唸的並不是電子或資訊科系.... (受訪者大話當年勇及離題瑣事約二十分鐘,在此省略)

: 目前看來大獎只有一項,除了冠軍之外的人全都摃龜,好像不太厚道,還有其他獎項嗎?

: 嗯,這種一家歡樂萬家愁的情況的確有可能發生(謎之聲: "萬"家愁?? 有三個人報名就偷笑了吧?),我想在比賽正式開跑前,我會再設法去化緣募捐看看,設法找到一些慈善機構贊助些獎勵,讓活動精彩些。不過我既無善舞長袖、亦無豐沛人脈,大家不要期望過高便是了。這陣子請大家留意一下本站的文章,有什麼新消息,會在本部落格公告。

TIPS-我的TFS安裝筆記

江湖上傳說TFS很難裝,一裝之下果然名不虛傳...

在動手前,請記得先爬文,可以少走點冤枉路,以下是我找到的一些資源:

不過,縱使已經先看過文件,我還是翻了好幾個跟斗。

TFS有Single-Server跟Dual-Server兩種安裝法,本來的構想是將TFS裝在我的工作機上,但又怕它會強制修改Reporting Service、WSS的設定,打亂工作機上本來的SSRS及WSS設定,所以最初想另外裝一台VM跑Application Tier(SSRS, WSS, TFS),SQL直接用工作機上的SQL 2005 Instance,可以省點RAM,也就是搞成Dual Server的架構。

美夢沒兩下就碎了... 我安裝的是Visual Studio Team System內附的TFS Workgroup Edition,限制只能用Single-Server架構,DB也得裝在VM上,只好把VM的RAM加大到768M,乖乖來份海陸全餐。(心中吶喊: 4G的RAM看來不夠用呀~~~)

TFS的安裝程式會進行Server Health Check一一指出哪些東西沒準備好,加上我用的是全新安裝的VM,其實並不算太難搞(除了被警告CPU跟RAM不合格外),只是VM的速度實在不怎麼樣,等好久才搞定: SQL 2005->SQL 2005 SP1->TFS Setup->WSS Setup的安裝流程。(心中吶喊: E6400雙核CPU看來不夠快呀... 謎之聲: 你根本是想敗家才會一直雞貓子喊叫吧?)

都安裝完成後,在VM的程式集中找不到任何TFS相關的連結,讓我楞了一下。後來想到,所有的管理功能應該是透過Team Explorer進行,在Visual Studio 2008找到功能表View/Team Explorer,就可以連上TFS,建立第一個專案。

底下是我的筆記:

  1. TFS會裝在8080 Port ,要管理需透過Team Explorer
  2. 建立新專案時,Team Explorer會連上SSRS設定報表,連上WSS控制中心建立專案入口網站,如果有設防火牆,記得開放: 80, 8080, WSS管理中心(安裝時隨機指定)等Web Port。
  3. 如果你要將新專案Check In到TFS,要修改VSTS的預設Source Provider選用TFS,否則VSTS只會提示VSS來源。但已經掛在TFS或VSS的專案,VSTS則可以自動識別找對來源。
  4. TFS全部的東西裝在一台VM上,運轉一陣子會吃RAM吃到900MB,所以建議系統需求的記憶體要1G並不誇張。不過我只想用Version Control,就試著把WSS Web、WSS管理中心、Analysis Service等服務都關閉,雖然Team Explorer上有些功能會出現叉叉,但Check In/Out都正常,就可以把RAM用量壓在500M左右,不失為舒緩之道。
Visual Studio 2008不支援SSRS的報表專案編輯

拿到VS2008的朋友,別急著把VS2005移光光,如果你還有編輯SSRS報表專案需求的話。

Visual Studio在大部分的舊版相容策略上,都維持簡便無痛的升級方式,但也有例外,例如: Reporting Service專案。

SQL Server 2000的Reporting Service報表限定只能用VS.NET 2003編輯,SQL 2005的SQL Server Reporing Service(SSRS)則必須搭配VS2005使用。因此Visual Studio 2008目前無法開啟SSRS的專案(.rptproj),得乖乖回頭用VS2005做事。

想用Visual Studio 2008編輯報表專案,要等待SQL 2008的Report Designer問市,SQL 2008目前預計會在Q3上市。

參考資料: 1 2

【茶包射手專欄】QueryString的中文編碼問題

同事在測試程式時,為求簡便,在IE地址列直接輸入測試用的參數,例如: MyApp.aspx?q=中文 (註: 此為不良示範,QueryString中如要指定英文字母及數字以外的字元,均應使用UrlEncode以求保險),結果ASPX中Request["q"]會抓到亂碼。

利用Visual Studio Debug時監看Request物件,會發現QueryString的原始Byte Array內容中,中文字是以BIG5方式編碼方式傳送的(有興趣研究的人可以試著用中文編碼解析工具驗證),而Request Encoding預設是UTF-8,最後當然是亂碼收場,並不意外。測試發現,如果把Request Encoding設成big5,Request["q"]便可抓到正確的值,但會破壞網站原本來往均應為UTF-8的設計,並不合理。因此,避免在URL中直接指定非ASCII文字,必要時使用URLEncode編碼過才是根本解決之道。

不過,在追查過程中,引發了另一個有趣的問題: IE的選項中有個"Send UTF-8 URLs",難道這個設定不能解決這個問題? 由於預設IE7的Send URL-8 URLs就是開啟的,顯然證實了該選項無法解決QueryString中直接夾帶中文的問題!

利用IE瀏覽"http: //someServer/中文.aspx?q=中文"並開啟Microsoft Network Monitor 3.1,分別觀察開啟或關閉"Send UTF-8 URLs"後所發出的HTTP Request封包。

結論是,"Send UTF-8 URLs"選項只會影響IE7送出Request中網頁檔案名稱的UrlEncode編碼(橘色框),至於QueryString中的中文字,則一律使用Windows預設的non-Unicode編碼(在正體中文環境中,多半就是BIG5)轉成Byte Array(綠色框)。所以,為了避免自找麻煩,在傳遞QueryString參數時,請多利用UrlEncode(Javascript中可用escape()函數)。

 【延伸閱讀】

關於TFS授權成本

自從把Mini C# Lab放上CodePlex後,算是我第一次使用TFS當作Source Control。比較起來,TFS的版本管控以Database為核心,透過Web Service方式提供服務,整體架構比VSS來得好。這次的使用經驗讓我對TFS這個Solution有點興趣,認真地考量了一下用它取代VSS的可能性,其中一個重要關鍵是成本! VSS是免費的,而TFS需要授權。於是,花了點時間Survey,以下是我的心得:

MS的官方資料: http://msdn2.microsoft.com/en-us/teamsystem/aa718938.aspx

Team Foundation Server需要Server License及CAL(Client Access License),以下的產品包含了CAL,不用另外採買:

  • Visual Studio 2005 Team Suite
  • Visual Studio 2005 Team Edition for Software Architects
  • Visual Studio 2005 Team Edition for Software Developers
  • Visual Studio 2005 Team Edition for Software Testers
  • Visual Studio Team Edition for Database Professionals

    非上述版本(例如: Visual Studio 2005 Professional Edition),或3rd Party產品(如Teamprise或Teamplain),則需要另外再買CAL。

    值得一提的是,上述的產品都包含了一個免費的Team Foundation Server Workgroup Edition組合包,可供最多五名成員使用(Visual Studio 2005 Pro版也可以連,不限Team Edition,但不要錢的VS 2005 Express則不行),同時還內附含限定TFS專用的SQL Server 2005 Standard Edition授權。(這個部分我很少聽人討論,但評估起來很划算)

    台灣微軟的網站上可以查到TFS, Team Suite及Team Edition的零售價,我個人的看法針對五人以下的小型團隊,不要忘了Team Foundation Server Workgroup Edition組合包這個好康,至於大型企業如果要大規模導入,那麼也許可以考量走大量授權的模式。

    註: 由於事涉授權等議題,特別聲明,以上資訊為本人自行查詢網路資料所得的理解,僅供參考用途,恕不對其正確性提供任何保證。各位如有疑義,請自行與台灣微軟接洽。

    PS: Visual SourceSafe有不少效能上及安全上的缺陷,看起來微軟也不打算繼續經營它,未來的主流應該會是TFS。如果你也考慮要用TFS取代VSS,我推薦這篇文章: 由VSS到TFS

     

  • Mini C# Lab ver 1.3 Release Note

    After Mini C# Lab ver 1.2, I got several important feedbacks from community, a friend, elleryq, told me that there is a free software Snippet Compiler providing colorful formatting, line number, document outlining, method list dropdown, even Intellisence, almost as luxurious as Visual Studio. Wow! It's really cool.

    Compared with Snippet Compiler, Mini C# Lab's code editor is quite weak. The Snippet Compiler integrated ActiPro's SyntaxEditor control to provide friendly editing environment, but this make it fatter (about 3MB, but still not big) and not open-source. If Mini C# Lab can improve its code editor, the mini size (less than 100KB), open-source, and single file features still can distinguish it from such fancy solutions as Snippet Compiler, IMHO.

    Another friend, adminjew (AKA Yotzichok), did a splendid job!  The open source code editor, ICSharpCode.TextEditor, was integrated to provide adequate features for C# coding, although no Intellisense and method list, it's good enough for mini coding job.  Except the new code editor, adminjew also add a whole bunch of new features, including undo/redo, a tool bar, splitted window, copy as formatted HTML...

    I postponed the release of ver 1.3 for several weeks for dogfooding it by myself.  I was excited about the nice experience of using Mini C# Lab on remote machine via terminal service, download and run!  The best experience is when I had to write and test C# code directly on a Bloomberg terminal, I was not allowed to setup Visual Studio on it because of memory limitation and authorization issue.  My code cause Snippet Compiler failed, so I use Mini C# Lab 1.3 to complete the whole coding and testing, it's totally adequate for the job!

    Here are the new features of Mini C# Lab v1.3:

    *  Replace RichTextBox+CSharpFormat with ICSharpCode.TextEditor
    *  Add toolbar and cut/copy/paste, print, undo, redo, split code box, copy as html functions...
    *  Terminate execution by force while exiting
    *  Prompt to save modified code before exiting
    *  Remember saved file name for latter saving

    You can download the v1.3 from CodePlex or from http://www.darkthread.net/MiniCSharpLab/MiniCSharpLab.zip directly.

    【中文摘要】

    Mini C# Lab 1.2推出後,我收到不少珍貴的回饋。elleryq提到了Snippet Compiler,同樣是即寫即編即跑,但內建的ActiPro SyntaxEditor程式碼編輯器支援Intellisense(是的,他加了洋葱 XD),豪華到讓人感動落淚,跟Mini C# 1.2簡陋到不行的克難程式碼編輯器,簡直是拿XX比XX。

    不過,上天的安排真是巧妙,另一位天使出現。來自美國紐約的adminjew咻咻咻地擴充了我的Mini C# Lab,加入一缸子新功能,還包含一個可怕的新東西--ICSharpCode.TextEditor,一個Open Source的程式碼編輯器,雖然不及ActiPro SyntaxEditor豪華,但已經比之前RichTextBox+CSharpFormat土法鍊鋼好上一百倍,剛好補強原本最弱的一環。現在行號有了,也可以即時變換文字顏色,還可以Undo... 酷呆了! 最重要的是,ICSharpCode.TextEditor是Open Source的,這樣Mini C# Lab就可以維持Open Source下去。

    adminjew在好幾週前就提出了他的改良,我卻遲推了好幾個星期才釋出新版,理由是我花了幾週吃自己的狗食(dogfooding)後才推出。這段時間,好幾次在Terminal Service到遠端主機時,直接Copy Mini C# Lab過去寫Code測試某些程式跑不起來的問題。而最棒的一次經驗是則是在Bloomberg Terminal上寫整合程式,因為記憶體限制跟未獲機器主人授權的理由,我不可能在上面裝一套Visual Studio,而該程式在Snippet Compiler上執行會出錯,所以我切回Mini C# Lab上,邊寫邊測地把程式寫完。

    跟雄偉的Snippet Compiler巨人相比,Mini C# Lab仍具有Open Source、可自行擴充、單一執行檔的優點,但由於缺乏Intellisense,並不適合對語法生疏的情境,算是提供給大家另一個選擇。

    整理一下1.3版的新特色:

    *  以ICSharpCode.TextEditor取代原本RichTextBox+CSharpFormat
    *  加入工具列,支援剪下/複製/貼上、列印、復原(Undo)、分割顯示、複製成HTML等功能
    *  程式結束時會強迫停止執行中的程式
    *  結束前提示是否要存檔
    *  連續多次存檔時會記住前次的存檔檔名

    TIPS-切斷web.config的繼承關係

    在ASP.NET的設計中,web.config是存在繼承關係的。例如: 我在wwwroot下放的web.config設定,將會影響到子目錄(例如: wwwroot/MySubWebApp)甚至虛擬子目錄下運作的ASPX網頁,即使MySubWebApp已建立成獨立的Web Application時,還是會受到一些影響。 (之前在Sharepoint網站上加掛自己Web AP時,有不少類似經驗)

    我在Community Server 2007的網站下,建了一個虛擬目錄MySubWebApp(實體路徑為D:\WWW\MySubWebApp),放入另一個獨立網站的內容,並用IIS設定成獨立的Web Application,瀏覽時會傳回以下錯誤:

    Server Error in '/MySubWebApp' Application.

    Configuration Error

    Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.
    Parser Error Message: Could not load file or assembly 'CommunityServer.Components' or one of its dependencies. The system cannot find the file specified. (d:\www\cs2007\web.config line 40)

    查了一下,問題出在d:\www\cs2007\web.config 的這一行:

    <httpModules>
      <add name="CommunityServer" type="CommunityServer.CSHttpModule, CommunityServer.Components" />
    </httpModules>

    CS2007在它的web.config裡宣告了專用的HttpHandler,而這個設定變成在MySubWebApp裡也生效,於是ASP.NET會試圖在D:\WWW\MySubWebApp\bin裡尋找CommunityServer.Components.dll。根本是八竿子打不著的東西,當然找不到而以錯誤收場。

    要解決這個問題,我們可以切斷這層繼承關係。在web.config裡可宣告location inheritInChildApplications來阻止繼承。

    不過,這是個神祕的Attribute,在Visual Studio中不會提示,MSDN上也找不到這項Attrubute。在CS2007的web.config上,用<location path="." inheritInChildApplications="false">把<system.web>包起來,問題就解決囉!

    哇塞! 有沒有這麼大尾呀?

    【警告: 內含寫實的自然生態照片,如果你正在看網頁配早/午餐,請斟酌點閱】

    登高健行除了可以鍛鍊強健體魄呼吸新鮮空氣陶養仁愛之心(仁者樂山,不是嗎?)之外,還有一項收獲,就是親近大自然可以見識許多都市叢林見不到的珍蟲異獸。

    除了每次都會看各式蝴蝶蜻蜓外,五月底那陣子,連續五次登山都看見小蛇(還好都是不及小指粗的小小蛇,人蛇相見,各自驚嚇加速逃逸,相安無事),到了六月則是滿山遍野的金蟬脫殼,最大的接近7-11茶葉蛋的大小。(我一直認為7-11的茶葉蛋是電腦選的,不然去哪裡找這麼多迷你雞蛋?)

    最神的還是上週,親眼目睹了"螳螂捕蟬"的神奇畫面,活生生地上了一堂國語+自然課。

    今天又去二格山報到,半路上遠遠遇見一條近兩尺的小黑蛇。哇靠! 在我的遇蛇事件簿裡,這條算是大尾的,而且還在路中央直衝我而來。不得了,趕快大步踏著路邊跳過它的上空,回頭一看,怪怪的...

    這"蛇"怎麼不是"蛇行",而是"蠕動"...

    好奇心趨使我回頭看了一下,黑黑的,一節一節的,莫非這是---蚯蚓??

    印象中的蚯蚓不是長到一枝筷子長就很強了,這隻近兩尺,會不會太大尾了點? 莫非是蚯蚓精?

    本著科學精神,我讓鏡頭蓋入鏡作為尺寸比例對照(我的表現不比人骨拼圖中拍照會放鈔票的安吉莉娜裘莉差吧?),提供照片兩張。第一張用來突顯全長,第二張則驗證我判別其為蚯蚓的理由。

     

    為了怕驚嚇到某些人(例如看到青蟲都會想吐的某女子),內嵌圖片只放縮圖,有科學研究精神的人再點開看大圖。

    按此比例推估,下回如果我在山上聽到兩隻狐狸在聊天,也不宜太驚訝,以免被譏沒見過世面。

    中文亂碼"蕞蕞蕞蕞"是怎麼來的?

    同事遇到一個問題,User抱怨SSIS由ORACLE轉資料到SQL後,所有的中文字都變成"蕞蕞蕞蕞..."了。

    (這個字唸"最",不唸"叢"! 慣用倉頡的我本來是不會去研究讀音的,不過看到個性豪邁的User小姐在信中寫道"不會唸厚,拎北查好了,這二個字叫『最最』不叫『叢叢』…",我想我這輩子都不會唸錯了 XD)

    SSIS在ORACLE與SQL搬資料時的編碼問題,過去遇過,加上發現只有用特定的機器跑SSIS時會變亂碼,所以我很快地就想到應與機器上的本機設定有關,果然在改過NLS_LANG後,亂碼問就消失了。

    不過,好奇心超重的我,心中仍有迷團未解,為什麼不是出現無規則亂碼或問號,而是全都變成"蕞"呢? 利用中文編碼解析工具,我查出"蕞"的BIG5編碼是%bf%bf,而ASCII 0xBF = ¿,一個倒置的問號。看到這個符號,大家應該有點印象吧?

    編碼錯誤解析不出來時,常會出現�、?,但有時也會看到¿。當中文完全無法解析,全都的文字都變成¿,兩個¿接在一起,再被當成BIG5解析,就變成"蕞"了!

    用以下的實驗證明,四個中文字變成¿¿¿¿,再以BIG5解讀,就變成"蕞蕞",故得證。

    More Posts Next page »

    Search

    Go

    <July 2008>
    SunMonTueWedThuFriSat
    293012345
    6789101112
    13141516171819
    20212223242526
    272829303112
    3456789
     
    RSS
    【工商服務】


    BlogLook Score and Rank

    Syndication