-
Web Site Application + Sandcastle
這次要解決的問題, 跟上次想要在 Web Application 裡執行單元測試的問題類似, C# 有跟 Java 類似的 comment help, 可以把寫在註解的文字萃取出來, 製作成一份文件...
不過, 過去的 NDoc, 到現在新掘起的 SandCastle, 都要求兩個東西:
- Assembly Files: 可以透過 reflection api, 取得 asm 的 metadata
- Compiler 在 compile code 時匯出的 xml document
通常 help 製作工具都需要這兩種檔案才能制作 help, 不過 asp.net 2.0 引進的 web app, 正常情況下跟本拿不到這些東西, 因為 code 只要丟在 App_Code 就可以跑了, 跟本不需要 compile 成 dll, 更不用說 xml document 了.... 想到幾種可能可行的辦法, 今天就抽空試了一下:
在 web.config 裡加上 compiler option 輸出 xml
要產生 dll 倒不難, 有一堆方法, 可以用 aspnet_compiler.exe 這個工具, 直接 build web site, 可以輸出 DLL. 不過還缺 xml doc, 翻了翻 MSDN, 找到一條路, 就是在 web.config 裡可以加 compiler options.. 加上去之後, 就會產生 xml document...
<configuration>
<system.codedom>
<compilers>
<compiler ...... compilerOptions="/doc:c:\sample.xml" />
...簡單寫個 web app 試了一下可以 work, 但是放到 production site 就不行了, compile 的過程中, 你會看到這個 xml 檔案不斷的產生出來, 又被砍掉... 原來 App_Code 目錄下, aspnet engine compile 的方式是以目錄為單位, 每個目錄下的 *.cs 會被當成一個 project compile 一次, 換個目錄再來一次, 所以你指定的 xml document 檔會不斷的被覆蓋...
氣的是這個參數還一定得指定檔名, 不能指定 *.xml 或是不指定之類的... 所以除非你的 App_Code 目錄下只有一層, 不然就放棄吧..
Web Deployment Project
Visual Studio 2005 有個附加的 Web Deployment Project, 在 SP1 之後就直接內建了, 它大概的作法就是 aspnet_compiler.exe 先輸出一堆 assembly, 然後再用 asm merge tools 把它併成單一個 assembly dll file. 是可以很簡單的拿到 dll 了, 不過產生 xml document 的部份仍然一樣無解
寫 msbuild project file
在 google 查這個問題時, 看到有老美用的作法是自己寫一段 task, 把所有 *.cs 加到 csc task 裡... 不過太麻煩了, 一來我整個 build 程序沒有用到 msbuild project file, 二來我也不熟, 寫起來有點辛苦..
手動下 CSC.exe 指令
來硬的, 我自己想辦法生個 dll + xml 總可以了吧, 反正我的目的只是要 help, dll 用完就丟也沒關係, 只要我不要寫兩份 code 就好. 查了一下指令, 可以這樣用:
csc.exe /out:App_Code.dll /doc:App_Code.xml /target:library /recurse:App_Code\*.cs
哇哈哈, 這次就成功了, dll 跟 xml 都成功的產生出來, 之後就丟給 NDoc / Sandcastle 就解決了. 額外抱怨一下, 雖然 SandCastle 能夠處理 .net 2.0 額外的功能, 像 generic 等等, 不過速度真是爆慢... Orz, 以前用 NDoc 約 20 min 能夠 build 好 chm, 現在用 sandcastle 要跑 60 min ...
雖然如此, 不過這個方法還是有幾個缺點.. 列一下我已經確定的:
- App_Code 下可以包含 source code 以外的檔案.
除了 .cs 這種 source code 會被自動編譯之外, 還有其它型態的檔案也會自動被處理. 比如 wsdl 放著就會自動 gen web service proxy, xsd 放著就會自動 gen typed dataset 的 source code... 這些是單用 csc.exe 沒辦法解決的 - 另外像 .ascx .aspx 對應的 cs, 也無法用 csc.exe 處理, 因為還有另一半的 partial class 是由 template file 會透過 asp.net engine 動態 parsing 後產生 .cs 再一起 compile, 這部份也沒有辦法單靠 csc.exe 處理掉
- 理論上還是有辦法把這些動作加在 batch file 或是 msbuild task 裡, 不過這些通通做下來, 那等於你自己搞一個 aspnet_compiler.exe 了... 工程太大, 不划算...
最後我選擇放棄這些遺漏的部份. 因為 help file 主要就是為了能共用的 class library 能有對應的文件, 上面漏掉的三塊都不大會有 comment help 產出, 唯獨 .ascx 還是很需要 help, 不過在沒有更方便的工具之前就先不管它了... 哈哈
-
好樣的多普達...
在我買了手機滿五周, 跟客服來回了十封 mail, 也打了幾通電話, 官方網站總算擺上了 c720w 回複出廠預設值後要安裝的軟體了 -_-
果然軟體還是要調過跑的才會順, 之前的 RSS reader, 畫面轉 90' 就是有點小問題 (因為是抓 595 的來裝的..), 語音命令的 hotkey / icon 也變正常了, 字典也回來了, 兩個附的 game 也回來了...
除了 RSS reader 速度變快了之外, 好像也沒啥大不同... 哈哈...
另外, 手機就是當手機用就好, 上周拿手機跑 PaPaGo 試了一圈, hmm... 導航沒多久, 我裝的 screen saver 就給我啟動了, 沒觸控邊開車也不大好按, 想想還是把我古董的 PDA 拿來當 GPS 專用機好了..
-
人生ｵﾜﾀ＼(^o^)／の大冒険
http://blog53.fc2.com/k/king75/file/owata.html
沒耐性 or 脾氣不好的人千萬別玩... 哈哈, 好機車的 game, 玩到想罵 TMD...
每當你以為很勵害破關了, 其實是掉到另一個陷阱.. [:@], 果然, 這就是人蔘啊...
-
Generic Type 的繼承...
之前貼過一篇 Singleton 的文章 (泛型 + Singleton Patterns, 泛型 + Singleton Patterns (II)), 就用到 base class 是 generic type 的作法, base class 可以是 generic type, 在繼承時直接給型別, 衍生出來的子類別就不再是 generic type 了.. 不過這種怪異的用法, 大概沒什麼書上的範例有講到, 也沒什麼書上有應用範例... 這完全是我自己亂配出來的藥方, 沒練過的人不要亂吃, 咳咳..
除了 Singleton 那種例子之外, 我另外碰到一個例子... 某個用 asp.net 開發的 project, 需要準備一套輸入各種型別資料的 control, 如基本的型別: string, int, bool, DateTime, TimeSpan... 及較複雜的自定型別, 如 MemberInfo, RoleInfo, ..... 等.
基本型別的部份, 大概大家都是搭配 asp:textbox, asp:checkbox, asp:calendar 這幾個控制項加一些 code 就搞定了, 反正用起來夠簡單, 也不用再呼它夠不夠精簡, 可不可以 reuse 了, 後面的自訂型別應該也不會太多, 可能土法練鋼, 每種各硬寫出個 user control 就解決了...
不過我怎麼能容忍這種 code 擺在我眼前? 哈哈... 看了就很不順眼... 以一般的 OO 觀點來看, 這些控制項應該有些共通的地方 (generalization) 能抽出來, 往上堆到 base class .. 不過卡在每種 user control 要輸入的型別跟本完全不一樣, 不是通通用 object 代替, 就是要寫的很醜...
看到那段紅字, 大家大概就會聯想到泛型 (generic) 了, 沒錯... 不過套用到 control 的世界該怎麼用?
貼一段不能 run 的 sample ... base class 的部份:
public class Editor<T> : System.Web.UI.UserControl {
public abstract T Value { get; set; }
// 其它就不干我的事了
}之後假設我要寫個選日期的控制項, 只要這樣寫:
.ascx
<asp:calendar runat="server" id="calendar1" />
.ascx.cs
public class DateEditor : Editor<DateTime> {
public override DateTime Value {
get { return this.calendar1.SelectedDate; }
set { this.calendar1.SelectedDate = value; }
}
}最後用起來就沒什麼特別的了, 大概像這樣:
<chicken:DateEditor runat="server" value="2000/01/01" />
看到最後, 讓大家失望了 (H), 沒什麼特別的 code 嘛, 其實不然, 這個作法可以替你的 project 打下一個很好的基礎, 透過 generic 的 base class, 解決掉型別的問題後, 你就可以把各種型別的 editor 都綁在一起, 讓它們有共通的 base class, 這樣的好處很快就出現了, 有許多功能你就有機會只作一次, 每種不同的 editor 都能享用...:
- 例: Editor 可以實作 "記住上次輸入的值" 這動作, 只要把 value set 的 code 插一段, 記到 file / db 之類的地方..., 所有 editor 自動都有這個能力了
- 可以統一加上 OnChange Event, 所有的 editor 都可以有這事件讓寫 page 的人能應用
- 因為所有的 editor 都有共同的 base class, 因此搭配 reflection 及 attribute, 你就能把 polymorphism 的技巧應用出來. 舉例來說, 你可以拿任意物件, 產生它專用的編輯畫面. 你可以透過 reflection api, 把所有的 field / property 名字及型別列出來, 同時在畫面上動態產生一個對應型別的 editor control ... 最後底下放個 [save] 的 button, 按下 ok 後自動的把每個 editor 收集到的值寫回 object ... 這一連串的動作如果沒有共同的 base class, 你是沒有辦法做的出來的
- 其它 543 的功能, 你有辦法都可以加在 class Editor<T> 裡, 馬上所有的 Editor 都能夠繼承這些能力
- 想不出來了, 剩下的原因只有這樣寫起來比較爽...
實際的 sample code 還真的不大好寫, 我碰到的 project 裡寫的東西又牽扯太多, 那天有空想要把它精簡一點的話再放 sample code, 不然就再說... 哈哈..
-
Windows Live Writer - Plugin 處女作...
Windows Live Writer (以下簡稱 WLW) 用過的都說好, 老實說它做的真是不錯, 連家裡太座用了之後就再也不到網頁上寫 blog 了...
不過有個缺點實在是很礙眼, 就是透過它上傳的圖檔, 不管 options 怎麼調, 透過 MetaBlogAPI 或是 FTP, 都會被重新存一次 JPEG 檔. 一來 JPEG 是破壞性壓縮, 越存會越糟糕, 二來它用的 quality 還不低, 我自己的圖檔丟上去大概都會肥一倍... 畫質變差, 檔案又有可能變肥, 真是人財兩失.. 到底差多少? 各位自己比較一下就知道了, 在圖檔上按右鍵選內容可以看的到 file size.. 底下左邊的圖是原檔, 右邊是 WLW 幫你加工過的, 不過我原圖是 JPEG 100% quality, 所以 WLW 雞婆完反而變小一點...
%5B4%5D.jpg)
試了半天沒得解, 每次都用 "Insert Picture From Web" 也不是辦法, 就把腦筋動到 Plugin 上了... 跟小熊子聊完後就開始手癢了, 去下載 WLW SDK 回來看... 可以用 .NET 寫, 就邊 K 邊寫起來... 做法跟 Insert Picture From Web 差不多, 只是先設定好 UNC 路逕跟網址的對應, 讓你挑完檔案先幫你 copy 好再塞入網址.. 懶人用.
首先是 option settings, dll 丟到 Plugins 目錄後, 打開 WLW 的 Tools -> Preferences, Plugins 就會看到新加進去的外掛了..
我有準備編輯設定的畫面... 因此有 [options] 的按鈕可以用..
這個畫面就很簡單的只填 UNC (網路分享的路逕), 跟對應的 URL ... 設定完成後, 只要要插入圖檔時, 從選單選 Insert -> 插入圖片(從網路芳鄰), 就會跳出標準的 Open File DialogBox, 挑完就一切大功告成了 :D
本來是想從 MetaBlog API 下手, 因為這個管道也可以 upload image, 不過試了半天宣告放棄, 大概是 Microsoft 怕有人寫 Plugins 來偷密碼吧? 也可能是 Plugins 都被定位在 "edit blog" 的部份, 而不是 "publish" 的部份, 因此完全拿不到 WLW 的 Weblog Account 相關資訊... 這條路宣告放棄, 就算要作, 也得分開 config, 沒辦法...
現在這個版本其實只是自己做爽的而以, 所以就不用跟我要 .dll 了, 不成氣候的作品... 因為不知 Microsoft 下一版會不會改掉這鳥問題? 有的話這外掛就變廢物了, 二來現在太陽春, 連個防呆都沒有... 哈哈... 只是花兩個小時邊 K 邊寫的本來就只能玩玩... 不過做過這個 plugin 後, 寫法跟能運用的範圍大概都有個底了, 下次來改寫的話, 我打算 option 那邊就改成 MetaBlogAPI 需要的設定, 如 Blog URL, account, password 等資訊, 不然放個網芳真的是沒啥用...
