netcoredbg 統合 C# 拡張の 8 プラットフォーム自動リリース構築記

2026年9月6日、私が運営する vscode-csharp-autobuild リポジトリで C# (with netcoredbg) 2.148.23001 の初回リリースを完了しました。Windows、Linux、Alpine Linux、macOS の x64 と ARM64 向けパッケージをすべて Open VSX に公開し、公開ファイルのハッシュが検証に使用した VSIX と一致することを確認しました。初回リリースには、C# 拡張と netcoredbg のソースバージョン、プラットフォーム別パッケージ、検証記録をまとめています。

本稿では、既存コミュニティの貢献と AI を活用したプロジェクトの出発点、8 プラットフォームの互換性検証、公開処理が中断した場合の復旧を扱います。定期ワークフローが新しいバージョンを検出すると、ソースビルドから公開ファイルの確認まで処理し、問題があればその候補の公開を停止する構成にしました。今回のリリースを踏まえて考えている後続の開発ツールについても紹介します。

まず別の拡張を作った理由から始め、プラットフォームの互換性問題とテスト範囲を説明します。その後、バージョンの対応付け、初回公開で判明した運用上の問題、実験用ワークフローの整理を取り上げます。最後に VS Code OSS ベースの .NET 開発ツール構想を紹介します。本稿のサポート範囲と実行結果は、2026年9月6日の初回リリースを基準としています。

既存の C# 配布を維持する別の拡張 ID

従来のリポジトリでは、Microsoft の C# 拡張ソースを自動ビルドして Open VSX に公開してきました。対象は C# 拡張であり、C# Dev Kit は含みません。公開用メタデータとビルド環境を調整しつつ、上流拡張の動作とデバッガー実装を維持する配布です。

C# 拡張のソース公開と、同梱デバッガーの利用範囲は別々に考えられます。Microsoft は vsdbg に関する文書で、このデバッガーをプロプライエタリな構成要素と説明し、Microsoft の IDE での利用に制限しています。そのため、拡張を Open VSX に移すだけでは VS Code 派生エディターにおけるデバッガーの制約までは解消できません。

既存の配布には、上流の動作をできる限り維持する価値があります。既存ユーザー全員にデバッガーの置き換えを適用するのではなく、別の拡張 ID を作りました。二つの配布は次の基準で選択できます。

コミュニティでは muhammadsammy/free-vscode-csharp がすでに netcoredbg を統合し、VS Code 派生エディターで使える C# 開発環境を提供してきました。私は、このプロジェクトが築いた選択肢と、その過程で積み重ねた貢献に大きな歴史的価値を感じています。代替手段を実際に使える拡張として公開し、維持してきた muhammadsammy と貢献者の皆さんに敬意と感謝を表します。

私がこのプロジェクトを始めたのは、変化の速い .NET エコシステムの成果をより多くの方に伝え、それぞれのエディターで体験していただきたいと考えたからです。調査、実装、失敗原因の分析に AI を活用しながら、メンテナーの繰り返しの介入を減らす配布体制を目指しました。今回の初回リリースで、その意図を 8 プラットフォーム向けパッケージと自動検証手順として具体化できました。

今回の配布では、上流の動作を保つ既存の配布を維持しつつ、タグごとのソースビルド、全プラットフォームの検証、別拡張としての公開を一つの運用フローにつなぐことに注力しました。既存コミュニティ拡張との違いも、こうした配布の目的と運用構造から説明できます。AI を活用して作成したスクリプトとテストが定期配布を実行し、検証に失敗した回はメンテナーがログを調べて対応する構成にしています。

名称も、当初検討していた Samsung を含む表記から C# (with netcoredbg) にしました。アイコンは明るい茶色の五線譜に C と # を置いたデザインで区別しています。プロジェクトの出自は説明と告知に残し、公式配布やスポンサー関係を示唆するブランド表現は使っていません。配布の区分とパッケージ方針に、二つの拡張の役割を記録しました。

原本ソースの保全と外部互換コードの境界

出発点は、netcoredbg の新しいタグを取得してプラットフォーム別にビルドし、C# 拡張に接続する方法でした。netcoredbg の MIT ライセンスは、著作権表示と許諾表示を含める条件で、複製、変更、配布を認めています。実際のパッケージでは、同梱ライブラリの告知も別途保持しました。

