你所不知道的 C#.NET -- ＆operator

今天來探討坎尼只用過一兩次的運算子 ＆

---

先來講它最基本的用法 邏輯運算
這邊要先來講解一下它的意義
不過由於這個又是另一篇課題  所以請參考 這篇

另外還有MSDN對＆的解釋 這篇 和 這篇 

用＆連接的兩邊 必須皆為 true  結果才會是 true
而且 這篇 裡會看到 0 及 1 的運算  此時要把 1 當成 true，0當成 false

以上是位元運算的說明  先來看一下圖

可以看到  第一次運算結果 z 為 1 ，第二次 z 則為 9

這邊牽扯到 2 進位運算  坎尼用個簡單的圖來描述一下

0000 0001  -> 這是1的2進位表示式

0000 0011  -> 這是3的2進位表示式

-------------------------------------

0000 0001  -> 這是 結果 的2進位表示式 -> 答案為 1

---

0000 1111  -> 這是15的2進位表示式

0000 1001  -> 這是9的2進位表示式

-------------------------------------

0000 1001  -> 這是 結果 的2進位表示式 -> 答案為 9

計算方式就是將數字以2進位的方式展開  留下兩邊皆為1的數

以上就是＆用於計算的表示式

下圖是 16 進位的計算  但是坎尼這邊還不是很熟  所以就保留跳過啦 XD

答案會是 0x0011 -> 17

上面看到了＆用於計算 再來看＆在判斷式裡的用法

上面是常用的 if 敘述句

上面將 ＆＆換成＆

這兩個寫法有什麼不同嗎?

坎尼先說  結果是一樣的

不過處理過程卻有一些差異在

一般常用的 ＆＆ 在碰到 false 的條件式之後

會馬上跳開 if 判斷式(或是 while...)

不管接下來的條件式是不是 false

但是＆卻是將所有條件式都判斷之後  再去判斷是否為 true

上圖範例中  ＆＆在判斷 x==2 為 false 之後  隨即跳開

＆卻要多判斷 y==1 為 false 然後發現結果為 false 之後  才跳開

其實這邊的＆並不是連接用

而且等兩邊的條件式判斷完  再做一次＆計算
所以依上面範例來講 x==2 為 false，y==1為 false
false ＆ false -> false

所以＆其實還是遵守它的本分 做邏輯運算

9月的文章數真是多到嚇人

難得 Tim 會這麼努力的寫網誌  哈哈

坎尼最近再去問幾個朋友看看要不要加入.NET文章發表的行列

Microsoft TechEd 2008 心得 - Day2-1

科科，Delay 好幾天的心得終於有空寫了，
由於我並沒有辦法很爽的去參加三個整天，
而是參加了第二天整天加上第三天早上，
因此預計就用三篇的篇幅來介紹我的心得 ...

Day2 -1

0850 ~ 1000
課程主題：深入淺出談軟體與服務(Software-Plus-Services)
講師：周旺暾

我一進教室就發現，原來他就是在8/26的mix08 Taipei講 Silverlight Streaming的講師，
似乎蠻有名的，而且他能講的範圍很廣，例如這次的主題是S+S(Software Plus Service)，
也就是微軟大約在2006年之後針對SaaS (Software as a Service)提出的另一套見解，
並且花了很多時間說明微軟未來的 Cloud Computing 的架構 (細節還是得看投影片)，
以下列出幾個重點：

• 微軟未來的 Cloud Computing 平台名稱應該會叫做「Windows Live Platform」，
  這個名稱跟現有的 Windows Live Service 比較一致，
  但要特別注意的是「Platform」這個字，這除了表示微軟對這套架構的重視，
  也意味著整個 Architecture Design 基本上已經完成，現在正努力實作中。
  這個 Platform 基本上很類似 3-Tier 的架構，以下一一說明。
  
• 在微軟規劃要提供的Cloud Computing藍圖中，他們認為應該提供類似OS的服務，
  也就是說從底層的服務開始都要提供(e.g. Storage, Network)。
  會做這樣的決定應該是因為微軟本身就已經對軟體的各層次都涉入很深，
  從底層的OS、Programming Language，一直到UI這一層，
  這也是他們要保障既有投資的作法吧。
  
  微軟要強調這一點是目前市場上有好幾種 SaaS 的運作型態，
  包括 Platform as a Service (PaaS)等等總共有三種的樣子，
  不過我印象沒有很深刻，還是要等投影片出來才比較清楚 ...
  
• 在上述的 Platform 中，最底層稱為「Global Foundation Services (GFS)」。
  從名字就知道，這一層提供的是各式各樣的基礎服務 (參考:早期的架構)，
  如 Hardware, Storage, Networking,Computing等，這些服務位於系統的最底層，
  對一般 End User 來說根本不會有感覺，對於 developer 來說，
  原則上也不會直接接觸到，這些東西都是微軟幫你準備好可以直接使用的。
  
  目前微軟大約以一個月新增一萬台 Server 的速度在建置這一層的服務，
  其他如 IBM 或 Google 也都在一直拼命建機房，
  可見各(超)大軟體公司都很努力的對 SaaS 做出自己的解釋，並提出 Solution。
  
• 在「Global Foundation Service」的上一層稱為「Building Block Servcices」。
  比較有 sense 的 User 可能就會知道有這一層的存在，
  這一層提供諸如 Authentication, Authorization, Communication 等服務，
  另外我覺得 Workflow Engine 也可以放在這一層。透過這一層服務的組合，
  再加上特殊的功能以及 UI，就可以建構出更上一層的「Solution」。
  這一層服務對外提供的 API 對 developer 來說就非常重要了。
  
• 接下來就是整個 Platform 的最上層：「Personal & Enterprise Solutions」。
  這裡提到的 Solution，除了微軟自己產品的 Solution 以外，
  也包含 3rd Party (ISV) 在微軟的平台上開發出來的 Solution，
  例如微軟的 Office、Exchange，3rd Party 的 ERP、CRM 等等的 Solution。
  跟以往 ISV 提供的 Solution 最大的差異是，由於底層是建構在 MS Cloud 上，
  因此這些 Solution 的延展性會非常大，但 Monotization 會有很大的改變。
  
• 目前底層的 Service 已經建置的差不多了，接下來很大的 efort 會花在第二層，
  並且要設法將現有的產品 (e.g. Office)轉化為利用第二層的服務來提供功能，
  未來微軟的新產品目標也都是建構在這個 Platform 上，
  藉由 Cloud Computing，微軟也希望接觸長尾效應的末端、累積起來量也是相當可觀的潛在客戶。而微軟(內部)的Service也將更有彈性和擴充性(理論上不會掛掉)。
  
• 以上是最重要的部分，另外還提到了一些機房管理之類的東西，
  還有微軟認為像上述那些底層的服務，應該交由專業的廠商來提供，
  例如機房的管理就需要專精的廠商來提供，Storage 也有專精的廠商來負責。
  另外他也提到了 Google 的海上機房專利(一時間找不到比較官方的資料@@a)，
  也是很有趣，不但很酷炫，而且一整個節能減碳，不過資料傳輸是比較麻煩。
  
  但是這樣會有很多困難需要克服，例如：
  
  (1) Service Level Agreement (SLA) 的定義。到底是要由 ISV 負責，
       或者是由更底層的平台廠商負責?
  (2) 資料隱私權的問題。一方面來講是 User 會不會放新將資料交給平台廠商管理?
      另一類型的 User 是永遠也無法將資料放到 Cloud 的，例如國防部。
      對於國防部之類的客戶就沒辦法了，不過要說服一般客戶的確是很大的挑戰。
  
• 在時程規劃的部分，預計在今年的 PDC 大會就會釋出 Beta 板的 Cloud SDK，
  其實現在已經陸續有各種服務提供出來，例如 Office Online、Exchange Online，
  SQL Server Data Service 等等，未來基本上微軟各個主力產品都會有 Online 版，
  如 SharePoint, BizTalk, Identity Server, 等等的，
  另外下一場的講師也有作一個 BizTalk Service 的 Demo，相當的淺顯易懂。

 

1020 ~ 1130
課程主題：微軟在SOA上的策略與願景
講師：李匡正

這場的議題主要圍繞在「微軟對 SOA 的解釋和想法」，跟上一場也有些關連，
首先一開始要強調的是，SOA 是為了解決企業內不同系統間要互相溝通的難題，
而逐漸發展出來的一種 Architecture，因此並不是一個實際的「產品」或「Protocol」，
實際上可以用各種方式(語言、平台)來實作，嗯，這算蠻基本的。

