換新系統了!! CS 2.0 Beta 3

以下內容基於原文所揭示的實務情境與明確限制（IIS 6.0 在 64 位 Windows 上無法同時執行 32/64 位模式、CS 1.0 依賴 ASP.NET 1.1、.NET 1.1 無 64 位 Runtime、作者因而升級至 CS 2.0 Beta 3 並暫時放棄客製功能），抽取並擴展為可操作的教學型案例。每案皆包含可復現的步驟與設定片段。若原文未提供量化數據，以下以可用性/可部署性等客觀可驗證的成效作為衡量。

Case #1: 64 位 Windows 上舊版 CS 1.0 無法啟動的緊急復原（強制 IIS 32 位模式）

Problem Statement（問題陳述）

業務場景：公司部落格採用 Community Server 1.0 長期運作。因主機升級至 Windows Server 2003 x64 與 IIS 6.0，既有站點依賴 ASP.NET 1.1，於 64 位模式下無法啟動，導致外部訪客無法瀏覽、內部文章維護停擺，影響對外公告與品牌形象。
技術挑戰：IIS 6.0 在 64 位 Windows 上不能同時執行 32/64 位模式；ASP.NET 1.1 僅能在 32 位模式運行。
影響範圍：整個 IIS 服務、所有站點與應用程式池；對外可用性與 SLA。
複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：
1. CS 1.0 僅支援 ASP.NET 1.1，於 ASP.NET 2.0 或 64 位模式無法運作。
2. IIS 6.0 在 64 位 Windows 上無法同時載入 32 與 64 位 CLR。
3. .NET Framework 1.1 無 64 位 Runtime，阻斷原生 64 位執行。
深層原因：
- 架構層面：站台架構緊耦合於單一框架版本（ASP.NET 1.1）。
- 技術層面：部署設計未能隔離位元架構差異（無分流或容器化）。
- 流程層面：OS 升級缺乏相容性影響盤點與預演。

Solution Design（解決方案設計）

解決策略：依 Microsoft KB 指引，將 IIS 切換為 32 位模式、重新註冊 ASP.NET 1.1，優先恢復舊站可用性；待服務穩定後再規劃升級與長期解法。

實施步驟

確認目前 IIS 位元模式
- 實作細節：查詢 Enable32BitAppOnWin64 旗標值
- 所需資源：cscript、adsutil.vbs
- 預估時間：5 分鐘
切換 IIS 至 32 位模式並註冊 ASP.NET 1.1
- 實作細節：設定 Enable32BitAppOnWin64=1，執行 1.1 版 aspnet_regiis
- 所需資源：.NET 1.1、IIS AdminScripts
- 預估時間：10-15 分鐘
回收應用程式池並驗證
- 實作細節：IISReset 或回收 AppPool、觀察事件檢視器
- 所需資源：IIS 管理工具
- 預估時間：10 分鐘

關鍵程式碼/設定

:: 1) 查詢目前位元模式（0=64位, 1=32位）
cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs GET W3SVC/AppPools/Enable32BitAppOnWin64

:: 2) 切換為 32 位
cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32BitAppOnWin64 1

:: 3) 註冊 ASP.NET 1.1（注意：只存在 32 位 Framework）
%SystemRoot%\Microsoft.NET\Framework\v1.1.4322\aspnet_regiis.exe -i

:: 4) 重啟 IIS
iisreset

Implementation Example（實作範例）：依序執行上述命令，並以瀏覽器測試 CS 1.0 首頁與後台登入。

實際案例：本文作者於 Windows Server 2003 x64 上，為啟動 CS 1.0 而切換 IIS 至 32 位模式。
實作環境：Windows Server 2003 x64、IIS 6.0、.NET 1.1、Community Server 1.0
實測數據：
- 改善前：站點在 64 位 IIS 下無法啟動（可用性 0%）
- 改善後：站點恢復上線（可用性 100%）
- 改善幅度：可用性 +100%

Learning Points（學習要點）

核心知識點：
- IIS 6.0 在 64 位 Windows 無法同時載入兩種位元模式
- .NET 1.1 僅 32 位；2.0 可 32 或 64 位
- 版本切換須同步執行 aspnet_regiis 與 AppPool 回收
技能要求：
- 必備技能：IIS 6 管理、命令列工具操作、事件檢視器
- 進階技能：版本相容性檢核、影響面盤點
延伸思考：
- 是否需要分流 1.1 與 2.0 到不同主機？
- 32 位模式對記憶體利用與效能的影響？
- 何時轉向長期升級方案（見 Case #3）？

Practice Exercise（練習題）

基礎練習：在測試機切換 IIS 位元模式並註冊 ASP.NET 1.1（30 分鐘）
進階練習：撰寫批次檔自動完成切換、註冊與驗證（2 小時）
專案練習：建立完整復原手冊與 Runbook，含回溯與通報流程（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：成功恢復 CS 1.0 上線
程式碼品質（30%）：批次腳本可重複、具防呆
效能優化（20%）：切換後無明顯效能退化
創新性（10%）：加入自動化驗證與報告