原本の保全はファイルハッシュで確認しました。ビルド前後で Samsung の入力ファイル 498 個の SHA-256 を比較し、初回リリースの全ネイティブ対象で変更がないことを確認しました。中間生成物、テスト用プロジェクト、互換コードは元のソースツリーの外で管理しています。

ビルドを自動化するだけでは、コンパイラーやランタイム環境の違いは解消しませんでした。Windows ではネイティブビルドとマネージドコードのビルドが中間出力パスを共有し、NuGet のアセットファイルが衝突しました。ネイティブ部分と ManagedPart のビルドを分離し、出力パスを分けて解決しました。

Alpine では、デバッガーをビルドできても .NET ランタイムの初期化中にクラッシュしました。コールスタックと再現結果を基に外部互換コードを追加し、明示的に確保した 8 MiB のスレッドスタック上で CoreCLR を初期化する構成にしました。この変更は原本ファイルに手を加えなくても、ランタイムの動作に関与します。そのため、原本ファイルを保全したことと、本リポジトリが互換コードの保守を担うことを併せて説明しています。ビルド問題と解決の記録には、再現条件と根拠を残しました。

C# 拡張側にもコード変更を加えました。一時チェックアウトに適用するオーバーレイが、拡張 ID、表示名、デバッガーのダウンロード先、アダプター選択、SDK 環境の引き渡し、パッケージングを調整します。上流コードが想定と異なればオーバーレイが失敗するように検査します。統合コードにこれらの変更をまとめています。デバッガーを置き換えても、C# 拡張の他の構成要素に適用されるライセンスや利用条件はそれぞれ維持されます。

ビルド成功後に判明したデバッガーの動作不良

基本的なブレークポイント検証を通過した macOS デバッガーでも、終了コードの誤りが見つかりました。最初に作った検証プログラムは正常終了コード 0 を返していました。Samsung の VSCodeTestExitCode は macOS で終了コード 3 を期待しますが、その時点でビルドしたデバッガーは DAP 応答で 0 を返していました。正常終了だけを確認するテストでは発見できない問題でした。

DAP（Debug Adapter Protocol）は、エディターとデバッガーがブレークポイント、スタック、変数、プロセス終了などの情報をやり取りする規約です。終了コードが異なると、プロセス自体は終了していても、エディターが受け取る実行結果が誤っている可能性があります。

macOS のプロセス終了状態を監視する外部ライブラリを接続して問題を修正しました。.NET 8 で動作した後も、.NET 10 では追加調整が必要でした。.NET 10 のランタイム構成要素が waitpid$NOCANCEL エントリーポイントを使うことを確認し、その経路も処理しました。その後、同じテストが両ランタイムで終了コード 3 を返しました。失敗したテストは検証一覧に残し、Darwin 互換コードの調査記録に修正前後の結果を分けて記載しました。

機能検証は独自プログラムの 8 検査項目に、Samsung の自動 DAP シナリオ 30 個を加えて拡張しました。上流テストの C# ソースとアサーションを維持し、外部プロジェクトで .NET 8 と .NET 10 を対象にビルドしました。手動実行用に分類された別のシナリオは、自動検査の件数に含めていません。

初回リリースでは次のプラットフォーム範囲を検証しました。

8 プラットフォームと 2 ランタイムを 2 段階で検証するため、合計 32 通りを実行しました。ビルド直後と VSIX から取り出したデバッガーに同じシナリオを適用し、パッケージング後の動作も確認しました。初回リリース実行では、全ネイティブビルド、VSIX パッケージング、展開後の機能検証を最初の試行で通過しました。公開段階の失敗は後述します。

ただし、全プラットフォームの DAP 検証と実際のエディター UI 検証では範囲が異なります。別途実施したインストール検証では、macOS ARM64 上の VS Code 1.135.0 を使用しました。VSCodium を含むすべての派生エディター、リモートデバッグ、統合ターミナル、Hot Reload、C# Dev Kit の全機能まで確認した結果としては扱っていません。

次の実行画面では、Program.cs の 7 行目に設定したブレークポイントで停止し、ローカル変数とコールスタックを確認できます。

調査中には macOS の起動遅延や例外スタック関連のテストが断続的に失敗しました。同じ候補の再実行が通過した記録もありますが、根本原因は確定していません。失敗記録を保全し、今後の候補でも同じ問題が発生すれば公開を停止する方針を維持しています。