另一個 SOA 的特性是非同步 (Async)，由於一項功能是由分散在外的 Service 聯合提供，
因此很難確保要做到即時的回應，因此諸如 Local Storage, Synchronization 等議題就變得更加重要了。也因為這樣的特性，造成 SOA 並不一定適用於所有的 Application。

接下來他提到了 WOA (Web Oriented Architecture) 的概念，
稍微Google一下就會發現這個概念並不新，在2006 Open Source Conference就有討論。
跟一般人認知的 SOA 是應用在企業內的封閉網路中不同的地方是，
WOA 強調「Web」，意味著這樣的架構是對外開放的 (Internet)，不侷限在企業內，
顯然在安全性上需要考慮的更多 (我想可能也有更多 Service Composition 的可能)。

另外就是 WOA 似乎都走比較輕量級的通訊協定，例如 REST，
SOA 通常都是走 SOAP。(WCF未來會支援 REST，但主要還是走 SOAP 的樣子)

然後接下來 ... 不是很記得微軟在 SOA 上又有另外發明甚麼架構，
基本上架構應該就是上一場周講師講的那個 Windows Live Platform，
在 IDE 上，微軟的目標是希望 Visual Studio 的 Design Style (experience) 能夠做到不管是開發傳統的 On-Premise Solution，或者是 Cloud Solution 都能夠一致。
Visual Studio 本來就是超強大的開發工具，繼續投資也是可以預期的。

另外李講師則是以 BizTalk Service (現在似乎是 Alpha 版) 的開發來做實例，
為了讓 VS 的開發方式維持一致，微軟針對 BizTalk 開發了一套「Cloud Activity」，
用起來就跟 Workflow Foundation 中的 Activity 一樣，一切都是拖拉就搞定，
然後不可免俗的又是利用 WCF 來 demo Cloud Service 間彼此如何溝通。
(果然如同祭司說的一樣，如果不會 WCF、WF，以後研討會聽起來整個就很不好吸收)

看來微軟是非常重視 BizTalk 的，而 Workflow Engine 未來也會扮演很重要的角色，
這方面的發展應該要持續的觀察。

呃 ... 寫到這裡發現似乎沒辦法整理得很好，不知道為什麼好像沒有記住很多細節 XD
(其他還有講到 Internet Service Bus, CardSpace 的目的是支援聯邦式的認證，從 outsourcing --> cloud-sourcing 等)
可能對SOA已經有點麻木了，而VS的 Demo 也沒有辦法多神奇，反正就是很簡單的樣子，
加上 Windows Live Platform 有比較清楚的架構圖，So ....
這一場的心得就讓我草草的結束吧！ XD

Microsoft TechEd 2008 心得 - Day2-2

Day2 -2

1330 ~ 1440
課程主題：It's the 21st Century: Time to Throw Away Your Medieval Gateways
                - 21世紀的資安事件中，市場上的擋火牆真的能保護你的資料嗎?
講師：Steve Riley

Here is Steve's Blog, and this post (directly connect to your copnet with IPsec and IPv6) is the topic in this session.

我覺得Steve的presentation skill很厲害，非常懂得如何炒熱氣氛 (他本身也很high)，
他現在的Title是 Senior Security Strategist，
聽起來整個就很高級而且很賺 (但是相對的也很困難，各方面都要懂得很深入)，
他主要的工作就是在像TechEd這樣的conference講安全性的議題 (到處飛來飛去)，
而議程內容主要就是利用平常沒講課的時間，
不斷的跟微軟內部的developer討論，還有接受客戶的feedback來決定的。

這堂課聽到的幾個重點如下：

1. 就工程上(或者科學上)來說，「前提」或「假設」是非常重要的。
   因為系統/protocol所有的設計/功能，都是在一開始定義好的前提下進行的，
   當前提是不夠周全(甚至是錯誤的)，駭客就會想盡辦法侵入你的系統。
   
   舉一個最簡單的例子，如果你有一個功能的假設是：
   「這個欄位使用者永遠不會輸入負數，所以程式只要處理正數和零」，
   那麼這個系統就會處於一個危險的狀態，因為當駭客察覺到這個前提後，
   就會千方百計的把負數扔進那個欄位，這時候系統可能就 crash 了。
   
   其實仔細想一下，這個精神可以廣泛套用到生活上的各層面，
   包括經濟、政治、法律等等，當有人可以設法讓某樣重要的前提失效，
   隨之而來的通常就是難以想像的巨大利益。
   
2. 環境的改變會對系統的各層面產生巨大的衝擊。
   這裡講的「環境」，也就是第一點所講的「前提」的很重要的一種，
   通常系統很容易就會針對目前設定(短時間內)要運作的環境來進行設計，
   因此隨著時間的流逝，一定要不斷的對系統進行重新修正，
   否則會漸漸的產生越來越大的漏洞。(因為環境的變化太大)
   
   當然另一種做法就是將老舊系統淘汰掉，重新針對現在的環境設計新的系統。
   
   以Internet 來說，最早期(約在上世紀60年代)第一次形成機器間可溝通的網路時，
   那時候大約只有5台機器，15個人，5個 Application (其實詳細數字我忘了XD)，
   因此是 trsuted network, trusted machine, and trusted people.
   所以他們那時候壓根沒想到要注意所謂「安全性」這回事。
   
   據說在第一版的 Internet Protocol (RFC 791)中的最後面有提到，
   在這個 protocol 的 development中，「Security」並不列入考慮。
   
   當然現在的新版文件裡面都有強調 Security 了，
   不過 Steve 說看到這句話應該會 strike the very core of your soul，
   想想也是沒錯，現在每天這麼大量的機密資料(金融, 個人, etc.)的傳輸，
   靠的就是當初設計時根本不考慮安全性的通訊協定(而且好老了)，實在是很可怕。
   
3. 愛因斯坦對「瘋狂」的定義：你一再的用相同的方式重覆做同樣的事情，
   但期望做到最後會得到一個不同的結果。
   
   這裡要強調的是說，現在已經有各式各樣關於安全性的資源，
   告訴你怎樣的程式碼會導致 XSS / SQL Injection，
   如果不小心管理防火牆 policy /不做 update 就很容易會被入侵等等，
   但如果你還是用舊的方法在寫程式，用舊的思維管理你的網路環境，
   卻期望用舊的方法做事可以避免新型態的攻擊，那麼你就是瘋了，
   因為這是絕對不可能的事情。
   
4. 關於課程的主題，簡單說就是一套利用IPsec和IPv6讓員工/客戶能夠從地球上任何一個角落，安全的連線到公司內部網路的做法。其中有很多細節其實記不太清楚，
   不過可以參考他的Blog。
   
   其中一個重要的觀念是，sadly, 對於要從 Internet 進入 Corpnet 的資料，
   必須要預設這些資料都是有害的(malicious)，直到證明它們是無害的為止。
   這個原則就是第一點所講的「前提」，必須要有這樣的假設，
   才有可能真正建構出一個安全的企業內網路，例如假設天真的假設所有從所謂 "trusted sources"收到的資料都是 OK 的，不另外進行檢查，
   那麼當這些 "trusted sources" 被駭客攻陷的時候，你的企業網路就準備等死了。
   
   另外他提到為何防火牆應該僅過濾Inbound Data，而不應該處理 Outbound Data，
   大致上是說正常來講，有問題的資料都應該被擋在外面，
   因此企業內部都是安全的資料，因此內部機器間的資料傳輸應該不需要檢查，
   當然這樣講聽起來也沒錯，但是我覺得並非所有資料都會經過防火牆的檢查，
   例如員工用隨身碟或者藍芽手機來傳輸的資料等等，當然這也牽扯很廣。
   
   其實內建在 Windows Server 2008 裡面的防火牆就有 Inbound & Outbound Rule，
   可見在某種程度上還是需要對Outbound Data作一些管制，
   例如合理的限制沒有權限的User就不能透過他的機器對Server作一些要求等等。

 

1510 ~ 1620
課程主題：Virtualization and security: what does it mean for me? 
                - 虛擬環境架構下該如何建置資安系統【英語演說】
講師：Steve Riley

這一場還是由Steve主講，重點擺在隨著 Windows Server 2008 推出的 Hyper-V (Virtual PC 的下一代)，很深入了介紹了 Hyper-V (hypervisor) 的設計理念和架構，
不外乎就是架構多好多好，Hyper-V 多安全多安全等等(另外配合一些實例)，
另一個重點是要打破「在虛擬化的環境下，舊有的」
因為講了一大堆細節，對virtualization又沒啥研究，因此印象不深，
就記憶所及的部分有以下幾點 (過一陣子應該可以直接抓投影片來看，超精美)：