Case #2: 同機並存 ASP.NET 1.1 與 2.0 的 32 位全站運行方案

Problem Statement

業務場景：同一台 64 位伺服器需同時承載 CS 1.0（ASP.NET 1.1）與少量 ASP.NET 2.0 工具站。受限 IIS 6.0 無法同時執行兩種位元，需在不增購硬體前提下維持雙版本共存。
技術挑戰：在 32 位模式下同時正確註冊 ASP.NET 1.1 與 2.0（32 位）並確保站台對應 Framework。
影響範圍：所有站台版本綁定、部署流程與相依元件。
複雜度評級：中

Root Cause Analysis

直接原因：
1. IIS 6.0 不支援混合位元模式。
2. ASP.NET 2.0 可 32/64 位，但 1.1 僅 32 位。
3. 站台版本未顯式綁定，導致註冊錯亂。
深層原因：
- 架構層面：多站多框架共用主機缺少隔離。
- 技術層面：未建立版本對應與驗證規範。
- 流程層面：安裝順序與維運腳本未標準化。

Solution Design

解決策略：統一 IIS 為 32 位模式；先註冊 ASP.NET 2.0（32 位），再註冊 1.1；以 Web.config 明確鎖定 2.0 特性；建立部署規範與驗證清單。

實施步驟

切換 IIS 至 32 位模式
- 實作細節：同 Case #1 步驟
- 所需資源：adsutil.vbs
- 預估時間：5 分鐘
註冊 2.0（32 位）與 1.1
- 實作細節：先 2.0 32 位再 1.1，避免覆寫
- 所需資源：aspnet_regiis.exe
- 預估時間：10 分鐘
逐站檢查與驗證
- 實作細節：以簡單頁面輸出 FrameworkVersion
- 所需資源：手動或自動化腳本
- 預估時間：30-60 分鐘

關鍵程式碼/設定

:: 統一為 32 位
cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32BitAppOnWin64 1

:: 先註冊 ASP.NET 2.0（32 位）
%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i

:: 再註冊 ASP.NET 1.1（32 位）
%SystemRoot%\Microsoft.NET\Framework\v1.1.4322\aspnet_regiis.exe -i

Implementation Example：對每個站台部署一個 Version.aspx 檢查實際執行框架。

實際案例：文章場景引出的權衡方案（暫維持 32 位以兼容 1.1 與 2.0）
實作環境：Windows Server 2003 x64、IIS 6.0、.NET 1.1/2.0
實測數據：
- 改善前：無法共存（2.0 在 64 位、1.1 不可用）
- 改善後：兩者在 32 位模式下可用
- 改善幅度：可用站台比例 0% → 100%

Learning Points

核心知識點：註冊順序、位元模式與框架版本對應
技能要求：IIS 多站維運、框架偵測
延伸思考：是否應分離主機/虛擬化分流？

Practice Exercise

基礎：建立 Version.aspx 顯示 IntPtr.Size 與 Environment.Version（30 分鐘）
進階：腳本批量驗證所有站台版本（2 小時）
專案：制定多框架共存 SOP（8 小時）

Assessment Criteria

功能完整性：所有站台正常渲染
程式碼品質：檢查頁面簡潔可重用
效能優化：切換後無明顯延遲
創新性：自動化驗證報告

Case #3: 升級至 Community Server 2.0 Beta 3 以解除 32 位依賴

Problem Statement

業務場景：為發揮 64 位新主機效益與長期維運可持續性，決定將 CS 1.0 升級至 CS 2.0 Beta 3，並在 64 位模式下運行 ASP.NET 2.0，暫時放棄先前客製功能。
技術挑戰：切回 64 位模式、重註冊 2.0（64 位）、驗證新站相容性與穩定性。
影響範圍：全部站台部署流程與客製功能。
複雜度評級：中

Root Cause Analysis

直接原因：
1. .NET 1.1 無 64 位 Runtime，限制 64 位發揮。
2. CS 1.0 僅支援 .NET 1.1。
3. IIS 6.0 位元限制無法同時運行雙模式。
深層原因：
- 架構層面：歷史系統技術債與版本耦合。
- 技術層面：客製改動難以跨大版本移植。
- 流程層面：升級路徑與回退缺乏標準化。

Solution Design

解決策略：部署官方 CS 2.0 Beta 3，IIS 切回 64 位模式，註冊 ASP.NET 2.0（64 位），以正式特性替代部分客製功能，後續再分批重建擴充。

實施步驟