C# とデバッガーのバージョンを結ぶ配布記録

インストールする拡張のバージョンは C# 拡張の流れに合わせつつ、デバッガーだけの変更やパッケージングコードの修正でも新しいパッケージを区別できるよう、配布リビジョンを加えました。

初回リリースの入力と出力は次のとおりです。

数値のパッチ部分は 上流 C# のパッチ × 1000 + 配布リビジョン で計算します。今回は 23 × 1000 + 1 = 23001 なので、2.148.23001 を使用しました。次のリビジョンは 2.148.23002 とし、C# のパッチが 24 に変われば 2.148.24001 から始めます。配布リビジョンは 1 から 999 まで認め、範囲を超えた場合は自動処理を失敗にします。

GitHub のリリースタグには、C# バージョン、netcoredbg タグ、デバッガーの短縮コミット ID、配布リビジョンを組み合わせます。完全なコミット ID、ビルド設定のフィンガープリント、検証実行 ID、ファイルハッシュはマニフェストとパッケージメタデータに保存します。数値バージョンにすべての詳細を詰め込まず、インストールしたバージョンから正確なソースと検証済みファイルをたどれるようにしました。バージョン計算コードと初回リリースのマニフェストで、実際の対応関係を確認できます。

上流タグの -prerelease 表記も記録に残しています。VSIX に数値バージョンを付けても、上流ソースがプレリリースであることは変わりません。公開前のドラフトリリースと公開済みリリースは使用したリビジョンを確保し、公開しない検証実行はリビジョンを消費しません。

初回公開で判明した反映遅延とドラフトの参照権限

最初の Open VSX アップロードは、すべての機能検証を通過した後に失敗しました。公開ツールは Windows x64 パッケージを受け付けたと応答しましたが、直後の公開メタデータ取得は HTTP 404 を返しました。当時のコードは公開ファイルをすぐに取得できると想定していたため、処理を中断しました。

約 4 分後には、同じバージョンの Windows x64 パッケージを公開 URL から取得できました。Open VSX の公開処理コードは、ファイル保存や検査などの一部を非同期で実行し、有効化が完了するまではそのバージョンを公開しません。そこで CLI の受け付け成功と公開ダウンロードの可否をそれぞれ確認するよう、公開手順を修正しました。

修正後のパブリッシャーは、まだ存在しないプラットフォームを一度ずつアップロードしてから公開状態を待ちます。すべてのアップロードを送信した後から共通の 15 分間を上限とし、公開ファイルをダウンロードして検証済み VSIX の SHA-256 と比較します。期限超過やファイル内容の不一致があれば、その実行を失敗にします。公開を待つ間に同じファイルを繰り返しアップロードすることはありません。

復旧用のファイルは、最初のアップロード前に GitHub のドラフトリリースに保存します。デバッガーのアーカイブ 8 個、VSIX 8 個、検証マニフェスト、リリースマニフェスト、検証記録のアーカイブの計 19 アセットを保全しました。一部のプラットフォームだけを公開した状態で処理が止まると、次の実行がドラフトからファイルを復元し、公開済みファイルのハッシュを比較します。内容が一致するプラットフォームはスキップし、残りの公開を再開します。

最初の復旧実行では別の問題も判明しました。検出ジョブに付与した contents: read 権限では公開リリースの一覧を読めましたが、非公開ドラフトは一覧に現れませんでした。GitHub Releases API の文書では、プッシュ権限のある呼び出し元だけがドラフトの一覧を取得できると説明しています。検出ジョブに contents: write を付与すると、保全していた初回リリースを見つけられました。ビルドとパッケージングのジョブは、リポジトリへの読み取り権限を維持しています。

復旧実行は、初回リリースのバージョンとファイルを保ったまま残りの 7 プラットフォームを公開しました。韓国標準時の2026年9月6日21時57分19秒に、GitHub リリースの確定まで完了しました。公開済みの Windows x64 パッケージは再ビルドも再アップロードもしていません。別途行ったダウンロード検査でも、8 プラットフォームすべてで元の検証ハッシュと一致しました。初回公開と復旧の記録に、失敗時の状態と復旧結果を併記しています。