1. 特別強調 Virtual Machine 跟 Hardware 的 Isolation。
   由於若允許虛擬層直接存取到硬體層，那麼若VM受到感染，
   可能就會對實體機器造成很大的威脅，因此實際上跟硬體間的溝通，
   主要還是透過Host系統內的Hypervisor來進行。
   
   另外一個重點是 Hypervisor 裡面只會有微軟自己的Code，
   這段主要在講說 VMWare 的 ESX 似乎有提供 3rd Party 客製化的部分，
   Steve 是 argue 說在如此底層的原件摻雜外部的 Code，可能造成相當的危險，
   因此為了客戶的安全，微軟是不會幹這種事情低！
   
   不過講到後來，在 Hypervisor 的 Future Version 中，
   似乎又會開放 Interface 出來，讓虛擬層能夠直接跟硬體溝通，
   目標應該是為了要提高效能，但是這樣似乎跟前面強調的 Isolation 有衝突，
   不確定到底是怎麼回事... 不過起碼目前版本的 Hypervisor 表面上聽起來很安全XD
   
2. Hypervisor是RUN 在 Ring-1 (應該是吧@@)，舊的 CPU 的架構中最底層是 Ring0，
   在新的CPU架構中變成多出一個Ring-1，這裡我也不太懂，等很有空再找資料看。
   
3. 在虛擬化的環境中，「安全性」的各項議題跟以前都是一樣的。
   簡單說就是在攻擊 Checkpoint 這陣子推出的虛擬防火牆啦 XD ..
   似乎在 VMWare 的架構中，可以允許 VM 間彼此透過特殊 protocol 溝通，
   但是在微軟的架構中，VM間也是透過標準的網路架構來溝通，
   因此基本上每個VM只要依靠本身的防火牆+防毒軟體就可以阻絕各種惡意攻擊了，
   並不需要另外花錢建置所謂的「虛擬防火牆」。
   
   另外他也舉例到，從最早的 DOS 是 1Machine+1User+1AP，
   到Windows 3.1 (1Machine+1User+nAP)，Windows 95+ (1Machine+nUser+nAP)，
   其實都是在 fool the machine，實際上在任何一個時間點永遠只有 1User + 1AP，
   因此在 Virtualization 的環境下，就是 1 Real Machine + n VM + nUser + nAP，
   只是 fool 的程度更上一層樓而已，本質上是沒甚麼差異的，
   舊有的安全性觀念和 practice 仍然適用，至於是否會衍生出新的威脅，
   就要看前面兩點所說的虛擬層的架構設計問題了。
   
4. VM的好處，在於可以很方便的觀察駭客如何進行惡意攻擊。
   因為是VM (本質上是一個在 File System 中的檔案)，所以掛了基本上也不太痛，
   隨時要做新的VM或者還原的effort基本上比搞一台實體機器低得多。
   因此VM也很適合拿來測試Beta版的軟體，或者開發中的系統等等。
   
   雖然有人會 argue 說駭客可能會讓惡意程式偵測是否處於VM的環境中，
   若判斷屬於VM則不發動攻擊等等，但是目前實際上在網路上的機器，
   根據統計可能已經有將近 1/3 都是VM，而且現在的攻擊多半是自動化+大規模，
   因此透過VM來研究駭客的惡意程式仍然是有效且成本低廉的方法。
   
   因此，Steve 也很鼓勵 developer 利用 VM 的 sandbox 特性，
   來測試並修正自己系統中可能存在的安全性問題。
   (＆ 觀察駭客如何進行攻擊永遠是一件很好玩的事 XD)
   
5. 只要有新的 Security Update 出來，請立刻執行修補的動作，不要等測試完畢。
   在這邊 Steve 是拿美國空軍來做例子，他說以前美國空軍的 update 總是慢一拍，
   因為每次有新的 update 出來都要在測試環境通過一系列的測試，
   等到確認沒有問題之後才會真的進行 deploy，等到完全 deploy 完，
   時間可能差距達兩週甚至一個月。後來他們覺得這樣不行，因此進行研究，
   最後發現 update 一出來就立刻進行更新，更可以有效降低被入侵的風險。
   
   由於現在的0 Day Attack越來越多，就算在一天內就能測試完畢，
   這中間的空窗期仍然可能遭受很大的威脅，Steve 的另一個 argument 是說，
   如果裝了 update，導致你的系統掛了，那就表示你的系統是依賴在這次被解決的弱點上，所以是你的系統有問題！不是 Microsoft Update 的錯！
   
   我覺得這個說法是蠻有道理的，雖然可憐的developer往往是被客戶要求，
   用各種詭異的手法來完成客戶要求的功能，才會造成上了update系統就掛了。
   
   不過 ... 微軟以前老是喜歡不走標準，搞自己一些特殊的格式或與法，
   然後在新版的軟體中洗心革面的改走標準的路 (e.g. IE8)，
   而造成一大堆舊的程式掛掉，這也是很鳥的事情 ...
   
6. 按照一套標準的Hyper-V建置作法，那麼Hyper-V幾乎是牢不可破的(就是說VM掛掉不會害的Host系統也跟著死掉)。詳細步驟要看投影片，印象中包括以下幾點：
   
   (1) Host System should be Windows Server 2008 - Server Code.
        重點就是盡量減少 Attack Area，這台機器就全職負責Host VM即可，
        其它的功能基本上能免則免。
   (2) 該開的防火牆一定要開，公司的 Security Policy 要貫徹，
        (Windows) Update 一定要隨時保持最新等等。
   (3) 其他實在是不太記得了 .. @@"

 

1650 ~ 1800
課程主題：高效能運算平台High Performance Computing Server 2008 - 管理與部署介紹
                Advanced Overview: High Performance Computing Server 2008
講師：楊勇克

很不幸的，這位講師是道地的港仔，因此大概在開場的一分鐘內，
我和我同事兩個就瞬間體認到，普通話對他來講是很吃力的，
反過來說，他的普通話對我們來講也不是聽得相當舒爽，
再加上其實這堂課是屬於 MIS/ASE 的課程， 他講的也是非常 detail，
所以聽了十分鐘之後我們就閃了，很多人還比我們更早走哩 ~~

所以這堂課的心得就是，阿鬼阿，你還是講中文的好... (真是相當老的梗 Orz)

PS. 希望下次請香港講師來上課的話，可以全程用英文講，
      這樣真的對大家都好，我覺得楊講師也是很無奈而且很努力低~~

PPS. 因為對 Steve 講課的 Style 印象太深刻了，所以就先寫好PO出來，
        晚一點再PO關於微軟SOA和 Cloud Computing的心得。

HowTo: 修改 Vista Theme & System32/shell32.dll

呃 ... 本來昨天就要開始寫 Microsoft TechEd 的心得， 但是發生了一個意外導致我把小黑重灌了， 好不容易弄到剛剛終於大致上搞定，所以先記錄一下處理這個意外的過程..

所謂的意外，就在我下載了這個黑色的 Vista Theme (Project X2) 之後開始， 按照他的說明文件，在覆蓋系統檔案 (System32中的browserui.dll & Shell32.dll)之前， 應該要先取消 UAC 的檢查，但是我想說 UAC 打開也不過是檔案操作要多確認兩次而已， 而且調整 UAC 的設定又要重開機，整個很麻煩，所以我還是讓 UAC 開著不管它...

接下來我先覆蓋了 System32/browserui.dll，嗯，一切正常！ 這時候我對於繼續打開 UAC 的決定又更有信心了， 下一步，rename舊的shell32.dll，一次成功 ！
 
接下來把新的 Theme 裡面的 shell32.dll 複製過去，跳出 UAC 視窗，確認OK，
接下來，檔案複製完畢！看一下 System32 裡面的狀況：

什麼事都沒有發生 .......冏~


雖然看來複製的動作已經完成，沒有跳出甚麼錯誤，但 refresh 之後， 顯然 System32 裡面只剩下被我改名成 shell32.dllold 的舊 dll， 應該已經被複製過來的 dll 連個鬼影子都沒看到，God， 這怎麼可以，不信邪的我再接再厲的重複上面的步驟...

System32 裡面還是甚麼都沒有 ....... @_____@"

這個 shell32.dll 從名稱來看就絕對是比其他 dll 更重要、更核心的東西， 如果就這樣莫名其妙的被我搞到消失了，想必會有很多問題， 這時候我想，幸好剛剛沒有把舊檔直接砍掉，而是用 rename 的方式改掉副檔名， 那我再把副檔名改回來就好啦！！

事不宜遲，馬上開始動手修改，這時又跳出UAC的確認視窗， 廢話我當然非同意不可呀，同意之後開始執行rename，很順利的執行完畢！！ 趕快再檢查一下 System32 裡面的狀況：

shell32.dllold 居然繼續給我完好如初的活著！！
 
