VSCodeでC#を始める：.NET SDK＋拡張機能＋実行まで最短手順

STEP0：最短で動かす全体像（導入）

この記事は、VSCodeでC#のコンソールアプリを作り、実行とデバッグまで通すための最短手順をまとめます。

この記事は初心者が「最短で動いた」を作ることを最優先にします。

環境構築は寄り道すると沼りやすいので、必要最低限の道具を順番どおりに入れる方針で進めます。

途中で「これで合ってる？」が出たら、確認コマンドで機械的に判定します。

この記事は「迷ったらこれ」という決め打ちの選択肢を置き、判断回数を減らして進めます。

同じことを二度調べないために、判断基準もセットで書きます。

途中で詰まっても戻りやすいように、各STEPの終わりに確認コマンドと復旧の当たりを用意します。

最終的に「原因の切り分けができる状態」を作るのが狙いです。

慣れてきたらカスタマイズしてもよいですが、最初は本記事の順番を崩さないのが最短です。

この記事のゴール（VSCodeでHello Worldまで）

ゴールは、dotnetで作ったConsoleプロジェクトをVSCodeで開き、Hello Worldを実行して、ブレークポイントで止められる状態にすることです。

さらに、ターミナル実行とVSCode実行の両方で同じ結果が出ることも確認します。

最終的には「実行できる」「止めて覗ける」「テストが回る」の3点が揃えば合格です。

この3点が揃うと、学習や業務で躓く確率が一気に下がります。

Hello Worldが動けば、以降はテンプレートを変えるだけでWebやAPIにも発展できます。

先にコンソールで土台を固めると、次の分野に移るときの手戻りが減ります。

このガイドは深い設定よりも、最短で一周して成功体験を作ることを優先します。

細かい最適化は「動いたあと」に回すのがコツです。

完璧な設定を目指すより、まずは一度通して「動く状態」を持つ方が安心できます。

必要なもの（PC/権限/回線）

必要なのは、管理者権限でインストールできるPCと、VSCodeを入れられるネット回線です。

社内PCで制限がある場合は、先に許可を取る方が結果的に最短です。

ストレージは数GB空いていれば十分ですが、容量不足だとSDK更新で躓くので余裕があると安心です。

空き容量が少ないなら、まず不要ファイルを整理してから始めます。

会社PCなどで権限がない場合は、先に情シスへ「.NET SDK」と「VSCode拡張の導入許可」を確認します。

許可が取れないときは、持ち帰りPCや仮想環境の検討に切り替えます。

Windowsの場合はPowerShell、Macの場合はTerminalが使える状態にしておきます。

ターミナルの基本操作だけ先に慣れておくと、後の操作が速くなります。

ネット回線が不安定なら、SDKとVSCode本体だけ先に落としておき、オフラインでも進められる状態を作ります。

この順番が最短な理由（結論）

最短になる理由は、.NET SDKで実行基盤を固めてからVSCode拡張で編集とデバッグを整え、最後にプロジェクトを作ると原因切り分けが一発でできるからです。

逆順で進めると「拡張が悪いのかSDKがないのか」が混ざって時間が溶けます。

また、最初にdotnetコマンドで動作確認しておくと、VSCode固有の問題に集中して対処できます。

迷子になったら「dotnet runが通るか」「F5で止まるか」の2点に戻るのが最短です。

この2点が通る状態を作るのが、この記事の設計そのものです。

迷ったら環境をいじる前に、まず確認コマンドの結果だけを見て判断します。

STEP1：.NET SDK を入れる（開発エンジン）

C#は.NET SDKが入っていないとビルドも実行もできないので、まずここを確実に通します。

最初の関門は「dotnetコマンドが動く」ことです。

SDKは開発用の道具箱なので、最初に入れておくほど後工程のエラーが減ります。

ここが曖昧だと、以降のSTEPが全部不安定になります。

SDKは後から入れ直してもよいですが、先に正しく入れておく方が結局早いです。