切換 IIS 回 64 位模式
- 實作細節：Enable32BitAppOnWin64=0，註冊 64 位 2.0
- 所需資源：adsutil.vbs、aspnet_regiis.exe（Framework64）
- 預估時間：15 分鐘
部署 CS 2.0 Beta 3
- 實作細節：依官方指引安裝、配置
- 所需資源：CS 2.0 Beta 3 套件
- 預估時間：1-2 小時
驗證與監控
- 實作細節：功能驗收、事件檢視器、IIS 日誌
- 所需資源：測試清單
- 預估時間：1-2 小時

關鍵程式碼/設定

:: 回到 64 位模式
cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32BitAppOnWin64 0

:: 註冊 ASP.NET 2.0（64 位）
%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -i

iisreset

Implementation Example：切換成功後，部署 CS 2.0 Beta 3，逐頁驗證前台與後台。

實際案例：作者最終改用官方 CS 2.0 Beta 3 版本運作於新系統。
實作環境：Windows Server 2003 x64、IIS 6.0、.NET 2.0（64 位）、CS 2.0 Beta 3
實測數據：
- 改善前：IIS 受限 32 位，無法發揮 64 位
- 改善後：IIS 64 位運行、CS 2.0 正常
- 改善幅度：64 位能力恢復（可用性 0%→100%）

Learning Points

核心知識點：IIS 位元切換、2.0 64 位註冊要點
技能要求：升級部署、風險控管
延伸思考：Beta 版本上線風險如何降低？

Practice Exercise

基礎：練習 32/64 位切換與 2.0 註冊（30 分鐘）
進階：撰寫驗收清單並執行（2 小時）
專案：完成 CS 大版本升級 Runbook（8 小時）

Assessment Criteria

功能完整性：新站完整可用
程式碼品質：設定與腳本清楚
效能優化：64 位下無異常
創新性：自動化驗證

Case #4: 64 位 OS 升級後舊站掛掉的零停機救援流程

Problem Statement

業務場景：OS 升級完成後，CS 1.0 無法啟動，需在最短時間恢復對外服務，同時保留日後升級彈性，避免長時間停機造成品牌損失。
技術挑戰：快速診斷位元衝突、切換模式、避免設定錯亂與資料遺失。
影響範圍：SLA、客服工單、搜尋引擎收錄。
複雜度評級：中

Root Cause Analysis

直接原因：位元模式不相容、框架版本錯配、註冊順序錯誤。
深層原因：
- 架構層面：無熱備與分流
- 技術層面：缺少健康檢查頁面
- 流程層面：無標準化應變手冊

Solution Design

解決策略：定義「緊急回復腳本 + 健康檢查頁 + 驗收清單」，在 15-30 分鐘內將 IIS 切至 32 位並恢復 CS 1.0，上線後再規劃升級。

實施步驟

一鍵回復批次
- 實作細節：打包切換、註冊、重啟指令
- 所需資源：批次檔
- 預估時間：5 分鐘
健康檢查頁部署
- 實作細節：輸出 IntPtr.Size 與版本
- 所需資源：ASPX 檢查頁
- 預估時間：10 分鐘
服務驗收與公告
- 實作細節：檢查日誌、對外公告
- 所需資源：SOP 文件
- 預估時間：15 分鐘

關鍵程式碼/設定

@echo off
REM Emergency rollback to 32-bit for CS 1.0
cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32BitAppOnWin64 1
%SystemRoot%\Microsoft.NET\Framework\v1.1.4322\aspnet_regiis.exe -i
iisreset
echo Done. Verify health page now.

Implementation Example：執行批次後以 /health.aspx 驗證。

實作環境：同 Case #1
實測數據：停機時間由不可預期 → 30 分鐘內恢復（可用性顯著提升）

Learning Points

核心知識點：救援自動化、健康檢查
技能要求：批次腳本、驗收設計
延伸思考：導入藍綠佈署是否可進一步縮短恢復時間？

Practice Exercise

基礎：建立 health.aspx（30 分鐘）
進階：撰寫完整救援批次（2 小時）
專案：演練並量測 RTO/RPO（8 小時）

Assessment Criteria

功能完整性：一鍵恢復
程式碼品質：容錯與日誌
效能優化：最小停機
創新性：自動化與通知

Case #5: 自改功能與官方升級的取捨與過渡（以擴充重構取代核心改檔）

Problem Statement

業務場景：作者先前對 CS 1.0 進行大量客製（如編輯器、Gallery、擴充），但為使用 64 位與官方改進，決定改用 CS 2.0 Beta 3，短期犧牲客製功能，長期規劃以擴充重構。
技術挑戰：避免核心改檔，改以可升級的擴充點重建。
影響範圍：功能體驗、維護成本、升級成本。
複雜度評級：中

Root Cause Analysis

直接原因：核心改檔導致升級成本高、相容性差。
深層原因：
- 架構層面：缺少外掛式設計
- 技術層面：對事件/Provider 模式掌握不足
- 流程層面：缺少升級前客製盤點