rename 完全是無效的！！Good, 這下真的是冏翻了，我把一個雖然不太清楚是幹甚麼用，
但是檔名裡面有「shell」這個超明顯重要關鍵字的 dll 搞壞了， 想必是不會有甚麼好下場，接下來努力嘗試其他各種方法，包括把 Vista 自動為系統檔案建立的 Shadow Copy 複製到其他資料夾， 再試圖覆蓋回去正確的System32資料夾也失敗，實在無計可施之後， 只好硬著頭皮重開，看看我的系統死狀到底如何...

在重開的過程中，原本以為會見到久違的 Blue Screen， 結果也沒有，似乎基本上系統運作還頗為正常， 但是就在進入登入畫面之前，跳出一個錯誤訊息：
 
「UILogon.exe 無法取得 shell32.dll，重新安裝應用程式可能可以恢復正常。」

God !! 莫非這表示我連可以正常登入系統的一絲希望都已經破滅， 可以直接考慮系統還原了？！幸好在按完確認之後，還是正常的出現登入畫面，讓我鬆了一口氣， 試了一下也可以正常登入，但是最冏的情況就在此刻發生，一個新的錯誤訊息告訴我：

「explorer.exe 無法取得 shell32.dll，重新安裝應用程式可能可以恢復正常。」

薑薑薑 ~~ 薑！答案揭曉了，explorer.exe 這個負責繪製 Windows 最基礎的 UI (桌面、檔案總館等等) 的重要程序給我直接死在沙灘上了，畫面上剩下一片令人心寒的烏漆媽黑， 只有一個孤獨的鼠標可以自由自在的移動，這樣我的系統不是相當於全毀了嗎 >_< ...

接下來我就繼續嘗試用 Safe Mode + Comman Prompt 開機， 無奈搞了半天我的小黑對 F8 就是毫無反應，這時候我仔細的想了一下， 剛好之前裝了Lenovo的System Update之後，很多內建Driver的介面都莫名的掛了， 不管是 Fn+F5 (設定無線通訊) 或者 Fn+F7 (設定簡報模式) 都變成無效， 加上現在系統裡面的beta軟體太多，乾脆就忍痛還原到出廠狀態， 利用這個機會重整系統吧！

接下來大約七到八個小時就耗在還原，還有還原後要做的 Windows Update， 灌一大堆 Utility 軟體、Office、四個Browser上面，系統弄得差不多之後， 我又開始手賤的想要嘗試把之前設定失敗的Theme給搞定， 在說明文件裡面寫說，shell32.dll 的作用是：

「This changes the image that is in the left hand pane of some places like the control panel, and you computer properties window.」

感覺就很酷炫的樣子，一定要想辦法把它裝起來的！！
 
但這次的設定我還是不信邪(換句話說就是腦殘)的按照上次的模式進行， 自以為上次只是運氣不好，可能本來系統就怪怪的，才會出現這種狀況， 很明顯的，我錯了！！

系統在我的惡搞下，相當迅速的呈現了跟昨天一模一樣的死亡狀態！！
 
shell32.dll 完全不給我一個替它正名的機會，堅持停留在shell32.dllold的狀態， 這時候我想到另一個解法，就是把小黑的硬碟拆下來裝到USB外接盒裡面， 再拿另一台系統正常的 NB 來直接複寫 System32/shell32.dll， 果然，這個簡單的做法是 Work 的！！


歷經了千辛萬苦又把shell32.dll還原到正常狀態之後， 接下來我就乖乖的把 UAC 關了，然後重開機， 然後把 shell32.dll rename，接下來複製新的 Theme 裡面的 shell32.dll 到 SYstem32，
薑薑薑薑~~！這次果然很順利的成功了！


這次的事情讓我想到 Microsoft TechEd 的講師 Steve Riley 提到愛因斯坦對於「瘋狂」的定義， (坎尼沒想到我這樣也可以扯到 TechEd 吧 XDD)

愛因斯坦說，瘋狂就是你一再的用相同的方式重覆做同樣的事情，
但期望做到最後會得到一個不同的結果。


我想把「瘋狂」換成「愚蠢」也是很貼切低！！ 冏rz

Anyway, 以下就是我換好Theme之後的畫面：


而所謂的「the image that is in the left hand pane of some places like the control panel, and you computer properties window」，就是下面這樣：


Computer Properties Window:


其實也不過就是黑成一團，好像沒有特別值得我為它搞得人仰馬翻嘛 ...=.=
最後得到的教訓，一個是說明文件一定要認真看，照著做，
另一個就是不要忘記還有把硬碟拆下來，用另一個正常系統來處理這個大絕招!!

PS. 小黑還真難拆，螺絲緊的跟甚麼一樣，各機構的配置也和大台的NB整個不太一樣，
慎重考慮等颱風過了去買一組電動螺絲起子工具組，不然以後老了就再也打不開了 ..

DataGridView 分頁

