在 VS Code 裡重現 Visual Studio 開發 ASP.NET Core 與 .NET Framework 的基礎體驗。
僅支援 Windows。.NET Framework 的建置需要本機安裝 Visual Studio 或 Build Tools（含 MSBuild 元件）。
語言服務（IntelliSense、跳轉定義、重構）與偵錯器本身都交給 ms-dotnettools.csharp，本擴充功能專注在 VS Code 原生缺少的部分：方案層級的建置、偵錯的設定、專案參考、NuGet，以及 VS 風格的快捷鍵。
功能
建置
以方案（.sln / .slnx）為單位建置，錯誤與警告解析到 Problems 面板，可點擊跳到原始碼。
引擎的選擇是自動的，規則和 Visual Studio 一致：
| 方案內容 |
使用的引擎 |
| 全部都是 SDK-style 專案 |
dotnet build |
| 含任何非 SDK-style（legacy）專案 |
VS 的 MSBuild.exe（透過 vswhere 定位） |
dotnet build 完全無法建置 legacy 專案，而 VS 的 MSBuild 兩種都能建；因此只要有一個 legacy 專案，整個方案就走 MSBuild。找不到 VS 時會退回系統內建的 Framework MSBuild，但它缺少 WPF／Web 等 VS 安裝的 targets。
診斷訊息維持工具鏈本身的語言（不強制英文），與 Visual Studio 的行為相同。
組態與平台
狀態列顯示 方案 | Configuration | Platform，點擊即可切換。選單的內容來自方案自己宣告的組態（.sln 的 GlobalSection(SolutionConfigurationPlatforms)、.slnx 的 <Configurations>），不是寫死的 Debug／Release——legacy 方案常有 x86，那正是 COM interop 與 32-bit 原生相依需要的。
Configuration 與 Platform 是一組，不能各自獨立選：MSBuild 用這一組來選方案組態，配不起來的組合就是 MSB4126。
建置單一專案（Shift+F6）時傳給 MSBuild 的平台，是查方案的 ProjectConfigurationPlatforms 對應表得到的專案自己的平台，而不是方案的平台。兩者經常不同：方案的 Release|x64 在一個沒有 x64 組態的類別庫上通常對應到 Release|AnyCPU。直接把方案的平台傳給專案會讓 OutputPath 沒有值，建置就失敗。
偵錯（F5）
本擴充不含偵錯器。ms-dotnettools.csharp 已經帶了 vsdbg，這裡做的是它不做的那一半：從方案裡決定要偵錯什麼、產出正確的設定、交給它。
| 專案 |
使用的偵錯器 |
| SDK-style（net10.0 等） |
"type": "coreclr" |
| .NET Framework（net48、legacy 專案） |
"type": "clr" |
按 F5 時我們的項目會出現在偵錯設定的選單裡，不需要 launch.json。也可以用「Generate launch.json for Startup Project」產生一份能進版控的設定。啟動專案選定後會記住——建置你正在看的檔案是 Shift+F6 的語意，偵錯不是。
不是本擴充產生的偵錯設定（手寫的、或 C# Dev Kit 的）會原封不動放行。
.NET Framework 專案的兩個預設值
clr 偵錯器限 64-bit 行程與 portable PDB，而 Visual Studio 的 net48 專案範本兩個都不滿足——它比這兩項限制都要早。所以 F5 前會先檢查，並提示修好：
| 限制 |
範本寫進 csproj 的值 |
實際後果 |
處理 |
| 限 64-bit |
<Prefer32Bit>true</Prefer32Bit> |
AnyCPU 編成 anycpu32bitpreferred，在 64-bit Windows 上跑成 32-bit 行程 |
提示改成 false（專案維持 AnyCPU，只是不再要求 32-bit） |
| 限 portable PDB |
<DebugType>full</DebugType>（Release 為 pdbonly） |
產出 Windows PDB，斷點一個都不會綁上 |
提示改成 portable |
PlatformTarget 是 x86 時只回報、不自動修。x86 在 legacy 專案裡通常是必要的（COM interop、32-bit 原生相依），改成 x64 不是修好而是弄壞——那是只有你知道的事。
修改只落在目前這一組 Configuration|Platform 的 PropertyGroup 裡，Release 不受影響；改完會重新向 MSBuild 評估一次確認真的生效。SDK-style 專案沒有這一節的問題：Microsoft.NET.Sdk.props 的預設本來就是 DebugType=portable 與 Prefer32Bit=false。
專案屬性一律問 MSBuild
launch.json 的 program 要指向實際的 exe，而那條路徑（TargetPath）是 OutputPath、AssemblyName、OutputType、Directory.Build.props 共同決定的，從 csproj 文字算不出來。所以這裡用 MSBuild -getProperty 拿建置會用的同一次 evaluation 的結果，不執行任何 target。
要建置哪個組態，走的是方案的 ProjectConfigurationPlatforms 對應表（同「組態與平台」一節）——方案的 x64 未必是專案的 x64，而 exe 就躺在那個平台的輸出目錄裡。
這需要 MSBuild 17.8+（VS 2022 17.8 以後，以及 .NET SDK 8 以後的 dotnet msbuild）。退回系統內建的 Framework MSBuild 時會明白回報無法判定，而不是猜一個可能是錯的答案。
Explorer 的 legacy 檔案標示
legacy（non-SDK）專案沒有隱含 glob：每個檔案都要 <Compile Include="..." /> 明確列出。磁碟上有、csproj 裡沒有的 .cs 檔不會被編譯，Explorer 卻照常顯示它——你改了它、存了檔、建置成功，然後發現改的東西沒有生效。
這種檔案會被加上 ∅ badge 與說明用的 tooltip。做在現有的 Explorer 上，不是另外畫一棵樹：git 顏色、rename、drag-drop、檔案巢狀全部保留。SDK-style 專案不標——那裡資料夾就是專案，每個 badge 都會是錯的。
Compile 清單來自解析 csproj 文字，且只在確定的時候才標：專案裡出現萬用字元、沒展開的 $(...)、或 .projitems 共用專案時，整個專案就不標了——寧可少標一個，也不要對一個真的會編譯的檔案說謊。所有 ItemGroup 取聯集，含條件式的：只在 Release 編譯的檔案不算「不在專案裡」，所以標示與目前選的組態無關。
專案參考
新增／移除專案參考、加入組件參考（瀏覽 .dll 或指定框架組件名稱）。新增前會走訪參考圖，擋下會造成循環參考的組合。
專案檔以文字方式就地修改，只動到目標那幾行，不會重排整個 XML — legacy 專案多半是手工維護的，重排會讓 diff 無法閱讀。
NuGet
搜尋 nuget.org、選版本、安裝／更新／解除安裝，以及檢查可更新的套件。
僅支援 PackageReference 專案（包含使用 PackageReference 的 net48 專案）。使用 packages.config 的專案會被偵測到並提示遷移 — 正確地安裝到 packages.config 需要下載 nupkg、依 TFM 挑選 lib 資料夾並寫入 <Reference><HintPath>，那是 NuGet 自己的工作，做錯會弄壞專案檔。
快捷鍵
VS 風格的按鍵對應，可用 vsfx.keymap.enabled 整組關閉。
| 按鍵 |
動作 |
Ctrl+- / Ctrl+Shift+- |
上一個／下一個瀏覽位置 |
Ctrl+K Ctrl+R |
尋找所有參考 |
Ctrl+K Ctrl+T |
呼叫階層 |
Ctrl+F12 |
移至實作 |
Ctrl+Shift+B |
建置方案 |
Shift+F6 |
建置目前專案 |
Ctrl+Break |
取消建置 |
Ctrl+Alt+O |
顯示建置輸出 |
F12（移至定義）、Shift+F12（尋找參考）、Alt+F12（窺視定義）、F8（下一個問題）在 VS Code 預設就與 VS 相同，因此未重新對應。
F5 也未重新對應。VS Code 的 F5 已經是「開始偵錯」，本擴充的偵錯設定會出現在它的選單裡；把 F5 搶過來會連帶接管同一個視窗裡其他語言的偵錯。
設定
| 設定 |
預設 |
說明 |
vsfx.keymap.enabled |
true |
啟用 VS 風格快捷鍵 |
vsfx.build.verbosity |
minimal |
MSBuild 輸出詳細程度 |
vsfx.build.msbuildPath |
"" |
指定 MSBuild.exe 路徑；留空則透過 vswhere 自動偵測 |
vsfx.build.dotnetPath |
"" |
指定 dotnet.exe 路徑；留空則依 DOTNET_ROOT → PATH → 預設安裝位置偵測 |
vsfx.build.parallel |
true |
傳 /m 給 MSBuild 做平行建置 |
vsfx.build.problems.enabled |
true |
把建置的錯誤與警告寫進 Problems。C# 擴充本來就會回報開著的檔案裡的編譯器錯誤，那些會出現兩次；關掉等同 VS 的 Error List 只看 IntelliSense，但 MSB 系列與沒開著的檔案裡的錯誤也會一起看不到 |
vsfx.explorer.decorateLegacyFiles |
true |
在 Explorer 標示 legacy 專案不編譯的原始檔 |
vsfx.nuget.includePrerelease |
false |
搜尋結果包含 prerelease |
開發
npm install
npm run compile # 打包到 dist/
npm run typecheck
npm run build-tests && npm test
按 F5 開啟 Extension Development Host 實測。
路徑處理
原始碼一律用 import { win32 as path } from 'node:path'，不要用 node:path 的預設匯出。
這個擴充套件處理的每一條路徑都是 Windows 路徑——MSBuild 的輸出、.csproj 的 Include、.sln 的項目、工具本身。正式環境的 host 一定是 Windows，所以 node:path 本來就等於 path.win32；明確寫 win32 是為了讓單元測試在 Linux CI runner 上跑出同樣的結果。用預設匯出的話，path.resolve('C:\\work', 'Program.cs') 在 Linux 上會得到 /builds/.../C:\work/Program.cs。
發佈
CI（.gitlab-ci.yml）在每次推送時跑 verify（typecheck + 測試）並打包出 VSIX 成為 artifact。推 vX.Y.Z 格式的 tag 才會發佈到 Marketplace。
放版步驟：
# 1. 更新 package.json 的 version 與 CHANGELOG.md
# 2. commit 後打 tag，tag 必須與 package.json 的 version 一致
git tag v0.2.0
git push origin v0.2.0
tag-matches-version job 會擋下版號不一致的 tag。Marketplace 的版號一旦發佈就無法重用，所以這道 guard 是必要的。
發佈需要 VSCE_PAT 這個 CI/CD 變數（masked + protected），來源是 Azure DevOps 的 Personal Access Token，scope 選 Marketplace → Manage。
藍圖
未來的規劃、已排除的方向，以及背後的決策理由記在 ROADMAP.md。