まず入れるのはSDK（ランタイムとの違いは最小でOK）

最初に入れるべきものは.NET SDKで、ランタイムだけではプロジェクト作成やビルドができません。

迷ったら「SDK」という言葉が入っているインストーラを選びます。

仕事や学習で複数プロジェクトを触る予定があるなら、長期サポート版（LTS）を選ぶと安定します。

最新版を入れるか迷ったら、まずLTSで一度動かすのが安全です。

インストール前に既存のSDKが入っている場合でも、まずは一つ動作することを優先します。

複数SDKは後から整理できるので、最初は成功を優先します。

プロジェクトによっては特定バージョンが必要になることがありますが、まずは動く基準を一つ持つのが大事です。

インストール手順（Windows/Mac）

Windowsは公式サイトから.NET SDKのインストーラを入手して実行し、案内どおりに進めます。

インストール先は既定のままで問題ないので、変更はしない方がトラブルが減ります。

Macは公式サイトのインストーラを使うか、HomebrewでSDKを入れる方法が一般的です。

Homebrewを使う場合は、brew自体が動くことも先に確認します。

Homebrewを使う場合は、brewの更新が止まっていないかも合わせて確認します。

インストール中にPC再起動を促されたら、あと回しにせずその場で再起動します。

再起動を挟まないと、PATH反映のタイミング差で「入ったのに見つからない」が起きやすいです。

社内PCで再起動が難しい場合は、最低でもVSCodeとターミナルを完全終了して起動し直します。

インストール確認（dotnet –version / –info）

ターミナルでdotnet –versionを実行してバージョンが表示されればインストール成功です。

続けてdotnet –infoでSDKの場所と実行環境が出ることも確認します。

確認で見るポイントは「SDKが列挙される」「インストールパスが空ではない」の2つです。

この確認は、後で誰かに相談するときにもそのまま使えます。

この段階でdotnetが見つからないなら、次の「つまずき最短復帰」を先に実施します。

実行結果はスクリーンショットやメモで残しておくと、後から比較できて安心です。

つまずき最短復帰（PATH/権限/再起動）

dotnetが見つからない原因の多くはPATH未反映なので、まずターミナルとVSCodeを完全終了して開き直します。

Windowsでは「新しいターミナル」ではなく、いったんウィンドウごと閉じて開き直す方が確実です。

それでもだめなら再起動し、再起動後に同じコマンドで確認します。

権限エラーが出る場合は、管理者でインストーラを実行できているかを見直します。

Macでコマンドが見つからない場合は、ターミナルの種類やシェル設定でパスの読み込みが違うことがあります。

最短復旧の方針は「環境をいじる前に再起動で反映差を潰す」です。

復旧の合図は、dotnet –versionが出ることだけで十分です。

復旧を急ぐときほど、PATHを手作業でいじる前に再起動を先に試します。

STEP2：VSCode 拡張機能を追加（エディタ強化）

次はVSCode側を整えて、補完とデバッグを最小の手間で使える状態にします。

ここでの目的は、入力補助とデバッグ体験を早めに手に入れて学習効率を上げることです。

拡張は「必要なものだけ」に絞るほど、トラブルが減ります。

また、拡張の導入を先に済ませておくと、プロジェクトを開いた瞬間に解析が走り、迷いが減ります。

まず入れる拡張（結論→理由の順）

結論として、C#開発には「C# Dev Kit」と「C#」系の公式拡張を入れるのが無難です。

理由は、プロジェクト解析とデバッグ設定を自動化してくれて、初心者の詰まり所を丸ごと潰せるからです。

軽量にしたい場合でも、最低限C#言語サポートの拡張だけは入れます。

迷ったときは「公式」「Microsoft」表記のある拡張を優先して、似た名前の非公式を避けます。

拡張を増やしすぎると起動が遅くなるので、最初は必要最小限だけに絞ります。

拡張の追加は、困ってからでも遅くありません。