坎尼又來講分頁了 (你怎麼那麼愛講
不過標題上寫的是 DataGridView 分頁
「到底是 DataGrid 還是 GridView 啦」
哈 其實是 System.Windows.Form.DataGridView

---

這東西是 WinForm 裡的資料展現容器
和 WebForm 上的 DataGrid 還是 GridView 看起來很像
其實骨子裡相同點倒是不多

首先稍微講一下 WinForm 和 WebForm 的差異
1.WinForm 裡沒有 也不需要 Session
2.資料繫結無需再下 DataBind() 動作 (也沒有 DataBind() Method)
3.ComboBox的 SelectedIndex 事件，在後端指定Index 也會去執行 Event
4.下拉選單在 WinForm 叫做 ComboBox 而且它只有 Text
好啦 目前大概知道這些就夠用了 (再寫下去篇幅會太長

再來就是講一下 為什麼要講 DataGridView 的分頁
因為它沒有內建分頁功能啊啊啊啊啊

所以坎尼用了最古老的方式 -- 自己算目前頁數的顯示資料

另外分頁的控制項沿用之前坎尼講的 自訂分頁

不過由於沒有 PagerTemplate

所以坎尼拉了個 Panel 再把拉了四個 LinkLabel 再加個 ComboBox 和 Label

先來看一下畫面


先宣告個全域變數 iCurrentPage 用來記錄目前的頁數

再來是寫換頁事件 這邊會看到坎尼用 LinkLabel 的 Tag 來記錄按下的鈕
當然 Tag 裡可以換成 Previous Next First Last 這種比較容易了解的文字

可以看到 Tag 裡值為 1 為第一頁 2為上一頁 3為下一頁 4是最後一頁
這邊要注意的是 坎尼用 -5 這個當做 iCurrentPage 的數值

接著就會跳往 ShowData 函式
可以看到 其實 ShowData 裡的東西實在沒什麼 XD
這裡會呼叫 Paging() 以取得繫結的 DataTable

再來就是最重要的 Paging 函式 先來看上半部
先由 GetData 函式取得查詢出來的資料 並宣告一個 dtReturn
接著就是判斷 iCurrentPage
這邊就會看到坎尼把最後一頁的參數設為 -5 的用意

先來看 if 的前半段 如果 iCurrentPage 大於等於 最大頁數
iCurrentPage 當然就是最後一頁 (iCurrentPage = dt.Rows.Count/10)
iCurrentPage 若小於0 當然就是第一頁 (iCurrentPage = 0)

由上面可知 不管怎麼按 上一頁 iCurrentPage 最少都只會是 -1
所以坎尼才會用 -5 來當最後一頁的參數 (當然 要用 -4 -6 -8 都可以
這邊還要注意一點的就是 坎尼是用一頁十個項目為基準

然後會看到一些 enable 的設定 只是讓顯示上好看一點 沒加上去也沒關係


繼續下半部
下拉選單的項目坎尼是讓系統每跑一次就重新產生
再把目前的SelectedIndex 設成 iCurrentPage (這邊會引發 IndexChanged 事件

最後是最重要的部分：建立要資料繫結的 DataTable
由於每頁為十筆 所以目標頁面的 index 是以 10 * iCurrentPage 為 起點 往後十筆
並將這些Row的資料 Add 進 dtReturn 裡
然後回傳給 DataGridView 做資料繫結的動作

最後是 下拉選單 的 IndexChanged 事件
這邊加入判斷式 為了不讓程式進入無窮迴圈 XDDD
想知道為什麼的人 可以將 if 給註解掉 然後設中斷點跑跑看 :p

下面就是執行畫面 (一張跑到上面去了)


好啦 又是落落長的一篇 (上次講分頁也是這樣
都不知道大家有沒有聽懂? (抓頭

總結一下
WinForm 的 DataGridView 沒有分頁事件
只要給予 DataSource 則會跑出所有資料
所以坎尼將資料處理過 每次都給 十筆資料 的 DataTable
這樣資料繫結完就會只跑出十筆

ps. 範例裡是以一頁10筆做基準
若想自訂分頁筆數 只要將 paging 裡的 10 改成 其他數字即可

.NET 中文字簡繁轉換

趁 Tim 這幾天去參加 Tech Ed 上來偷發文
反正他已經預定要寫心得文了 XD

---

在 上一篇 坎尼有提到
將 byte[] 裡的值利用 Encoding.Default.GetString 的方式給抓出來
不過坎尼這幾天都面臨了繁中轉換的問題
由於資料是用 GB 碼編成的 

所以轉出來的東西在繁中的 OS裡是無法閱讀的

所以坎尼上網谷歌了一下  這個

不過這篇是繁轉簡  所以坎尼另外再去找了 字碼對照表

於是乎  坎尼很高興地  加入了 Miscrosoft.VisualBasic 參考

然後就按下轉換鍵   很興奮的用 notepad 打開轉完的文件

怎麼會有 ? 之類的字!!!!!  (翻桌

想說怎麼這東西這麼鳥  很多字都無法對應過來

後來坎尼把谷歌大神給我的東西往下捲了幾頁  看到了 這個

原來是坎尼傳入的系統對應ID問題   (0x0404明明就寫 台灣-中文

把 ID 的部分改傳入 中文 RPC  (代號 2052) 就成功了

以下是程式碼

需要注意的地方是  由於資料是 簡體 GB 碼

所以 Encoding 後面是要接 GetEncoding  然後傳入 簡中的 對應code

如果用 Default  則 .Net 會用目前的系統編碼的方式讀入

此時就會看到一堆亂碼了  哈

再來就是把抓到的字串  丟入 VB 下的 Strings.StrConv 去轉換

大功告成!!!!  byte[] 陣列裡的字請大家試著轉轉看 :p

Binary Stream 讀取一些小心得

最近處理一個轉檔的程序
剛好要碰到比較基層的位元讀取
所以坎尼把一點點小小心得給寫出來

---

首先，要講的是 Stream 類別
Stream 在 .NET 2.0 裡又分為很多種
有 FileStream、MemoryStream、BufferStream...
但一般常用的應該是 FileStream 類 用來將檔案內容讀出

再來就是存取資料的容器 (直接用 FileStream 也有 Read 函式)
不過這次由於處理的資料需要將位元抓取出來 並換轉成數字或文字
所以坎尼研究了一下 BinaryReader (使用方式見下圖


BinaryReader 直接提供了很多種讀取方式
可以滿足一般人的需求 XD

不過使用這些函式時要注意一點
它們都是以目前 Stream 讀取到的地方當作起點
讀取完並向前推進

比如說 目前將檔案讀取到了第 24 byte的地方
ReadInt32 函式就會往前讀取 4 bytes
而且目前的 index 會變成 28

不過這種要多少讀多少的方式算是中規中矩
速度不快 但很穩

可是坎尼這次處理的是較大型的檔案
所以坎尼偷吃步的先把所有的資料讀進一個 byte 陣列中
再去對些陣列做存取
這樣做的好處有：很快、可以隨意取出資料
壞處當然就是很耗資源 常常一下子就發生 OutOfMemory 的慘劇

當然 這個 byte 陣列要怎麼轉換成數字及文字呢?
.NET 提供了以下的方法
在 System 這個 Namespace裡 有個 BitConverter 靜態 Class
提供的方法大致上和上面 BinaryReader 的讀取函數差不多
只是需要傳入要轉換的 byte 或 char 陣列 以及 index


上面是取得數字 再來是要講如何取得文字
在 System.Text 底下有個 Encoding 的靜態 Class
平常坎尼都用它來轉換編碼 沒想到它竟然內建了 GetString 的方法

GetString 前面的 Default 就是以當前預設的語言編碼去轉換
這地方可依個人需求改成 utf-8、unicode、ASCII....

GetString 則是要傳入要轉換 byte 陣列
另外還有 index 及 count (另一個多載方法可不傳入

抓圖裡這段 code 就是指

在 b 這個陣列的第5個 byte 開始 抓取 12 個 byte 資料
將它轉換成文字
當然 這地方要確定真的是文字 不然抓出來可能是些奇怪的符號

大致上講到這邊 坎尼對 IO 的研究也沒有很深
家裡那本 IO 存取的書 買到現在才將本機存取的部分看完 orz
還有一半在講網路 IO 的 可能要等哪天興起拿起來翻吧 囧>

另外補充給 Tim
其實這個和 Sql Server 裡存的 Binary 資料存取方式應該不太一樣
Sql Server 那個坎尼也沒研究過 只知道可以把圖片直接轉成 Binary 丟進去存

Windows SharePoint Service 3.0 網站設定

經過了一番奮鬥，好不容易成功的執行了還原之後，一開始很高興的在intranet裡面連來連去，感覺一整個正常， 本來以為大概搞定了，沒想到晚上回家以後手癢試了一下， 很快的就發現從internet上是無法連線的!!!


到了這時候很明顯的是網站的設定出了問題， 但是之前負責架站的前輩已經離職了，
因此只好慢慢摸索，可憐的砍尼還一直被我騷擾幫忙測試，（嗯，你是好人～）
 
最後終於整理出以下的設定方式：

• SharePoint 網站的設定方式：
  在還原好WSS網站後，在「目錄安全設定」中，預設會是「整合式Windows驗證」，在這樣的設定下，intranet access是沒有問題的，但是從internet連線的時候，會直接跳出「HTTP 401.2」的錯誤，而不會跳出輸入帳號密碼的驗證視窗。經過跟MIS的確認後，
  由於公司有使用proxy的關係，因此必須將「驗證的存取」部分設定為「基本驗證(使用純文字傳送密碼)」，如此在internet連線的時候就會正常跳出驗證視窗。
  
  另外要注意的是，「啟用匿名存取」一定要取消掉，否則上述的驗證視窗一樣不會跳出來，而且Search Engine的crawler不用經過身分驗證就可以進來爬資料，如此直接就造成(公司/個人)資料外洩，因此一定要取消，強迫所有的連線都要通過身分驗證的程序。
  
  
  
  
• download網站（連到另一台file server提供檔案下載服務）的設定方式：
  
  • 不考慮proxy (無法提供Internet access，第一次restore之後的作法)：
    此時SharePoint網站的「目錄安全性設定」勾選「整合式Windows驗證」。建立虛擬目錄，別名為「download」(大小寫沒差)，路徑指向\\myFileServer/mtSharedFolder，而後點選在「網站目錄」右邊的「使用者名稱」按鈕，在此採用一個有效的AD Domain帳號。
    
    如此設定可以讓intranet透過AD驗證來存取網站的內容，但是整個portal本身從Internet上會變成無法存取。
    
    
    
    
  • 正確作法(考慮proxy)：
    跟MIS確認之後，應將SharePoint網站的「目錄安全性設定」勾選
    「基本驗證(使用純文字傳送密碼)」，如此從Internet上連線到http://MyServerName.com的時候，就會跳出驗證視窗。
    
    做了這樣的調整之後，變成原本的download網站無法存取，
    因此需做以下兩個調整：
    
    (1)將download網站的「目錄安全性設定」改為
       「基本驗證(使用純文字傳送密碼)」。
    (2)點選「網站目錄」右邊的「使用者名稱」按鈕，勾選「當要確認到網路目錄的存取時永遠使用已驗證過的使用者認證」。
    
    
    
    
• 網站連結失效問題
• 原本以為經過上述的步驟，應該所有的設定都大功告成了，
  但是透過一些掃描broken link的工具（e.g. FF LinkChecker）挑了幾個網頁來掃描之後，發現有些連結失效了！原來是在WSS中建立「上方連結列」(或其他連結)時，是不用輸入網站的根目錄的，直接輸入網址即可。
  
  在這樣的情況下，WSS會以http://server_name/作為根目錄，而不是「http://MyCompanyDomainName.com.tw」，如此當Server更名的時候可能就會造成連結失效。
  
  因此最好在每次建立新的頁面或連結之後，確認一下網站的根目錄應該一律調整為「http://MyCompanyDomainName.com.tw」，如此未來要還原到其他VM或者是Server更名都不會有影響。

以上就是最後完全設定、修正完畢的過程，經過了這次修復WSS的慘痛SE經驗之後，
最後再整理一些結論：

1. 平時一定要用stsadm tool做好備份檔，並且妥善保存，否則當server掛點的時候，保證很難還原的回來！這一點我再強調一百萬遍都不夠～
   
2. 用Google找資料時，要小心WSS 3.0和MOSS 2007是完全不同的東西，另外用「WSS」當關鍵字，往往效果不如「Windows SharePoint Service」。
   
3. WSS可以考慮run在VM上，這樣做的好處是萬一當實體機器掛了的話，可以先暫時把VM備份倒出來，移到另一台機器上run，可以更快的暫時恢復服務。缺點是VM並不一定會每日備份，因此資料的狀態很可能會回溯到一段時間以前，這時候在利用每日的stsadm備份檔將Portal完成還原之前，建議不要修改暫時復原的VM上的Portal的資料內容。
   
4. 在WSS中建立「上方連結列」或其他連結時，要注意是否不用輸入網站的根目錄，直接輸入網址即可。

Windows SharePoint Service 3.0 備份 / 還原經驗談

在大略介紹完WSS的功能還有技術內涵之後，接下來就進入在血淚交織(？)中獲得的寶貴經驗 -- 如何執行 WSS 備份與還原，由於是因為 server 掛了才開始研究的，因此先從還原看起：

• WSS使用的資料庫
  由於還原的過程中，牽涉到設定新的資料庫，或指定現有的資料庫，
  因此必須先了解一下到底WSS用到了那些資料庫：
  
  
  
  • SharePoint_Admin_Content_xxx (xxx是亂數編碼的結果)：
    這個DB儲存WSS Admin網站的相關內容，包含目前的Server Farm下轄多少Server、網站等資訊。
  • SharePoint_Config：儲存WSS Server Farm中每個網佔有那些子網站、頁面、layout等等的資訊。
  • WSS_Content_xxx：儲存每個網站中的文件資料。這部份通常最佔空間。
  • WSS_Search_ServerName：每個網站啟動全文檢索服務的時候所使用的資料庫。
    
    
• 還原
• 想像中的作法：
  一開始我嘗試還原的時候，知道前輩有每日排程跑備份，只知道DB Server沒掛，資料庫都好好的，在「SharePoint 所有的資料其實都塞在DB裡」的印象之下，藉由無數次的Google，試圖先灌好基本的WSS Service以及Default Site，再透過「指定DB」的方式來做還原，事實證明這真的是難到爆了！！整個就是失敗的！
  
  首先在安裝WSS時，選擇的是「基本」，此時可以很順利的把 WSS Service還有Default Site裝起來，很高興的進入管理介面之後，發現可以順利把舊的「ContentDB」刪掉，指定到DB Server上活的好好的DB，這時候問題來了，要怎麼指定ConfigDB？
  
  雖然在安裝完畢，執行「產品設定精靈」的時候可以設定要使用哪一個ConfigDB，但是會遇上DB被舊的帳號密碼鎖住的狀況（cache），因此還要以stsadm tool執行「Updateaccountpassword」、「Updatefarmcredentials」等操作，但是搞了半天最後還是失敗了。
  
  因此結論就是，一定要透過 WSS 內建的 stsadm tool 來執行備份以及還原，其他方法都很複雜而且失敗率太高。
  
  
• 實際試驗成功的作法：
  
  最後在努力的翻箱倒櫃以後，發現其實前輩有設定在每日排程中利用WSS內建的stsadm tool進行備份，而備份檔也存在另一台server上！有了由stsadm製作的備份檔以後，就可以比較順利的進行還原啦！
  
  
• 如何安裝standalone的WSS
• 用來還原的實體機器或VM必須要加入AD Domain中。
• 第一部分的安裝畫面參考Angi’s Tech Trace(Part I)，在Step2-3的部分，選擇「基本」即可，預設會裝好完整的Admin IIS Site和Default WSS Site。
  
• 第二部分 「建立網站集合」的設定繼續參考Angi’s Tech Trace(Part II)，從Step4-5開始來建立新的Web應用程式，特別注意在Step4-7的說明中提到的「主機標頭」，要設定為一個有效的DNS。請注意，在DNS設定生效之前（舊的cache update之後），即使已完成Site Collection Restore，但從intranet上還是連不到此網站。
  
• 完成下述的Site Collection Restore之後，從Admin Site中將原本預設安裝好的Web應用程式刪除，網址如右：http://VM_MachineName/。
  
• Site Collection Restore(Ref)
• 範例：stsadm -o restore -url http://myServerName.com.tw -filename C:\Site.bak –overwrite
  
• 這是最後測試後可以正確work的方法，但缺點是會把所有的 DB （共四個）都還原到本機的Windows Internal Database（也就是SQL Server 2005 Embedded Edition），基本上千萬不要用Embedded/Express Edition（除非是在家裡架好玩的），因為會有實體DB Size的限制，萬一爾後真的超出限制的時候應該會寫不進去，到時候要調整一定會極度的痛苦！
  
• 在WSS所使用的DB中，主要是WSS_Content所佔的空間是最大的，所有的文件資料都塞在裡面，因此在完成restore之後，可以利用「SharePoint 3.0 管理中心」進入WSS管理介面，在「應用程式管理」-->「Web應用程式清單」中選擇還原好的網站後（會跳回應用程式管理畫面），再進入「內容資料庫」，將現有的ContentDB刪掉，而後新增一個資料庫，指到DB Server上完好如初的ContentDB就可以了。
  
• Catastrophic Restore(Ref)
  
  • 範例：stsadm –o restore –directory \\myBackupServer\temp\Site.bak -percentage 1 -suppressprompt -username theName –password theWord -preservechangelog
  • 按理說，我遇到的狀況是應該採用災難復原的方式，但是在嘗試過後，用上述Site Collection Restore的方式可以讓stsadm tool正確辨認備份檔，但是stsadm工具對UNC path一直有意見，不管怎麼試就是會出現「找不到備份檔」的錯誤訊息，因此最後沒有採用這個方法來還原。
    
• 在同一台機器上，若曾安裝過WSS，之後又進行移除，再來要重新安裝WSS的時候，會遇到這篇TechNet KB中提到的「Install and configure WSS 3.0 with Windows Internal Database」問題，找了一下資料，在這篇TechNet文章中有提到如何移除Windows Internal Database。

在成功進行還原之後，下一步就是趕快設定好備份的程序，不然哪一天萬一機器又掛了，或者Windows Server 2003瘋了，那我就只好跟著瘋了>< ...
 
以下是備份的作法：

• 備份
  
  • 作法：利用WSS內建的stsadm tool每日執行排程來進行備份。備份的時候採用「overwrite」參數來覆蓋前一日的檔案。由於根據最後測試的結果也無法採用Catastrophic Restore，因此後來備份時也僅採用Site Collection Backup。
    
    這部份作法的正確性（以及設定每日排程的作法)尚待確認，由於最近幾週可能都沒時間處理這個問題，因此要晚一點再另寫一篇文章補完了 ...
  • 範例 Command (Ref)：stsadm –o backup –url http://myServerName.com.tw –filename Site.bak -overwrite

其實在重複的做了幾次的實驗以後，發現 stsadm 這個工具也不算難用，
問題是官方還是缺少一個比較完整說明如何執行還原的標準程序，
大家都是靠網路上無數的苦聖先賢的辛苦和分享，
加上自己的嘗試，才慢慢進入狀況，可見清楚的說明文件有多麼重要。

最後再次強調，you MUST use the stsadm tool to run the backup procedure,
and you better keep the backup file safe, or you will be TOTALLY SCREWED if WSS server went down!
參考資料：

1. Stsadm command line tool reference
   
   • TechNet Homepage
   • Index for Stsadm operations and properties
2. Psconfig command line tool reference
3. Install and Configure Windows SharePoint Service 3.0

關於SqlParameter的一些想法

坎尼在 這篇 裡有提到
把 like 後面的 % 符號寫在 Parameter 的 Value 裡
不過 SqlParameter 應該要擋掉關鍵字不是嗎?

坎尼經過剛剛沉思了數小時 (扣掉看電視和聊 msn 還有看 blog 的時間
得出一個結論 (當然是我的猜想

% 會被 SqlParameter 當成一般的文字在處理

為什麼呢? 請聽坎尼娓娓道來

一般大家在下 like 的 T-Sql 會怎麼寫呢?

select * from table1 where column1 like 'abc%'

這串會把 所有 column1 裡 abc 開頭的資料都抓取出來
但是如果改成下面這個樣子呢???
select * from table1 where column1 = 'abc%'

我們可以得到 column1 值是 abc% 的資料
當然 若沒有符合 abc% 這個條件的 就查不到任何資料 (多一個 a 少一個 % 都不行)

由以上坎尼推論式得知 % 只在 like 出現時是關鍵字
因為它自己出來是沒作用的 Sql 只認它和它的搭檔 like

就像平常 馬利歐(like) 出現 旁邊一定會有 香菇(%) 和 火焰花 (_) 一樣
若是香菇自己出現 沒有人會認為把它拿來吃會長得跟大樹一樣高

這個例子舉的很爛 不過大致上就是這種感覺
一個很普通的人若是旁邊出現了明星朋友 (比如說 王X宏)
就算是再普通 大家也會知道他是 王力X 的朋友
但是過了幾天 他旁邊沒了 X力宏 還有人會認得他嗎?

再度舉了個很爛的例子 大概是坎尼想睡一直胡言亂語

因為前幾天 Tim 一直在炫耀說他本月文章贏一篇
所以只好上來發了篇沒什麼感想的心得文

Windows SharePoint Service 3.0 簡介

由於最近負責管理的Server因不明原因掛點了，因此很榮幸的從8/12下午 MIS 把機器灌好以後，就開始試圖restore最重要的一項服務：用Windows SharePoint Service 3.0架設的portal。

最後一直到了今天早上，總算修復了絕大多數的功能，從完全搞不懂SharePoint到底在幹嘛，
到歷經約15~20次的重灌、調整設定、刪除、再重灌的洗禮後，總算掌握到一些要領，雖然還沒有很深入了解所有的細節，不過也足以作為如何backup/restore，還有設定網站的參考了！

由於內容太多了，因此文章預計分成三到四篇，先從簡介開始。

由於產品名稱中都有「SharePoint」，因此以下先從Windows SharePoint Service(WSS)與Microsoft Office SharePoint Server (MOSS) 的差異開始看起。以下是簡單的對照表：

	WSS	MOSS	Note
最新版本	3.0 SP1	2007 SP1
如何取得	Built In Win 2003	Part of Office System 2007
授權費	FREE	Office 2007 Professional以上
底層平台	.NET Framework 2.0	.NET Framework 2.0
Workflow Engine	Workflow Foundation	Workflow Foundation	Require .NET Framework 3.0
功能	基本	進階	MOSS is build on WSS technology
AD 整合	YES	YES
LDAP整合	NO	YES

詳細的差異請看參考資料2。MOSS 到底在Office什麼版本以上才有提供，
因為MS的網站實在寫的不清不楚的，花了十分鐘沒找到一個確切的結果就不想找了...
深入一點說，WSS是MOSS的基礎，是Windows Server的一部分，
本身不另外收費，所以沒事在家也可以架來用。
 
雖然說是免費的，但是已經可以做到蠻豐富的應用：

1. Team Site
   「小組網站」，是Site Template中最常用的，基本上當portal用，
   也可用來作Project Management
   （整合MS Project Server、Outlook、Word、Excel、PowerPoint等工具）。
2. Content Management System (CMS)
3. Blog --> 可以用word寫好上傳
4. Wiki
5. RSS Feed

從技術面來講，WSS應用到以下幾項技術：

1. ASP.NET 2.0 --> Basic functionalities & WebPart
2. MS Office Integration
3. MS Active Directory Integration
4. .NET Framework 3.0 --> Workflow Foundation

所以WebPart起碼MS自己的產品內部是應用的蠻兇的，
利用SharePoint Designer 2007 來調整WebPart也還算蠻好用的。
不過WSS有以下關於DB的問題：

1. 內建使用Windows Internal Database，有實體DB Size的限制，
   要審慎評估DB的使用狀況，必要的時候需要對DB進行升級，
   但升級基本上應該是跟還原一樣困難。
2. 不支援 SQL Server 的 binary sort order，
   這是公司資深的 ASE 前輩特別點出來的，沒時間仔細查，
   砍尼，交給你了，一定要回喔 XDD

而在WSS的基礎上近一步擴充的MOSS，則提供了以下的進階應用：

1. Bisuness Intelligence --> KPI、Dashboard
2. Enterprise Portal --> 應該是 scalibility 比 WSS 更強
3. Enterprise Search
4. Enterprise Content Management
5. Business Process & Forms
   (基本上 WSS 也都做的到，但通常在MOSS的介紹中更強調這塊)
6. LDAP Integration
7. Microsoft Office Service

在技術上，把Office元件經過再包裝做出來的一套service是比較新推的東西，
看來是MS Software Plus Service 策略的一部分（e.g. SQL Server Service），
如果哪天進了真正的MS Partner公司再慢慢研究好了。

MOSS主要著重在Enterprise這一塊，因此scalibility還有security的考量會比WSS更周延，
另外在BI的部份，也和SQL Server有很好的整合，如果整套都用MS的產品的話，應該是可以很快建置初一個企業的portal來。

以上是簡介的部分，接下來由於我負責管理的是 WSS，因此第二篇預計說明如何進行備份/還原，最後一篇記錄IIS的網站設定，還有總結心得感想～

參考資料：

1. Difference between WSS3.0 and MOSS 2007
2. Official difference comparison table download

如何 SqlParameter 裡用 like 關鍵字

今天趁假日要趕快來消化一下RSS訂閱的文章
愈訂愈多 然後積的文章量也就愈來愈大 orz

---

剛剛在 Jeff 大的 blog 中看到這篇

所以坎尼想到了平常處理 like 指令時 用Parameter的方式
第一次做的時候 對 SqlParameter 能不能用在 like 也有些疑問
經過反覆試驗後 下面就是現在坎尼常用的方法

第一個要點是 SQL 指令
一般來講會這麼下指令 select * from test where id like 'm%'
那變成參數式的寫法要怎麼寫呢?
坎尼只是很簡單的用了 select * from test where id like @id

「百分比符號哩?」『挖藏起來啊~』「金GY捏~~拿出來看看好不好?」

先來看部份程式碼抓圖 (其他不重要的就不抓了

坎尼只是把百分比符號在 addValue 時給加上
當然 各位也可以加上 前後 % 或是 ____ (以下是執行畫面

輸入 t 當然就是只有 t 開頭的客戶會出現

都不輸入就只會跑 % 所以是列出所有的客戶名單


這個做法坎尼用了數十次 目前還未發生副作用
如果有人發現副作用 請來信告知 :p

如何在Windows Server 2008上設定MSDTC

隨著Windows Server 2008的正式上市，最近也利用一些時間來測試公司底層的.NET 1.1元件（還有最近升級到.NET 2.0的元件），由於在微軟的平台上，舊的元件不可避免的大量依賴MSDTC（微軟的分散式交易服務，參考MSDN文件，在黑暗執行緒也有很多troubleshooting資料），又因為MSDTC可能出錯的狀況幾乎是有上千種（連某些特殊語系的OS都可能會有詭異的bug），因此隨著新版Windows Server OS的推出，也必須要更新舊有的MSDTC Troubleshooting Manual。

在最近的測試中，大致上都相當順利(不管是X86 or X64版)，Win2008除了底層架構更為模組化，效能表現更加突出之外(這在UI上感受不到)，最明顯感受到的差異就是管理介面的改變，不過對於用習慣Vista Business的人來說，應該會比較容易上手(若是Vista Home Premium以下，則還是有相當的差異，就像WinXP vs. Win2003的差異一樣)。

廢話不多說，以下是最general的設定步驟（這些步驟會將安全性原則設定到最寬鬆的狀態，實際上還是應該經過測試，開放最小限度的安全設定即可）：

1. 確認 AP Server 以及 DB Server 上的 Distributed Transaction Coordinator 服務都有開。
   
   除了透過「系統管理工具」-->「服務」的  GUI 來啟動 DTC 服務之外，也可以在 command prompt 中用「net stop msdtc」和「net start msdtc」來啟動/停止 DTC 服務。
   
2. 確認 AP Server 與 DB Server 間能互相以 NetBIOS / DNS 的方式來解析電腦名稱。
   
   這裡的重點是一定要兩台 Server 間彼此互相都能解析，在 Win2008 上，預設會把 ping 所使用的 ICMP Protocol 關閉，可以在 command prompt 中執行「netsh firewall set icmpsetting 8」指令，或者從Firewall的Inbound Rules中，將「File and Printer Sharing (Echo Request – ICMPv4-In)」設定為Enabled。(參考資料)
   
3. 調整關於 RPC 的安全性設定 
   
   DTC 必須使用RPC，因此需要設定相關的安全性設定。直接修改 Registry 的方式請參考這裡。
   
4. 其他安全性設定（含允許網路 DTC）
   
   (1)在Control Panel中，進入Component Services
   
   
   (2)依序展開Computers > My Computer > Distributed Transaction Coordinator > Local DTC，檢視 Properties。參考下圖的設定。
   
   
   (3)上途中在「Allow Inbound」和「Allow Outbound」下面的三個驗證選項，由於通常AP Server和DB Server會位於相同的Security Zone中，因此最寬鬆的設定是完全不要驗證，以免產生不必要的麻煩，相關安全性的問題應該在request進入AP Server前就處理好，或者在AP Server就把惡意的程式碼給擋下來，不要牽涉到DB Server。
   
   根據實際經驗，如果 AP Server 和 DB Server 都位於相同的 AD Domain，那麼其實設定開啟驗證也不會有什麼問題。
   
   最後一個「Enable XA Transactions」的選項就目前的情況也都可以不要允許，XA應該是另一套做 two-phase commit 的機制，不太熟 .... O.o
   
   
5. Basic Windows Firewall Exception Program settings
   
   (1)到Control Panel > Windows Firewall，點選左方的「Allow a program through Windows Firewall」連結，以設定 Exception Program:
   
   
   (2)設定允許DTC和File and Printer Sharing（參考資料）:
   
   
   
6. Advanced Windows Firewall Policy Settings
   
   (1)在Control Panel > Administrative Tools 中，找到 Windows Firewall with Advanced Security:
   
   
   (2)展開「Inbound Rules」後，在中間的Rules詳細內容區塊中可以找到「Distributed Transaction Coordinator (RPC)」、「Distributed Transaction Coordinator (RPC-EPMAP)」、「Distributed Transaction Coordinator (TCP-In)」等規則，預設都是disabled的（灰色），把他們通通 Enable。
   
   
   
7. 設定完畢之後，一定要利用DTC Tester來測試（更早以前還有一個DTC Ping工具，但是可能會產生false positive的結果，工具說通了，但實際就是不work），這個工具是利用ODBC來連線，在target DB Server上啟動一個分散式交易，建立一個temp table（只有一個欄位），然後塞入一筆亂數的資料，若是MSDTC有通的話，最後會要求你按一個鍵來commit transaction，如果看到志個訊息就表示「基本上」MSDTC的設定已經成功了！ (參考：如何使用 DTC Tester)
   
   曾經公司有些SE到客戶端裝完機器，按照手冊設定好MSDTC之後，居然拿最基本的ping DNS和telnet來測試連線，然後反應說系統掛了，結果看exception的訊息很明顯就是MSDTC不通。總之重點就是，沒有用DTC tester這個工具來測試的話，一切都是假的，聽說還會有DTC Tester測試通過，但MSDTC還是無法正常運作的案例呢！（幸好我沒遇過）
   
   好消息是微軟因為知道MSDTC這東西太難搞了，所以釋出一些測試工具，壞消息是這些工具在大部分的情況下只會吐出非常general的錯誤訊息（e.g. Invalid Cursor State），還有四個預設的安全性檢查建議，因此除非剛好看到非常明顯的錯誤訊息（例如MSDTC服務根本沒開），否則還是只能無奈的看著「Invalid Cursor State」，然後靠著Google瞎子摸象找解法了。

以上的圖主要是針對Win2008抓的，若SQL Server是架在Win2003上，基本上步驟都一樣（只是可以不要管Windows Firewall with Advanced Security的部份），主要是畫面長的不太一樣，主要還是參考微軟的這份文件(2007.12.5)。

MSDTC這東西真的是很麻煩，常常發現出錯的時候，都會Google到新的scenario（OS Setting + MS Product + .NET Version + Firewall Setting + Registry Setting），可能出錯的狀況真的是有千百種，即使到了最新的LINQ or ADO.NET Entity Framework似乎也還是無法擺脫它（NHibernate / Spring 是怎麼弄的我就不清楚了）。

事實上，根據公司資深ASE的前輩的觀察，其實相當少的系統需要做到realtime的two-phase commit，大部分的系統做到near realtime就可以了，或者以Enterprise Application來講，配合DB Server的設定，可以做到高階主管(或者頂級尊爵客戶)看到的系統畫面是真的realtime，其他一般小職員或者普通user看到的系統畫面則是near realtime，delay個1分鐘其實都還不會怎樣的。（不過 ... 效能還是應該無所不用其極的盡量調校才對，效能好也是可以節能減碳的）在near realtime的情況下，可以用暫存table來自己處理two-phase commit，更可以精準的控制retry的機制，把critical的交易通通交給像MSDTC這樣的black box來處理，未必是最明智的作法。

Anyway，短期內還是必須要跟MSDTC這東西相處好一陣子，有空再把之前處理過的更詭異情況寫一下囉~~

程式碼片段 Code Snippet

今天要談的是程式碼片段 (CodeSnippet)
之前坎尼在 好用的快速鍵 這篇就有提到
快速建立 #region 片段的方法

其實這就是利用內建的 code snippet
可惜 c# 內建的 snippet 實在少的可憐
想自行擴充的人 請上 MSDN 查 程式碼片段

C# 裡基本的倒是都有支援到
利用這些 code snippet 可以增加程式的開發速度
也比較不會因為手誤 而跑出一堆小蟲

下面列舉了幾個常用 keyword 的程式碼片段
另外再補充一點 程式碼片段的使用方式
是在有定義 snippet 的關鍵字後 按下 tab 鍵

先來看 if 的程式碼片段
首先 打上 if (這是廢話嗎?

接著按下 tab 就自然會跳出括號 (沒出現 tab記得多按幾下
並且會 focus 在判斷條件上

當然 else if 也是同樣用法

else 的話就只會跳出大括號


再來是介紹 try...catch...
當然是打 try 之後 按下 tab 鍵
不過會自動跳出 Exception 關鍵字這點令坎尼很滿意 XD


for 迴圈還會自己設定 i 為判斷因子 XD
當然也可以自己改成其他變數


程式碼片段真的很容易用又好用
當然有心擴充的人要自己上網找範例 (這部分坎尼還沒研究過

如何利用Windows Server 2003內建的工具來修改序號

由於上禮拜要在一台Win 2003 (SP0) VM上安裝VS2005，
因此要先升級到SP1(以上)，在執行SP2安裝程式時忽然發現，
前人用來安裝的序號是非法的！(冏 ... ) 因此開始辛苦的找尋公司的正版序號，
好不容易找到了之後，在修改序號的時候又頻頻卡住。

一開始找到了一篇修改Registry並且重新Activate Windows的教學，結果證明完全無效。後來又找到一個叫做Windows KeyFinder的工具，據說很好用，但是從1.73RC2、1.72 Final、1.66到1.62版我都試過了，每次執行就直接跳一個「Unexpected Error」，難道我真的不能做個好人，乖乖的用正版序號嗎？所幸最後請教公司的MIS之後，才發現直接利用Win2003光碟片內建給OEM廠商用的Support Tool - Sysprep.exe (意指 System Prepare）就可以搞定了！

這個Tool主要是給OEM廠商用的，可以對Windows OS做factory或者reseal（重新封裝，應該是為了綁入3rd party的軟體），也可以預先設定好序號，這樣安裝的時候使用者就不用很麻煩的打序號（看來SuperXP之類工具的快速安裝可能就是這樣做的？）。詳細使用步驟如下：

1. 把VM或實體系統做好備份，以免系統從此一去不復返。
2. 將實體Win2003光碟放到光碟機（廢話），或者用Daemon之類的虛擬光碟工具掛上映像檔。
3. 在檔案總管裡，展開「SUPPORT」這個資料夾，如下圖：
   
   
   
4. 在裡面會看到一個「DEPLOY.CAB」壓縮檔，這裡可以看到「Sysprep.exe」這個工具，所以就先把它解壓縮吧。
   
   
   
5. 執行Sysprep.exe，基本上可以不要用command line，它的GUI介面還算蠻單純的，在「改序號」這種需求來講，也不需要使用到什麼了不起的參數。
6. 勇敢的選擇「reseal」，這會抹消原有的序號，還有地區語言選項、administrator密碼等等設定。執行完畢後，會警告你說要重新開機才會生效。
   
   
   
7. 重開機之後，根據畫面的引導，先設定最重要的序號，之後陸續設定一些地區語言選項之類的東西。
8. 登入系統（若是administrator請用舊密碼），執行Win2003 SP2安裝程式，薑薑薑薑！順利安裝完成，OS漂白成功！

以上就是改邪歸正的完整步驟，根據我測試的結果，執行reseal之後其實administrator的密碼並沒有改變，原先的系統環境也不受影響，該有的開發環境和相關設定都還保存的好好的，因此以後就可以放心的使用這個Sysprep工具了！

最新版的Sysprep工具可以在微軟技術支援服務找到(SP1 / SP2)，稍微 Google 一下也可以發現，這個工具應該起碼從XP時代就有提供了，用標準的官方工具感覺還是比較保險，天曉得現在外面的破解軟體裡面會藏了什麼樣的木馬或者病毒，要是運氣好一點碰上 rootkit 木馬，那就刺激了...