Solution Design

解決策略：以官方版本為基底，將客製功能重構為獨立擴充（HttpModule/控件/設定），建立功能清單與優先級，逐步回補。

實施步驟

客製盤點與分類
- 實作細節：列出功能、依賴、替代性
- 所需資源：文件化
- 預估時間：2-4 小時
擴充框架骨架搭建
- 實作細節：建立 HttpModule/控件專案
- 所需資源：Visual Studio
- 預估時間：2 小時
逐步回補與驗證
- 實作細節：一項一驗收
- 所需資源：測試計畫
- 預估時間：持續

關鍵程式碼/設定

// 範例：以 IHttpModule 擴充而非改核心
public class MyCsExtension : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.BeginRequest += (s, e) => { /* 擴充邏輯 */ };
    }
    public void Dispose() { }
}
// web.config 註冊
// <httpModules><add name="MyCsExtension" type="MyNs.MyCsExtension"/></httpModules>

實際案例：作者暫時放棄自改，改用官方版本，後續再補齊。
實作環境：CS 2.0 Beta 3、ASP.NET 2.0
實測數據：升級阻力降低（可升級性由低→高）

Learning Points

核心知識點：可升級擴充策略
技能要求：HttpModule/控件開發
延伸思考：若官方已提供等效功能，是否直接採用？

Practice Exercise

基礎：建立空白 HttpModule（30 分鐘）
進階：將一項小客製改為 Module（2 小時）
專案：完成 2-3 項客製的擴充化（8 小時）

Assessment Criteria

功能完整性：擴充達到舊功能
程式碼品質：模組化、解耦
效能優化：無額外開銷
創新性：可配置化設計

Case #6: 舊版 Editor 客製遺失的重建策略（以控件覆寫替代改檔）

Problem Statement

業務場景：原有對 .TEXT/CS 的 Editor 客製在升級後遺失。需在不動核心的前提下，於 CS 2.0 上重建特定編輯體驗，以降低未來升級風險。
技術挑戰：新版 UI/控件差異、事件模型不同。
影響範圍：內容編輯效率、作者體驗。
複雜度評級：中

Root Cause Analysis

直接原因：升級版本 UI/控件 API 變動。
深層原因：
- 架構層面：UI 客製未封裝為獨立控件
- 技術層面：缺少 Provider/模板覆寫
- 流程層面：未建立 UI 差異比對清單

Solution Design

解決策略：設計自定義 Editor 控件，透過頁面模板/Skins 覆寫預設 Editor，逐步回補必要功能。

實施步驟

盤點現有 Editor 功能缺口
- 實作細節：列出功能差異
- 所需資源：表單/清單
- 預估時間：1 小時
建立自定義控件
- 實作細節：包裝 TextBox/Script、事件綁定
- 所需資源：VS 專案
- 預估時間：2-3 小時
模板/Skins 覆寫與驗證
- 實作細節：在 Master/Page 中切換控件
- 所需資源：版型檔
- 預估時間：1-2 小時

關鍵程式碼/設定

public class CustomEditor : CompositeControl
{
    protected TextBox Tb;
    protected override void CreateChildControls() {
        Tb = new TextBox { TextMode = TextBoxMode.MultiLine, Rows = 20, Columns = 80 };
        Controls.Add(Tb);
        // 可加入工具列、快捷鍵、Markdown 支援等
    }
}

實際案例：作者提到過去修正「不滿意的地方」，升級後需以新方式補回。
實作環境：ASP.NET 2.0、CS 2.0 Beta 3
實測數據：編輯體驗由缺失 → 可用（質性改善）

Learning Points

核心知識點：控件覆寫與模板化
技能要求：WebForms 控件開發
延伸思考：是否導入現成富文本控件替代？

Practice Exercise

基礎：建立自定義簡易 Editor（30 分鐘）
進階：加上快捷鍵與工具列（2 小時）
專案：在站台切換新 Editor 並回報可用性（8 小時）

Assessment Criteria

功能完整性：關鍵編輯功能可用
程式碼品質：可維護性高
效能優化：載入快速
創新性：擴充性設計

Case #7: Photo Gallery 舊改造的替代與啟用（以官方功能取代）

Problem Statement

業務場景：原有 Photo Gallery 客製在升級後失效；需先以官方功能快速恢復影像發佈能力，後續再視需要擴充。
技術挑戰：功能對齊、URL/權限/上傳流程差異。
影響範圍：媒體內容管理與展示。
複雜度評級：低

Root Cause Analysis

直接原因：版本升級導致舊自改無法沿用。
深層原因：
- 架構層面：缺乏外掛式封裝
- 技術層面：處理管線變更
- 流程層面：缺少移轉計畫

Solution Design

解決策略：啟用官方 Gallery，調整路由與上傳限制，先恢復核心能力，再規劃差異補齊。