導入後に不具合が出たら、拡張を一度無効化して切り分けできるよう、最初は少数にしておくのが安全です。

拡張の入れ方と有効化確認

VSCodeの左側の拡張機能アイコンを開き、検索欄にC#と入力して該当拡張をインストールします。

インストール後はVSCodeを再起動し、拡張の状態が「有効」になっていることを確認します。

拡張の更新が保留になっていると動作が不安定になるので、更新があれば先に適用します。

社内プロキシなどで失敗する場合は、ネットワーク設定を先に解決します。

オフライン環境では拡張の導入経路が変わるので、社内手順があるならそれに従います。

確認の合図は、C#ファイルを開いたときに補完が出ることです。

さらに、エディタ下部にエラー一覧が出るようになれば、解析が動いていると判断できます。

最小で効く設定（保存時整形/フォーマット等）

最小で効く設定は、保存時に自動整形が走るようにして、コードの見た目で悩む時間を減らすことです。

設定画面で「Format On Save」を有効にし、C#のフォーマッタが動くことを確認します。

プロジェクトが大きくなるまで細かなテーマ変更や拡張の盛り込みはしません。

まずは「書く→保存→整う」が成立すれば、学習のストレスが目に見えて減ります。

設定を変えたら、必ず一度C#ファイルを保存して挙動が変わったかを確認します。

設定は増やすより、増やさない決断の方が効きます。

補完やフォーマットが不安定なら、設定を増やす前に再起動と拡張の状態確認に戻ります。

STEP3：プロジェクトを作る（箱を作る）

SDKと拡張が揃ったら、最小のConsoleプロジェクトで成功体験を作ります。

ここで一度成功しておくと、以降の応用は「テンプレート変更」だけで進めやすくなります。

ここでの判断は「最小の例で一周する」に固定します。

最初から複雑な構成にすると、エラー原因が増えるので避けます。

作業フォルダの決め方（後から迷わない）

作業フォルダは、短い英数字のパスにして、同期ツール配下や日本語パスは避けるとトラブルが減ります。

例としては、WindowsならC:\work、Macなら~/workのような場所が扱いやすいです。

OneDriveやiCloud配下は自動同期でファイルロックが起きることがあるので、最初は避けます。

フォルダ名は後でコマンドを打ちやすいように、スペースを含めない方が無難です。

迷ったらwork直下に作ると、ほぼ困りません。

将来複数プロジェクトを作るなら、work配下にproject名で並べると管理しやすいです。

最短作成（dotnet new console）

ターミナルで作業フォルダに移動し、dotnet new console -n HelloCSharpのように実行してプロジェクトを作ります。

続けてcd HelloCSharpで移動し、dotnet runで一度動くかを確認します。

この時点で動けば、SDKは正しく入っているので次はVSCode側の確認に進めます。

dotnet runが通らない場合は、まずSTEP1に戻ってSDKの確認をやり直します。

初回はビルドに少し時間がかかることがあるので、エラーと待ち時間を混同しないようにします。

実行結果が出たら、その出力を一度コピペしてメモしておくと安心です。

ここで動いた事実があると、以降の問題はVSCode側に絞りやすくなります。

VSCodeで開く＆信頼設定

VSCodeでフォルダを開くときは、プロジェクトフォルダ直下を開くと拡張が認識しやすいです。

初回に「このフォルダの作成者を信頼しますか」と出たら、信頼して機能制限を解除します。

信頼しないままだとデバッグ機能が制限されることがあります。

ワークスペースを開いたら、下部ステータスバーにC#関連の解析が走っているかを確認します。

解析が終わる前に操作すると補完が不安定になるので、初回だけ少し待つのがコツです。

補完が出ないときは、まず解析が終わっているかを疑います。

信頼設定で迷ったら、学習用のローカルフォルダは信頼してしまう方が手戻りが少ないです。

用語の最小理解（ソリューション/プロジェクト）