セッションに依存しない配布と保守範囲

定期配布はデフォルトブランチ main で 6 時間ごとに実行します。C# と netcoredbg のタグを調べ、新しいソースまたはビルド設定の組み合わせを検出すると、すべての検証を開始します。完了済みの組み合わせはスキップし、公開中断によるドラフトが残っていれば、そのファイルの復旧を優先します。全段階を GitHub ホストランナーで実行するため、ローカルターミナルや今回の作業セッションを開いたままにする必要はありません。定期配布ワークフローに、この入口をまとめました。

運用方針は、失敗した Actions 実行とその証拠を中心に構成しました。機能検査、ファイルハッシュ、プラットフォームの結果のどれかが一致しなければ、その候補の公開を停止します。失敗した入力は次の周期でも再検証でき、メンテナーはログを基に原因を調査します。通知はメンテナーの GitHub 設定に従い、専用の通知サーバーや隔離キューは追加していません。トークンの有効性、サービス障害、GitHub の予約実行の遅延と非アクティブなリポジトリの扱いは、引き続き運用上の条件に含まれます。

複数プラットフォームを Open VSX に公開する処理は、全件成功か全件取り消しかを保証するトランザクションにはなりません。一部が先に公開される可能性があるため、元の検証済みファイルを保全して公開を再開する方式を選びました。自動ロールバックは実装せず、公開後の機能問題を修正する場合は配布リビジョンを上げた新しいパッケージを提供します。リリースを取り下げても、ユーザーがすでにインストールしたファイルまでは自動的に戻りません。復旧とロールバックの検討記録で、この範囲を区別しています。

リリース後は、実験中に作った Windows 専用の検証と Alpine 診断のワークフローを整理しました。従来の C# 公開、新拡張の配布入口と内部検証ワークフロー、GitHub 管理の Copilot ジョブを維持しています。手動検証も、新しい配布入口で公開オプションを無効にする方法に統一しました。一時ブランチと削除を承認した診断実行記録を削除した後も、調査文書と正式リリースのアセットは保全しています。整理の記録を残し、イシュー #2を完了としてクローズしました。

VS Code OSS ベースの .NET 開発ツールへつながる構想

今回の経験を基に、今後機会があれば VS Code OSS ベースのオープンソース .NET 開発ツールにも着手したいと考えています。C# Dev Kit の開発体験を参考に、ソリューションとプロジェクトの探索、ビルド、テスト、デバッグをエディター内でつなぐ方向を想定しています。Microsoft の C# 開発文書では、C# Dev Kit によるソリューション管理や統合テストなどを紹介しています。こうした作業フローのうち、オープンソースのツールで構成できる範囲から検討する予定です。

後続ツールの進行状況は、基準日とともに次のように記録します。

2026年9月6日現在、後続の開発ツールにはまだ着手していません。着手時期と詳細な機能は、今後の検討を経て具体化する予定です。

今回の拡張で得たデバッガー統合とプラットフォーム別検証の経験は、後続作業の出発点にできます。ソリューション管理とテスト実行までつなぐ際には、既存のオープンソース構成要素の役割とライセンスを別途調査し、実際のエディター上の動作も検証する予定です。後続作業でも調査と実装に AI を活用し、実行結果を基に公開する機能とサポート範囲を定めたいと考えています。

検証済みの範囲から始める別の C# 配布

今回のプロジェクトでは、コミュニティが築いてきた選択肢に感謝を示しながら、AI を活用して最新の .NET 開発環境をより広く届けるという意図を実際の配布につなげました。上流 C# 拡張と netcoredbg のソースを組み合わせ、検証済みのプラットフォーム別ファイルを繰り返し公開する運用経路を整えました。初回リリースの記録には、機能検査と公開ファイルの確認結果、残る制約を保全しています。

パッケージは Open VSX の C# (with netcoredbg) から選択できます。上流の動作維持を優先する場合は従来の配布を引き続き使えます。netcoredbg 統合版を選ぶ場合は、記録したプラットフォームと機能範囲を判断材料にできます。当面の運用では、新しいタグやランタイム、コンパイラーの変化に対して同じ検証を繰り返し、失敗原因を調査します。VS Code OSS ベースの開発ツールは次の機会に着手を検討する長期構想とし、今回の拡張は公開したサポート範囲内で維持していきます。