實施步驟

啟用 Gallery 模組
- 實作細節：依官方設定啟用、配置資料夾
- 所需資源：CS 2.0 管理介面
- 預估時間：30-60 分鐘
調整上傳限制與縮圖
- 實作細節：web.config 調整 maxRequestLength 等
- 所需資源：設定檔
- 預估時間：30 分鐘
驗證 URL 與權限
- 實作細節：測試公開/私有相簿
- 所需資源：測試帳號
- 預估時間：30 分鐘

關鍵程式碼/設定

<!-- web.config 範例：放寬上傳大小 -->
<configuration>
  <system.web>
    <httpRuntime maxRequestLength="10240" executionTimeout="360"/>
  </system.web>
</configuration>

實作環境：CS 2.0 Beta 3、ASP.NET 2.0
實測數據：媒體發佈能力由不可用 → 可用

Learning Points

核心知識點：先恢復核心能力，再行擴充
技能要求：設定調校、驗收
延伸思考：是否需保留舊 URL 相容？

Practice Exercise

基礎：啟用並上傳測試相片（30 分鐘）
進階：設定縮圖與大小限制（2 小時）
專案：完成舊相簿→新相簿映射（8 小時）

Assessment Criteria

功能完整性：可上傳/瀏覽/權限控制
程式碼品質：設定清晰
效能優化：縮圖快速
創新性：自動化匯入

Case #8: Community Server 擴充套件相容性檢核清單

Problem Statement

業務場景：升級至 CS 2.0 後需評估既有擴充（Extension/ServiceExtension）是否可相容或需改寫，以降低上線風險。
技術挑戰：API 變更、事件點不同、組件相依。
影響範圍：自訂功能完整性。
複雜度評級：中

Root Cause Analysis

直接原因：大版本 API/事件點調整。
深層原因：
- 架構層面：未對擴充定義明確介面邊界
- 技術層面：缺乏自動化相容性掃描
- 流程層面：無檢核清單

Solution Design

解決策略：建立相容性檢核清單（事件、設定、部署、相依），以反射列出載入組件，逐一驗證。

實施步驟

清單設計
- 實作細節：功能、事件、設定、相依四類
- 所需資源：文件
- 預估時間：1 小時
自動列舉組件
- 實作細節：反射掃描 bin 內 DLL
- 所需資源：小工具程式
- 預估時間：2 小時
逐項驗證與標記
- 實作細節：Pass/Rewrite/Drop
- 所需資源：測試計畫
- 預估時間：4 小時

關鍵程式碼/設定

// 簡易反射掃描載入擴充
foreach (var file in Directory.GetFiles(Server.MapPath("~/bin"), "*.dll"))
{
    try { var asm = Assembly.LoadFrom(file); /* 列舉型別/屬性 */ }
    catch { /* 記錄不可載入項目 */ }
}

實作環境：CS 2.0 Beta 3
實測數據：可相容擴充清單產出、無法相容項目明確化

Learning Points

核心知識點：相容性檢核實務
技能要求：反射與測試計畫
延伸思考：是否建立 CI 驗證擴充載入？

Practice Exercise

基礎：撰寫 DLL 列舉工具（30 分鐘）
進階：加入事件/設定檢核（2 小時）
專案：完成擴充相容性報告（8 小時）

Assessment Criteria

功能完整性：清單可用
程式碼品質：健壯與日誌
效能優化：掃描效率
創新性：CI 整合

Case #9: 維持 32 位 IIS 還是升級應用？決策與取捨

Problem Statement

業務場景：在有限資源下，需抉擇暫時維持 32 位 IIS 共存 1.1/2.0，或升級至 CS 2.0 以用 64 位。需形成清晰決策與路線圖。
技術挑戰：效能、維運、風險、成本的權衡。
影響範圍：未來 1-2 年維運策略。
複雜度評級：中

Root Cause Analysis

直接原因：IIS 6.0 位元限制與 1.1 不支援 64 位。
深層原因：
- 架構層面：多版本共存
- 技術層面：升級成本不可忽視
- 流程層面：未量化決策依據

Solution Design

解決策略：定義 4 構面（可用性/效能/成本/風險）評分，短期維持 32 位恢復服務，長期升級至 64 位。

實施步驟

指標定義與評分
- 實作細節：1-5 分制
- 所需資源：決策矩陣
- 預估時間：1 小時
兩案評估與結論
- 實作細節：會議決議
- 所需資源：干係人
- 預估時間：1 小時
路線圖與里程碑
- 實作細節：短中長期
- 所需資源：計畫文件
- 預估時間：2 小時

關鍵程式碼/設定

（不適用，屬流程與決策）

實際案例：作者最終選擇升級至 CS 2.0 Beta 3
實測數據：可用性與 64 位效益恢復

Learning Points