プロジェクトは実行単位の箱で、ソリューションは複数プロジェクトをまとめる入れ物です。

最初はプロジェクトだけで十分なので、ソリューションは必要になったら導入します。

Consoleアプリはプロジェクト単体で完結しやすいので、学習の入口に向いています。

複数プロジェクトを扱う場面が出たら、そのときにソリューションを作れば間に合います。

用語は「今はそういう箱がある」程度で十分です。

言葉で迷ったら、まずは作って動かす方に戻ります。

STEP4：実行・デバッグ・テスト

ここでは、動かすだけでなく、止めて中身を確認する流れまでを完成させます。

「動く」と「理解できる」は違うので、止めて覗けるようにして理解を加速させます。

ここを通すと、学習速度が一段上がります。

動いたまま放置せず、止めて確認することで「何が起きたか」を自分の言葉で説明できるようになります。

実行（dotnet run）

実行はプロジェクトフォルダでdotnet runを打つのが最短です。

VSCodeのターミナルから実行しても同じ結果になることを確認します。

ターミナル出力にエラーが出たら、上から順に最初の原因を見つける意識で読みます。

実行の入口をdotnetコマンドに固定すると、ツールが変わっても応用できます。

実行が安定すると、次はデバッグに集中できます。

エラーが出たら、まずは「何を実行したか」と「どのフォルダで実行したか」を確認します。

最短デバッグ（ブレークポイント→F5→変数確認）

Program.csにブレークポイントを置き、F5でデバッグを開始します。

止まったらウォッチや変数ビューで値が見えることを確認します。

デバッグ構成が聞かれた場合は「.NET」を選ぶのが基本です。

最初はステップ実行で流れを追い、処理の順番が見えることを体験します。

うまく起動しない場合は、まず「実行はできるか」を確認してからデバッグ設定を疑います。

止められたら、次は変数の値が見えることだけ確認すれば十分です。

デバッグが成功したら、今後は「止めたい場所にブレークポイント」を置く習慣がつきます。

最小テスト（作成→実行→失敗を見る）

テストはdotnet new xunitで別プロジェクトを作り、dotnet testで動くところまでを最小として押さえます。

最初はわざと失敗するテストを書き、失敗が検出できることを確認します。

テストの設計やモックは次の学習ステップに回します。

テストが回ると「壊れたかどうか」が即わかるので、学習の手戻りが減ります。

最初は1つのテストだけで十分なので、量よりも実行の流れを覚えます。

テストが通る状態を作ることが、次の開発にもそのまま効きます。

余裕があれば、テストの実行結果がコンソールに出ることを確認し、成功と失敗の差を体感します。

STEP5：動かないときのチェックリスト（最短復旧）

動かないときは勘でいじらず、症状から順に確認して最短で復旧します。

以下は「症状→確認→対処」の順で見ればよいチェックリストです。

この章は、時間がないときほど上から順に機械的に進めるのがコツです。

最短復旧の考え方は「戻して確認して前に進む」です。

原因を当てに行くより、確認結果で範囲を狭める方が早いです。

dotnetが見つからない／バージョン違い

症状は「dotnetが認識されない」または「SDKが見つからない」などの表示です。

確認はターミナルでdotnet –versionとdotnet –infoを実行して出力が出るかを見ることです。

対処はVSCodeとターミナルを再起動し、それでもだめならPC再起動と再インストールを行います。

別のSDKが複数入っている場合は、想定したSDKが選ばれているかを–infoで確認します。

ここが直れば、以降の問題も半分は解決します。

さらに、実行しているターミナルが「どのシェルか」も確認すると、環境差の切り分けが速いです。

補完が出ない／拡張が効かない

症状はコード補完が出ない、エラー表示が更新されない、デバッグが開始できないなどです。

確認は拡張の一覧でC#系拡張が有効で、かつ更新が保留になっていないかを見ることです。

対処はVSCode再起動と拡張の再インストールで、まず一度初期状態に戻します。

