Windows App CLI 0.6 上線:免金鑰雲端簽章、WinUI 鷹架指令一次補齊
GitHub microsoft/winappCli Releases · 2026-08-12
建立專案與尋找元件用法
微軟於 2026-08-12 釋出 Windows App Development CLI(套件名稱 winapp)v0.6.0,這是一支協助開發者建立、除錯、簽署 Windows 桌面應用的命令列工具,可透過 WinGet(Microsoft.WinAppCLI)或 npm(@microsoft/winappcli)安裝。這個版本把「建立新專案」與「找範例程式碼」兩件事都做成了指令,對應 PR #686 與 #681。過去要開一個 WinUI 3 專案,得先在 NuGet 上翻找對的範本套件,新版直接用一行指令產生骨架。
winapp new
winapp find-ui --query "NavigationView"
winapp run ./MyApp.csprojwinapp find-ui(PR #681)會去搜尋 WinUI 3 Gallery 與 Windows Community Toolkit 裡真正能執行的範例,回傳可直接貼上的 XAML 與 C# 片段,而不是只給 API 簽章。winapp run 則在 PR #612 中新增了 .csproj 專案模式,可以直接指到專案檔建置並啟動,不必再另外下建置指令。此外 PR #624 也補了一個以 Node.js 呼叫原生 WinUI 3 視窗的範例,方便前端背景的開發者參考。
用 Azure Trusted Signing 取代本機私鑰
新增的 winapp az-sign 指令(PR #595)把封裝簽章整個搬到雲端,底層串接 Azure Trusted Signing 服務,開發機上不再需要存放程式碼簽署用的私鑰檔案。同一版也在 PR #607 加入 sparse packaging 工作流程,讓既有的傳統桌面應用可以外掛套件識別身分(package identity),藉此使用僅限具識別身分應用程式呼叫的 API,而不用把整支程式改寫成完整 MSIX 封裝。PR #678 同時修正了 MSIX bundle 版本號產生的問題。
winapp az-sign— 呼叫 Azure Trusted Signing 簽署封裝(PR #595)- Sparse packaging 工作流程 — 為既有桌面應用加上套件識別身分(PR #607)
winapp new/winapp find-ui— WinUI 3 專案鷹架與元件搜尋(PR #686 / #681).csproj專案模式 —winapp run直接建置執行專案檔(PR #612)
替 AI 代理準備的操作紀錄格式
PR #690 讓 UI 操作錄製功能輸出帶時間戳記的 JPEG 影格與 JSON 索引,設計目的是讓 AI 代理能逐格分析畫面變化、對照使用者操作,而不只是產生給人看的影片檔。這版也把原本分開的 Copilot 與 Claude 技能整併為單一 plugin(PR #631),並新增了處理 MAUI resizetizer 的 winapp-maui 技能(PR #610)。整體來看,v0.6.0 把過去分散在文件、範本倉庫、Azure 入口網站裡的操作,統一收進同一支 CLI 之中。
原始來源:GitHub microsoft/winappCli v0.6.0 Release Notes、Windows App Development devblog
當 ARM64X 外掛「該用哪個架構跑」自己說了不算,得靠 PROC_THREAD_ATTRIBUTE_MACHINE_TYPE 指定
The Old New Thing (devblogs.microsoft.com) · 2026-08-14
原本的問題
ARM64X 是一種「肥二進位檔」(fat binary)格式,同一支 EXE 或 DLL 裡同時含有 ARM64 與 x64(經 Arm64EC 相容)兩組機器碼,讓 x64 與 ARM64 行程都能載入同一支模組。問題出在外掛程式(plug-in)場景:當一支 host 行程需要載入某個只用單一特定架構編譯的外掛 DLL 時,系統預設會依照目前行程的架構去挑對應的那半邊程式碼,開發者無法用一般的 LoadLibrary 明確指定「我就是要用 x64 那份」。Raymond Chen 在文章裡描述的情境,是需要強制某個子行程或載入動作只走 AMD64 這條路徑,即便主機是原生 ARM64 也一樣。
採用的方法
解法是透過 STARTUPINFOEXW 搭配 PROC_THREAD_ATTRIBUTE_MACHINE_TYPE 屬性建立行程,在呼叫 CreateProcessW 之前先用擴充屬性清單(process thread attribute list)把想要的機器類型寫進去,而不是依賴系統自動判斷。對於載入 DLL 而非啟動新行程的情境,文章示範的作法是先照常呼叫 LoadLibraryExW,如果因為格式不符而載入失敗,再改成以指定的 IMAGE_FILE_MACHINE_AMD64 身分重新啟動一個子行程來完成載入,搭配 GetSystemInfo 判斷目前實際跑在哪種處理器架構上。這個技巧也延伸自作者前一篇(2026-08-13)介紹的「管理 LPPROC_THREAD_ATTRIBUTE_LIST 的小型輔助類別」。
STARTUPINFOEXW siex = { sizeof(siex) };
InitializeProcThreadAttributeList(nullptr, 1, 0, &size);
siex.lpAttributeList = (LPPROC_THREAD_ATTRIBUTE_LIST)alloc(size);
InitializeProcThreadAttributeList(siex.lpAttributeList, 1, 0, &size);
DWORD machineType = IMAGE_FILE_MACHINE_AMD64;
UpdateProcThreadAttribute(siex.lpAttributeList, 0,
PROC_THREAD_ATTRIBUTE_MACHINE_TYPE,
&machineType, sizeof(machineType), nullptr, nullptr);
CreateProcessW(..., EXTENDED_STARTUPINFO_PRESENT,
..., &siex.StartupInfo, &pi);實際效果
強制指定機器類型後,行程或載入行為不再受限於目前主機的原生架構,外掛開發者可以確保特定的 x64 外掛一定被以 x64 身分載入或執行,即使呼叫端是 ARM64 或 ARM64X 混合行程。這對需要同時支援舊有 x64 外掛與原生 ARM64 主程式共存的軟體(例如帶外掛系統的編輯器、IDE)特別實用,可以避免外掛因為架構誤判而載入失敗或效能退化到完整模擬層級。
原始來源:The Old New Thing: Forcing an ARM64X executable to run as a specific architecture、Microsoft Learn: Arm64EC for Windows 11 apps on Arm
Git-APE:用 Copilot 多代理架構把「先求有」的 demo 逼著補齊 SaaS 上市該有的決策
GitHub Azure/git-ape · 2026-08-14
原本的問題
許多 ISV(獨立軟體供應商)把應用做成概念驗證後,真正卡住上市的往往不是核心功能,而是一連串平常被延後處理的架構決策:租戶隔離模式、身分驗證與授權、Marketplace 上架與計費、用量計量、法規遵循、維運就緒。Azure 官方部落格把這個落差形容為「我們做出一個 App」與「我們能把它當 SaaS 賣出去並維運」之間的距離。Git-APE(playbook automation engine for SaaS delivery)就是為了在雛型階段就強迫團隊面對這六項關鍵選擇而生。
採用的方法
Git-APE 的實作形式是一套建構在 GitHub Copilot 之上的多代理框架,而非傳統獨立 CLI:倉庫內含 8 個專責子代理與 12 個以上的技能,分別負責需求蒐集、ARM 範本產生、部署、架構審查、政策建議、成本估算、RBAC 建議與部署後測試等工作。整個流程分成五個階段:需求與架構評估、landing zone 與平台鷹架建置、Marketplace 上架設定、履約與計量實作、上線就緒驗證。執行模式分成互動式(在 VS Code Chat 內對話)與無頭式(透過 git-ape-plan.yml、git-ape-deploy.yml、git-ape-destroy.yml 這三支 GitHub Actions workflow,搭配 OIDC 驗證在 CI/CD 中執行)兩種。
- 租戶模型(tenancy model)如何選擇
- 區域部署與資料邊界規劃
- Marketplace 上架型態:contact me、trial、free、transactable
- 從購買到續約的生命週期處理
- 可計費的用量維度(billable usage dimensions)
- 安全與維運驗證關卡(gate)
每次部署產生的架構圖、成本估算與決策紀錄都會存放到 .azure/deployments/ 目錄下留存,方便日後稽核;同時內建 drift 偵測,持續比對線上實際的 Azure 資源與當初存下的部署產物是否出現落差。部署前也設有安全關卡與 Well-Architected Framework(WAF)審查,阻擋在資源尚未建立前先擋下明顯有風險的設計。
實際效果
目前 Git-APE 官方定位仍是「實驗性、非正式環境可用」,官方説明明確寫著僅建議用於本機開發、demo、sandbox 訂閱與學習用途,尚未建議直接套用在正式生產環境。截至部落格發文時,倉庫已累積 268 顆星、40 個 fork、325 次主分支提交,並開放 52 個未結案 issue,顯示專案仍在快速迭代中。想要試用的團隊可以透過 VS Code Marketplace 擴充套件、Copilot CLI plugin 或本機開發設定三種方式安裝。
原始來源:GitHub: Azure/git-ape、All Things Azure: Git-APE SaaS Factory