核心知識點：技術決策矩陣
技能要求：需求盤點與溝通
延伸思考：是否考慮分流/虛擬化？

Practice Exercise

基礎：建立決策矩陣（30 分鐘）
進階：完成兩案評估報告（2 小時）
專案：產出升級路線圖（8 小時）

Assessment Criteria

功能完整性：決策清晰
程式碼品質：不適用
效能優化：有量化依據
創新性：有替代方案

Case #10: 位元模式切換操作治理（標準化 adsutil/aspnet_regiis 流程）

Problem Statement

業務場景：頻繁切換 32/64 位模式易誤操作，需以標準化腳本與文件降低人為風險，提升可追蹤性。
技術挑戰：不同框架版本與註冊步驟的組合管理。
影響範圍：維運流程與風險控管。
複雜度評級：低

Root Cause Analysis

直接原因：手動操作易漏步驟。
深層原因：
- 架構層面：缺乏自動化
- 技術層面：命令多且順序敏感
- 流程層面：無 Runbook

Solution Design

解決策略：將切換、註冊、重啟、驗證封裝為批次或 PowerShell 腳本，並搭配檢核清單。

實施步驟

腳本編寫
- 實作細節：參照 Case #1/#3 指令
- 所需資源：批次檔/Pwsh
- 預估時間：1 小時
驗證與日誌
- 實作細節：輸出結果與錯誤碼
- 所需資源：日誌檔
- 預估時間：30 分鐘
文件化與交付
- 實作細節：Runbook 與權限控管
- 所需資源：文件、權限
- 預估時間：1 小時

關鍵程式碼/設定

:: switch-32bit.bat
cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32BitAppOnWin64 1
%SystemRoot%\Microsoft.NET\Framework\v1.1.4322\aspnet_regiis.exe -i
iisreset

實作環境：IIS 6.0
實測數據：誤操作率降低、操作時間穩定

Learning Points

核心知識點：自動化與治理
技能要求：腳本、文件化
延伸思考：是否導入變更申請流程？

Practice Exercise

基礎：完成 32/64 切換腳本（30 分鐘）
進階：加入健康檢查（2 小時）
專案：完成操作 Runbook（8 小時）

Assessment Criteria

功能完整性：一鍵切換
程式碼品質：防呆與日誌
效能優化：快速完成
創新性：自動驗證

Case #11: 切回 64 位後的驗收與證明（驗證實為 64 位運行）

Problem Statement

業務場景：升級至 CS 2.0 後切回 64 位模式，需以技術手段證明應用實際在 64 位執行，以符合法遵與績效目標。
技術挑戰：在 ASP.NET 2.0 環境下取得位元資訊。
影響範圍：驗收、績效報告。
複雜度評級：低

Root Cause Analysis

直接原因：人為誤判或註冊混亂。
深層原因：
- 架構層面：無客觀驗證
- 技術層面：缺預設檢查頁
- 流程層面：缺驗收標準

Solution Design

解決策略：部署簡單檢查頁輸出 IntPtr.Size 與版本，納入驗收清單。

實施步驟

建立檢查頁
- 實作細節：輸出位元與 Framework
- 所需資源：ASPX
- 預估時間：15 分鐘
切換後驗收
- 實作細節：拍照存證與歸檔
- 所需資源：文件
- 預估時間：15 分鐘
例行巡檢
- 實作細節：月度檢查
- 所需資源：排程
- 預估時間：持續

關鍵程式碼/設定

<%@ Page Language="C#" %>
<%= "PtrSize=" + IntPtr.Size + ", Version=" + Environment.Version %>
<!-- PtrSize=8 表示 64 位進程 -->

實作環境：ASP.NET 2.0、IIS 6.0
實測數據：PtrSize 由 4 → 8、確認 64 位

Learning Points

核心知識點：客觀驗收
技能要求：簡單頁面開發
延伸思考：可否在監控中自動抓取？

Practice Exercise

基礎：部署檢查頁（30 分鐘）
進階：將結果上報監控（2 小時）
專案：建立驗收流程（8 小時）

Assessment Criteria

功能完整性：輸出正確
程式碼品質：簡潔
效能優化：無
創新性：監控整合

Case #12: Beta 版本上線風險控管與回退

Problem Statement

業務場景：CS 2.0 Beta 3 非正式版，上線需有回退機制以避免未知缺陷造成長時間停機。
技術挑戰：資料相容、配置回退、溝通節點。
影響範圍：上線穩定性與品牌。
複雜度評級：中

Root Cause Analysis

直接原因：Beta 版本穩定性未知。
深層原因：
- 架構層面：回退難度高
- 技術層面：資料 schema 差異
- 流程層面：缺回退手冊

Solution Design

解決策略：完整備份、雙機影子部署、時間窗管控、回退腳本與公告模板。

實施步驟

