朝陽專案・交件明細
版本 1.0.5.1
連線使用中的電腦強制套用 VNC 參數更新
連線使用中的電腦也能套用 VNC 參數更新：開關預設「否」＝等這次連線結束才套用，不打斷使用中的連線；開關「是」＝照 1.0.5.0 提示後重啟並自動重連（自測第 149 項）。
真 UltraVNC 兩台實測：開關否，連線中改 5917，對方不斷線，中斷後 12.9 秒套用；開關是，連線中改 5927，18.2 秒自動重連、同一筆紀錄。
- 自測
- Mac 1675／1675；Windows 1868／1868（新功能第 149 項 57／57）
- 獨立驗收
- 通過（Windows 兩台真機獨立編譯、獨立驗收）
- 改壞紅幾格
- 17 格（三方各改壞一處：另兩處紅 1 格、3 格）
- 正反案例
- 代表案例 27／27 過（開關是／否兩邊、等待中又來一版、不合法都在內）
要 James 定的題目
無
測試明細過 27不過 0
| 情況 | 預期 | 案例 | 結果 |
|---|---|---|---|
| 狀態＝畫面已接通（正在被連） × 開關否 | 不重啟、不提示，記下「等這次連線結束後套用第 N 版」，回報後台 | 格 21（判斷＋套用器＋整合） | 過 |
| 狀態＝畫面已接通 × 開關是 | 照 1.0.5.0：兩端提示 → 被連端重啟 → 發起端用新 port 自動重連 | 格 22；真機 18.2 秒重連 | 過 |
| 狀態＝沒人連（VNC 沒跑／在跑／查不到） × 開關是否都一樣 | 沒跑改 ini、在跑靜靜重啟、查不到當沒跑 | 格 17／18／19 | 過 |
| 狀態＝協商中（還沒接通） × 開關是否都一樣 | 先等，接通後再看開關 | 格 23／24；協商沒接通＋否走 a（格 25） | 過 |
| 跟已套用的一樣／沒裝 UltraVNC | 不動／只存檔，都不進等待（與開關無關） | 格 26／27 | 過 |
| 又來一版（更新的版本） | 只等最新那一版，log「只套用第 N 版」，仍不重啟 | 格 28（套用器＋整合） | 過 |
| 後台重送同一版 | 繼續等，不重複記 log、不重複回報 | 格 34；格 29 | 過 |
| 開關改成「是」 | 馬上照 1.0.5.0 走提示＋重啟＋等重連，清掉等待 | 格 30（套用器＋整合）；真機開關是重啟在聽 5918／5927 | 過 |
| 連線結束（任何方式：被連端結束、發起端中斷、斷線、CB 收尾） | 立刻套用最新那版（沒人連就改 ini／在跑就靜靜重啟），清掉等待 | 格 35／36／37；真機 A 中斷後 12.9 秒套用 5917 | 過 |
| CB 被結束後重開（等待只在記憶體） | 不留等待；啟動比對一次，照沒人連那組規則補套 | 格 39 | 過 |
| 後台在等待中重開 | 連線不斷、CB 繼續等；新後台重記「等第 N 版」、電腦清單有等待 | 格 40（整合） | 過 |
| 重啟中把開關改成否、又來第 4 版 | 這次重啟照樣用「決定當下那一版」做完（在聽 5920）；第 4 版改成等連線結束，不再重啟 | 格 31（修法：連線中重啟用快照不讀最新） | 過 |
| 網頁「系統參數」頁勾選（VNC 三項同一張表單） | 預設不勾 | 格 1 網頁 | 過 |
| 管理者／Admin 改開關 | 存、版本號不變、下發一次、修改紀錄一筆（類型 VNC 參數、方式 網頁、否→是）、log 一行 | 格 3／4 | 過 |
| 使用者 POST 想改 | 403，開關不動、不下發、不記 | 格 5 | 過 |
| 只改開關 | 參數頁「修改歷史」不多列（版本沒變），但「修改紀錄」頁看得到那一筆 | 格 14 | 過 |
| 同時改 port 和開關 | 版本＋1、修改紀錄兩筆、下發帶新 port＋開關值 | 格 7 | 過 |
| 內容一樣再存 | 不記（開關不會被當成改過） | 格 8 | 過 |
| DLL SetVncApplyDuringSession：成功／跟目前一樣「沒有修改」不記／金鑰錯或沒填修改者就失敗且不 | DLL SetVncApplyDuringSession：成功／跟目前一樣「沒有修改」不記／金鑰錯或沒填修改者就失敗且不動 | 格 9／10／11／12 | 過 |
| 後台記「X 正在連線中 | VNC 參數第 N 版等連線結束後套用」；等待中又換版記「改成等第 N+1 版」；套用記「已套用第 N 版」 | 格 21／28／30／35（整合 log） | 過 |
| Dashboard 電腦清單、參數頁套用狀態：在線又在等 | 後面加「VNC 參數等連線結束後套用（第 N 版）」；沒在等或離線不顯示 | 格 21／42 | 過 |
| CB 把等待版本經 StatusMessage.PendingSettingsVersion 回報後 | CB 把等待版本經 StatusMessage.PendingSettingsVersion 回報後台 | 格 48 序列化 | 過 |
| 序列化：SettingsMessage.ApplyDuringSession、StatusMessage.PendingSettingsVersion 來回不走樣；舊 JSON 沒這兩欄 | false／0 | 格 48 | 過 |
| 1.0.5.0 的 CB（只有 4 欄）讀新後台參數 | 多的開關欄位不影響其他三項 | 格 45 | 過 |
| 新 CB 讀 1.0.5.0 後台（沒有開關欄位） | 開關＝否，正在被連會等連線結束 | 格 47 | 過 |
| 勾選、說明、等待那句、修改紀錄字樣：繁中／簡中／英文／越南四語系都 | 勾選、說明、等待那句、修改紀錄字樣：繁中／簡中／英文／越南四語系都有 | 格 49 | 過 |
| 撞到監聽埠等不合法參數 | 不收、不改開關（還是否） | Receive 格 | 過 |
這是代表案例；自測第 149 項共 57 格，全表在交件包。
自我總結錯誤 → 原因 → 背後原因 → 對策
格 31 紅：連線中改參數要重啟時，重啟用「存檔最新值」寫 ini；停服務 6～8 秒期間後台又下發一版，重啟就套到新版的 port（實際 5921，應是決定時的 5920），而且新版沒被延後——跟設計「已在重啟中改成否 → 照樣做完、新版等連線結束」相反。（交 James 前的 Mac 自測抓到；前一個開發流程漏修）
連線中的重啟沿用閒置時的 RestartServerWithCurrentSettings（寫存檔最新），沒分「已承諾要套某一版的重啟」跟「閒置時合併多版一次套」。
同一個「寫最新」動作，在閒置時是對的（合併）、在已開始的重啟是錯的（要用決定當下那一版），當初沒把這兩種語境分開。
加 RestartServerWithSettings(desired)，連線中的重啟寫「決定當下的快照」；閒置路徑維持讀最新。以後凡「已承諾要對某一版做動作」的路徑，動作時用決定當下的快照，不在完成時再讀會被別人改的共享狀態。
1.0.5.1 的測試整組沒提交（未追蹤、item 149 註冊與 DLL 合約更新都沒 commit）；item 33「DLL 連本機沒人聽的埠 → 對方拒絕、2 秒內回」在 Windows 實際 2.01 秒，門檻太緊；VersionInfo 還停在 1.0.5.0。（接手時 git status、獨立驗收、交件前提醒各抓到）
測試沒 commit、分支基底比別支舊（少了門檻修正）、版本號沒改，都是「別人做一半、我沒逐項盤點」漏掉的。
交件前只檢查「自測綠不綠」，沒檢查「這包本身的狀態對不對」。
交件前固定盤點四項——① git status 乾淨（測試都 commit 了）② VersionInfo 跟這版相符 ③ 分支基底有沒有缺別支已修的同類修正 ④ 全套自測在 Mac 與 Windows 兩邊的數字都看過。這版就是靠這個盤點補齊。
（觀察，非這版的紅）用故意改壞的版本跑自測時，壞的套用器讓自測 process 在跑完一節後中途死、結果被截斷、沒印 exit——自測只數紅格，沒有「跑到 N／應跑 M」的對照。
runner 只數紅格；背景執行緒的未捕捉例外在 .NET 下會直接終結整個 process，後面的案例沒跑也沒報錯。
綠燈的定義是「沒有紅格」，不是「該跑的都跑到了」。
（列下一版，非 1.0.5.1）runner 印「跑到 N／應跑 M」，少跑即判不過；套用器 Loop 確保任何路徑的例外都不逸出執行緒。