プロジェクト解析が終わっていないだけの場合もあるので、初回は少し待ってから判断します。

拡張の問題は、再起動と再インストールで直ることが多いです。

それでも直らない場合は、一度別の新規Consoleプロジェクトを作って同じ症状か確認します。

実行できない／ビルドエラー

症状はdotnet runでビルドエラーが出る、または実行時例外で落ちることです。

確認はエラーの先頭行と最初のファイル名を見て、どこで止まっているかを特定することです。

対処はbinとobjを消してdotnet buildをやり直し、再現性のある状態に戻します。

変更点が多いときは、直近に触ったファイルから順に戻すと原因が見つかりやすいです。

エラーを読む順番を固定すると、焦って試行錯誤する時間が減ります。

同じエラーが繰り返し出るなら、作業フォルダとコマンドの実行場所が一致しているかを確認します。

STEP6：なぜこの方法が最短なのか（補足）

最後に、今回の順番がなぜ再現性が高いのかを整理して、次に応用できる形にします。

最短のコツは「原因の数を増やさない」ことで、順番はそのための道具です。

「動かない原因」を一個ずつ潰せる順番にしているのがポイントです。

道具が増えるほど原因も増えるので、最初は道具を増やさない判断が重要です。

最小構成で成功→必要に応じて拡張

最初に最小構成で成功させると、追加した要素が原因かどうかを一つずつ切り分けられます。

便利そうな拡張を最初から盛ると、原因が増えて調査時間が伸びます。

最初に通すべき成功は「dotnet run」と「F5」で、これが通れば前に進めます。

拡張は後から足しても困らないので、最初は必要最小限で十分です。

この考え方は、WebやAPIに進んだあともそのまま使えます。

慣れてきたら、ログ出力やフォーマットルールを追加してもよいですが、まずは成功を優先します。

公式ツールチェーンに寄せるメリット

dotnetコマンド中心にすると、VSCode以外の環境でも同じ手順を再現できます。

公式の流れに寄せるほど、将来のSDK更新やPC乗り換えでも手戻りが減ります。

また、検索で出てくる解決策が公式手順と一致しやすく、検証が速くなります。

環境差が出たときも、公式コマンドの出力を共有すると会話が早いです。

公式に寄せることは、初心者ほど強い保険になります。

ツールが変わっても「dotnetで動く」基準が残るので、学習の資産になります。

STEP7：次にやること（学習ロードマップ）

環境ができたら、題材を少しずつ広げて実装量を増やすのが最短の上達ルートです。

次の一歩が決まっていると、環境構築で燃え尽きずに学習を続けられます。

続けるためには「次に何を作るか」を決めておくのが効果的です。

環境構築だけで満足しないように、翌日に作る小さな題材を一つ決めます。

コンソール→Web/API→GUIの順

順番はコンソールで基礎、次にWebやAPIで実用、最後にGUIで見た目という流れが学びやすいです。

最初にUIから入ると設定要素が増えて理解が分散します。

Web APIに進むときも、まずはテンプレートを作ってdotnet runが通るかを最初に確認します。

GUIは依存が増えやすいので、基礎が固まってから挑戦すると挫折しにくいです。

学習は「小さく作って動かす」を繰り返すのが一番速いです。

最初のうちは、毎回「実行できた」を積み重ねる方が伸びます。

公式ドキュメントの探し方

困ったら「dotnet コマンド名 公式」や「C# 機能名 docs」で検索して一次情報に当たります。

情報が古いときは、SDKのバージョンと記事の日付を合わせて読みます。

検索するときは「エラーメッセージの一部」と「SDKバージョン」をセットにすると近い答えに当たりやすいです。

社内環境の制約がある場合は、同じ制約の事例を探す方が近道です。

一次情報を読む癖がつくと、今後の学習が一気に楽になります。

困ったときのメモを残すと、次回同じ問題に当たったときに数分で解決できます。