備份與演練
- 實作細節：檔案/DB 備份與還原演練
- 所需資源：備份工具
- 預估時間：2 小時
影子部署與切換
- 實作細節：DNS/Hosts 切換
- 所需資源：測試機
- 預估時間：1 小時
回退腳本與通報
- 實作細節：腳本與公告模板
- 所需資源：文件
- 預估時間：1 小時

關鍵程式碼/設定

（略，依環境而定，重點在流程）

實作環境：CS 2.0 Beta 3
實測數據：回退時間可控（<30 分鐘）

Learning Points

核心知識點：回退設計
技能要求：備援與演練
延伸思考：可否以藍綠/灰度？

Practice Exercise

基礎：撰寫回退清單（30 分鐘）
進階：演練一次回退（2 小時）
專案：制定標準回退手冊（8 小時）

Assessment Criteria

功能完整性：回退可行
程式碼品質：腳本清晰
效能優化：時間最短
創新性：自動化

Case #13: 技術債拔除：逐步停用 ASP.NET 1.1

Problem Statement

業務場景：長期維護 32 位 IIS 以兼容 1.1 造成負擔；需制定計畫拔除 1.1 依賴，全面轉向 2.0/64 位。
技術挑戰：功能替代、時程控管。
影響範圍：系統組合與人員技能。
複雜度評級：中

Root Cause Analysis

直接原因：1.1 技術債
深層原因：
- 架構層面：歷史包袱
- 技術層面：相容性差
- 流程層面：缺轉換規劃

Solution Design

解決策略：清單化所有 1.1 相依、排程替代或升級、設停用里程碑。

實施步驟

相依盤點
- 實作細節：服務、站台、組件
- 所需資源：清冊
- 預估時間：1-2 天
替代/升級
- 實作細節：逐項替換
- 所需資源：開發/測試
- 預估時間：數週
停用與驗收
- 實作細節：切回 64 位模式、驗收
- 所需資源：Runbook
- 預估時間：1 天

關鍵程式碼/設定

（略）

實作環境：IIS 6.0、.NET 2.0
實測數據：1.1 依賴由 N 項 → 0 項

Learning Points

核心知識點：技術債治理
技能要求：專案管理
延伸思考：能否以插件化提升未來可升級性？

Practice Exercise

基礎：盤點清單（30 分鐘）
進階：替代方案設計（2 小時）
專案：完成一輪替代（8 小時）

Assessment Criteria

功能完整性：依賴清零
程式碼品質：替代方案穩健
效能優化：不退化
創新性：最小耦合

Case #14: 單機限制的替代思路：多機/虛擬化分流（備選方案）

Problem Statement

業務場景：若不願犧牲 64 位亦需保留 1.1，可考慮以多機或虛擬化分流 1.1 與 2.0 應用。
技術挑戰：成本、部署與資料同步。
影響範圍：架構與維運。
複雜度評級：高

Root Cause Analysis

直接原因：IIS 6.0 不能混合位元。
深層原因：
- 架構層面：單機承載多版本
- 技術層面：缺分流能力
- 流程層面：部署複雜度上升

Solution Design

解決策略：將 1.1 與 2.0 分至不同主機/VM，以 DNS/反向代理分流，降低單機限制。

實施步驟

拆分規劃
- 實作細節：域名/路由策略
- 所需資源：網路/機器
- 預估時間：1-2 天
部署分流
- 實作細節：反代/NLB
- 所需資源：反向代理
- 預估時間：1-3 天
驗收與監控
- 實作細節：健康檢查
- 所需資源：監控系統
- 預估時間：1 天

關鍵程式碼/設定

（依環境不同，示意）

實作環境：多機或 VM
實測數據：兩版本皆以原生位元運行

Learning Points

核心知識點：分流架構
技能要求：網路與部署
延伸思考：成本與收益評估

Practice Exercise

基礎：設計分流拓樸（30 分鐘）
進階：配置反向代理（2 小時）
專案：完成雙機上線（8 小時）

Assessment Criteria

功能完整性：分流可用
程式碼品質：不適用
效能優化：延遲可控
創新性：彈性擴展

Case #15: 善用官方知識庫（KB 894435）指引切換與排錯

Problem Statement

業務場景：需參照官方文件在 64 位 Windows 上切換 32 位 ASP.NET 1.1 與 64 位 ASP.NET 2.0，避免走錯路。
技術挑戰：正確理解與落實文件步驟。
影響範圍：切換成功率與速度。
複雜度評級：低

Root Cause Analysis

直接原因：對 IIS 6.0 位元與版本註冊細節不熟。
深層原因：
- 架構層面：複雜度高
- 技術層面：命令差異大
- 流程層面：缺文件內化

Solution Design

解決策略：將 KB 要點內化為 SOP 與腳本，並納入維運知識庫。

實施步驟

