C#開発環境の準備2026:.NET 10 SDKとdotnet CLIで始める
Visual Studio 2019のインストール記事を2026年版に刷新。.NET 10 SDKの導入、dotnet new console、トップレベルステートメント、エディター選び(VS 2026・VS Code・Rider)を実際の出力で確認します。
2026年11月全面改訂: このアドレスには、もともと2021年に韓国語で書いた「Visual Studio 2019 のインストール」記事がありました。Visual Studio 2019 は2024年4月にメインストリームサポートが終わり(延長サポートは2029年4月まで)、いま C# を始めるならインストーラーの画面より .NET SDK と
dotnetコマンドを知っておくほうがずっと役に立ちます。そこで URL はそのままに、内容を .NET 10 前提の「C# 開発環境の準備」に書き換えました。以下のコマンドと出力は、すべて Apple Silicon Mac で実際に実行したものです。2019年当時のスクリーンショット13枚はすべて削除しました。
C#をこれから始める人と、昔 Visual Studio で C# を覚えたけれど Mac や Linux でもう一度始めたい人向けの記事です。先に結論を書くと、C# 開発にどうしても必要なのは .NET 10 SDK だけです。SDK があれば dotnet new console と dotnet run の2行で最初のプログラムが動きます。エディターはそのあとで、OS と好みに合わせて選べば大丈夫です。
2021年版から変わったこと
2021年版は、Visual Studio 2019 のインストーラーを1画面ずつ追い、「C++ によるデスクトップ開発」ワークロードを選んでサインインするまでの流れが中心でした。5年たって前提がいくつも変わっています。
- C# は Windows 専用ではありません。 2021年版は C# を「.NET Framework に最適化された言語」と紹介していましたが、いまの主役は Windows・macOS・Linux のどれでも動く .NET(現行は .NET 10)です。.NET Framework 4.8.x は既存の Windows アプリの保守用に残っています。
- 「C++ がベース」という説明も正確ではありません。 C# は C 系の文法を借りていますが、C++ の上に作られた言語ではありません。オブジェクト指向という説明は正しく、いまはラムダ式・ジェネリック・パターンマッチングもよく使います。
- IDE なしで始められます。
dotnetコマンドライン(CLI)がプロジェクトの作成・ビルド・実行・パッケージ管理をすべて受け持ちます。Visual Studio も内部では同じ SDK と MSBuild を使っています。 - 元記事のダウンロードリンクには第三者の追跡用パラメーターが付いていたので外しました。SDK は Microsoft 公式の .NET ダウンロードページから入手してください。
削除した画像は、インストーラーと IDE の画面12枚と、ダウンロードページのキャプチャ1枚です。ダウンロードページのキャプチャには、Microsoft の宣伝画像に写った他人のユーザーフォルダーのパス(C:\Users\…)が見えており、IDE の初回起動画面にはサインインしたアカウントのプロフィールアイコンが写っていました。残りもバージョン16.0当時の画面で、いまインストールする人の画面とは合いません。
.NET 10 SDK のインストール(Windows・macOS・Linux)
ランタイムではなく SDK を入れます。ランタイムだけではプログラムを動かせても、ビルドはできません。
| OS | 方法 |
|---|---|
| Windows | 公式インストーラー、または winget install Microsoft.DotNet.SDK.10 |
| macOS | 公式 .pkg インストーラー(入る場所は /usr/local/share/dotnet)、または Homebrew の brew install dotnet |
| Linux | ディストリビューションのパッケージ(Ubuntu などは dotnet-sdk-10.0)、または公式の dotnet-install.sh --channel 10.0 |
Linux はディストリビューションとバージョンによってパッケージの提供状況が違うので、Microsoft Learn の「Linux に .NET をインストールする」ページで自分の環境の項目を確認するのが確実です。
インストールしたら新しいターミナルで確認します。この記事を書いた Mac(Homebrew で導入)での実際の出力を短くしたものです。日本語環境では一部の見出しが日本語になります。
$ dotnet --info
.NET SDK:
Version: 10.0.403
Commit: 5a2162bea6
Workload version: 10.0.400-manifests.a00bebb6
MSBuild version: 18.9.15+5a2162bea
ランタイム環境:
OS Name: Mac OS X
OS Version: 26.6
OS Platform: Darwin
RID: osx-arm64
Base Path: /opt/homebrew/Cellar/dotnet/10.0.403/libexec/sdk/10.0.403/
…
Host:
Version: 10.0.14
Architecture: arm64
…
.NET SDKs installed:
10.0.403 [/opt/homebrew/Cellar/dotnet/10.0.403/libexec/sdk]
見るところは3つです。.NET SDK: Version が 10.0.x か、RID が自分の CPU に合っているか(Apple Silicon なら osx-arm64、Intel Mac なら osx-x64)、.NET SDKs installed に想定外のバージョンが混ざっていないか。バージョンだけなら dotnet --version(ここでは 10.0.403)で足ります。
dotnet new console と dotnet run
プロジェクトを置くフォルダーで次を実行します。
$ dotnet new console -o HelloCs
テンプレート "コンソール アプリ" が正常に作成されました。
作成後の操作を処理しています...
HelloCs/HelloCs.csproj を復元しています:
復元対象のプロジェクトを決定しています...
HelloCs/HelloCs.csproj を復元しました (39 ミリ秒)。
正常に復元されました。
CLI のメッセージは OS の言語に合わせて出ます。DOTNET_CLI_UI_LANGUAGE=en を付けると英語になり、エラーを検索するときは英語のほうが情報を見つけやすいです。
できるファイルは2つだけです。HelloCs.csproj の中身はこうです。
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net10.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
</Project>
ImplicitUsings は using System; などよく使う using を自動で入れ、Nullable は null になりうる参照をコンパイラーに警告させます。古い講座のコードがこのテンプレートで警告を出すのはこの設定のためで、実例は break・continue・goto の記事にあります。
$ cd HelloCs
$ dotnet run
Hello, World!
dotnet run は復元 → ビルド → 実行を一度に行います。この Mac で time を付けて測ると、dotnet new console が1.5秒、最初の dotnet run が2.0秒、2回目の dotnet run が1.5秒でした。出力は bin/Debug/net10.0/ に入り、最初の実行後のサイズは bin が152KB、obj が256KB でした。
.NET 10 では、プロジェクトなしで ファイル1つだけを実行することもできます。hello.cs に Console.WriteLine($"file-based app on .NET {Environment.Version}"); の1行だけを書いて dotnet run hello.cs とすると、file-based app on .NET 10.0.14 と表示されました。ちょっとした実験にはこれが手軽です。
トップレベルステートメントと、古い講座のコード
テンプレートが作る Program.cs は Console.WriteLine("Hello, World!"); の1行です。namespace も class Program も static void Main もありません。これが C# 9 で入ったトップレベルステートメントで、見えない Program クラスと Main メソッドはコンパイラーが用意します。それでも args は使え、return で終了コードも返せます。
// トップレベルステートメント:このファイルがエントリポイント
string name = args.Length > 0 ? args[0] : "world";
Console.WriteLine($"Hello, {name}!");
Console.WriteLine($".NET {Environment.Version}, {System.Runtime.InteropServices.RuntimeInformation.OSDescription}");
return name.Length; // 終了コード
$ dotnet run -- dotnet
Hello, dotnet!
.NET 10.0.14, macOS 26.6.2
$ echo $?
6
-- のあとの値はプログラムの args に渡り、return した値が終了コード6になりました。
古い講座のように namespace ConsoleApplication1 { class Program { static void Main(string[] args) … } } と書いたコードも、Program.cs にそのまま貼れば警告なしでビルドでき、動きます(韓国語の文字列を出力させても問題ありませんでした)。新しいプロジェクトを昔の形で作りたいなら、dotnet new console --use-program-main で namespace HelloCs; class Program { static void Main(string[] args) … } の形が生成されます。
つまずきやすいのは、2つの書き方を混ぜたときです。実際に出たメッセージです。
| 状況 | 結果 |
|---|---|
| トップレベルステートメントのファイルが2つ | error CS8802: Only one compilation unit can have top-level statements. |
トップレベル + 同じファイルに class Program |
error CS0260: Missing partial modifier on declaration of type 'Program'; another partial declaration of this type exists |
トップレベル + 別クラスの static void Main |
warning CS7022: The entry point of the program is global code; ignoring 'App.Main()' entry point. |
CS0260 は、コンパイラーが生成する Program を partial として宣言するために出ます。厄介なのは CS7022 で、警告だけで済むうえに自分で書いた Main は黙って無視され、トップレベルのコードだけが実行されます。講座の例を1つずつ試すときは、例ごとにプロジェクトを作るか、Program.cs の中身を丸ごと置き換えるのが安全です。
エディター選び:Visual Studio 2026、VS Code、Rider
中で使う SDK は同じです。エディターで変わるのはデバッグとリファクタリングの使い勝手で、コンパイル結果ではありません。
| エディター | OS | 向いている場面 | メモ |
|---|---|---|---|
| Visual Studio 2026 | Windows | WinForms・WPF などの Windows デスクトップ、大きなソリューション | Community エディションは個人・小規模チームなら無料 |
| Visual Studio 2022 | Windows | .NET 9 以前を対象にした既存プロジェクト | 17.14 は net10.0 を対象にできない(NETSDK1233) |
| VS Code + C# Dev Kit | Windows・macOS・Linux | 軽いエディター、複数の言語を一緒に扱うとき | C# Dev Kit は Visual Studio と同じライセンス条件 |
| JetBrains Rider | Windows・macOS・Linux | IntelliJ 系の IDE に慣れている | 非商用利用は無料 |
気をつけたいのは Visual Studio 2022 と .NET 10 の組み合わせです。Microsoft Learn の SDK・MSBuild・Visual Studio のバージョン対応のページによると、net10.0 を対象にするには Visual Studio 2026(18.0)以降が必要で、Visual Studio 2022 17.14 は .NET 10 SDK を読み込めても .NET 9 以前しか対象にできません。上の dotnet --info で MSBuild が 18.x なのも、Visual Studio 2026 と同じ世代だからです。Visual Studio for Mac は2024年8月にサポートが終わったので、Mac では VS Code か Rider を使います。
2021年版の中心だった C/C++ の開発が目的なら、Windows の Visual Studio で「C++ によるデスクトップ開発」ワークロードを選ぶ手順はいまも同じです。C# だけを学ぶならこのワークロードは要りません。
macOS でハマった点:Homebrew 版と DOTNET_ROOT
この記事の Mac は Homebrew で .NET を入れていました。dotnet run は問題なく動くのに、ビルドした実行ファイルを直接起動すると次のように失敗しました。
$ ./bin/Release/net10.0/spin
You must install .NET to run this application.
App: …/bin/Release/net10.0/spin
Architecture: arm64
App host version: 10.0.14
.NET location: Not found
…
Default location:
/usr/local/share/dotnet
実行ファイル(アプリホスト)は、環境変数 DOTNET_ROOT、次に既定の場所 /usr/local/share/dotnet で .NET を探します。Homebrew 版は /opt/homebrew/Cellar/dotnet/…/libexec にあるので見つからなかったわけです。dotnet tool で入れたツール(今回は ilspycmd)も同じメッセージで起動しませんでした。対処はこれだけです。
$ export DOTNET_ROOT="$(brew --prefix dotnet)/libexec"
設定後は、実行ファイルもツールも普通に動きました。毎回打たなくて済むよう、シェルの設定ファイル(~/.zshrc など)に書いておきます。この違い自体を避けたいなら、最初から Microsoft 公式の .pkg インストーラーを使うのがいちばん簡単です。
環境が整ったら、C#の配列、メソッドの順に進んでみてください。どの例も、この記事と同じ dotnet new console のプロジェクトで確認し直しています。
検証環境:.NET SDK 10.0.403 / ランタイム 10.0.14(Homebrew)、C# 14、macOS 26.6.2、Apple Silicon Mac(M1 Pro)。
よくある質問
C#を始めるのにVisual Studioは必須?
必須ではありません。必要なのは .NET SDK だけです。SDK を入れれば dotnet new console でプロジェクトを作り、dotnet run でビルドと実行までできます。エディターは、Windows なら Visual Studio 2026、macOS・Linux なら VS Code + C# Dev Kit か Rider を、あとから選べば十分です。
Visual Studio 2022で.NET 10のプロジェクトは扱える?
Microsoft Learn の SDK・MSBuild・Visual Studio のバージョン対応のページによると、net10.0 を対象にするには Visual Studio 2026(18.0)以降が必要です。Visual Studio 2022 17.14 は .NET 10 SDK があっても .NET 9 以前しか対象にできず、net10.0 を指定すると警告 NETSDK1233 が出ます。
macOSでビルドした実行ファイルが「You must install .NET」で動かない
Homebrew で入れた .NET では、dotnet run は動いても、bin の実行ファイルを直接起動すると .NET の場所が見つからずこのメッセージになります。既定の /usr/local/share/dotnet にないためです。export DOTNET_ROOT="$(brew --prefix dotnet)/libexec" をシェルの設定に書くか、Microsoft 公式のインストーラーを使えば解決します。