摘要 KB 要點
- 實作細節：位元切換與註冊順序
- 所需資源：KB 文件
- 預估時間：30 分鐘
內化為腳本
- 實作細節：見 Case #1/#3
- 所需資源：批次檔
- 預估時間：30 分鐘
知識庫發佈
- 實作細節：內網 Wiki
- 所需資源：知識平台
- 預估時間：30 分鐘

關鍵程式碼/設定

（同 Case #1/#3）

實作環境：IIS 6.0
實測數據：切換成功率明顯提升

Learning Points

核心知識點：文件內化與落地
技能要求：文件化、培訓
延伸思考：建立常見錯誤對照表

Practice Exercise

基礎：撰寫一頁 SOP（30 分鐘）
進階：做成操作教學（2 小時）
專案：辦一場內訓（8 小時）

Assessment Criteria

功能完整性：SOP 可用
程式碼品質：腳本正確
效能優化：操作時間縮短
創新性：可視化教學

Case #16: 干係人溝通：暫時犧牲客製，換取官方根本改進

Problem Statement

業務場景：升級至 CS 2.0 Beta 3 導致先前修正的「不滿意之處」暫時缺席，需與使用者/管理層溝通取捨與後續計畫，維持信任。
技術挑戰：將技術取捨轉為可理解的商業語言。
影響範圍：使用者滿意度、專案支持。
複雜度評級：低

Root Cause Analysis

直接原因：升級犧牲客製。
深層原因：
- 架構層面：客製未模組化
- 技術層面：大版本落差
- 流程層面：缺溝通節點

Solution Design

解決策略：以「官方改進的長期價值 + 擴充重建路線圖」進行溝通，設定回補時間表與里程碑。

實施步驟

列示官方改進清單
- 實作細節：以功能/效益呈現
- 所需資源：版本說明
- 預估時間：1 小時
回補計畫與時程
- 實作細節：優先級排序
- 所需資源：計畫表
- 預估時間：1 小時
定期回報
- 實作細節：雙週更新
- 所需資源：會議/看板
- 預估時間：持續

關鍵程式碼/設定

（不適用）

實作環境：CS 2.0 Beta 3
實測數據：干係人支持度提升（質性）

Learning Points

核心知識點：技術決策溝通
技能要求：簡報與路線圖
延伸思考：如何用數據佐證改進？

Practice Exercise

基礎：製作一頁取捨簡報（30 分鐘）
進階：排出回補 Roadmap（2 小時）
專案：召開共識會議（8 小時）

Assessment Criteria

功能完整性：計畫明確
程式碼品質：不適用
效能優化：不適用
創新性：有效溝通方式

案例分類

1) 按難度分類

入門級（適合初學者）：#10, #11, #15, #16, #7
中級（需要一定基礎）：#1, #2, #3, #4, #5, #6, #8, #9, #12, #13
高級（需要深厚經驗）：#14

2) 按技術領域分類

架構設計類：#9, #12, #13, #14, #16
效能優化類：#3, #11（驗收 64 位間接關聯）
整合開發類：#5, #6, #7, #8
除錯診斷類：#1, #2, #4, #10, #15
安全防護類：無直接描述（可於實作中加入最小權限原則）

3) 按學習目標分類

概念理解型：#1, #2, #3, #15
技能練習型：#10, #11, #6, #7, #8
問題解決型：#4, #9, #12, #13
創新應用型：#5, #14, #16

案例關聯圖（學習路徑建議）

先學哪些案例？
- 基礎與概念：#15（讀懂 KB）、#1（緊急復原）、#2（共存策略）、#10（操作治理）
依賴關係：
- #3（升級至 CS 2.0）依賴 #1/#2/#15 的位元切換與註冊知識
- #11（64 位驗收）依賴 #3 的切換完成
- #5/#6/#7/#8（擴充與客製重建）依賴 #3（新版本落地）
- #12（Beta 風險）與 #4（應變）互補
- #13（技術債拔除）依賴 #3 與 #8 的盤點成果
- #14（分流）可作為 #9（決策）的替代分支
- #16（溝通）貫穿升級全程
完整學習路徑建議： 1) #15 → #1 → #2 → #10（建立位元切換與共存基本功） 2) #9（做出戰略決策） → #3（實施升級） → #11（64 位驗收） 3) #12（風險/回退）與 #4（應變）並行準備 4) #8（擴充相容性檢核） → #5/#6/#7（重建客製與替代） 5) #13（拔除 1.1 技術債），若資源允許可探索 #14（分流架構） 6) 全程穿插 #16（干係人溝通）確保支持度

說明

本組案例嚴格以原文資訊為核（IIS 位元限制、ASP.NET 版本相容、CS 升級取捨），延伸為可操作的教學與專案練習任務。對於原文未提供之量化數據，以「可用性/可部署性」等可驗證結果替代，並補上量測與驗收方法。