VS Codeで「System.Windows.Formsが見つからない」CS0234の原因と解決策：WinFormsを動かす正しいプロジェクト設定

VS CodeでC#を書いていて、フォームアプリを作ろうとして using System.Windows.Forms を追加したのに、CS0234: System.Windows に Forms が存在しない と怒られる。これは「usingの書き方が違う」のではなく、プロジェクト側がWinFormsを参照できる状態になっていないことが原因です。
この記事では、なぜこのエラーが起きるのか、そして.NETの世代ごとに最短で直す手順をまとめます。

VS Codeで「System.Windows.Formsが見つからない」CS0234の原因と解決策：WinFormsを動かす正しいプロジェクト設定

そもそもCS0234は「using不足」ではなく「参照不足」で起きる

using は「名前空間を短く書けるようにする」だけの宣言で、ライブラリ（アセンブリ）そのものを追加する機能はありません。
つまり System.Windows.Forms をコードに書いても、プロジェクトが System.Windows.Forms を参照していない、もしくは 参照できないターゲット になっていれば、存在しない扱いになってCS0234になります。

この状況が特に起きやすいのが、VS Codeで「とりあえず console テンプレートで作ったプロジェクト」にWinFormsのコードを混ぜたケースです。

重要：WinFormsは“どの環境でも動く”わけではない

WinForms（System.Windows.Forms）は基本的に Windows向けのUIフレームワーク です。
そのため、次のどれかに当てはまると、設定が合っていない可能性が高いです。

dotnet new console で作ったプロジェクトにフォームを足した
.csproj の TargetFramework が net6.0 や net7.0 のまま（-windows が付いていない）
Windows以外のOSでビルド/実行しようとしている
.NET Framework時代の手順と、.NET 5以降の手順が混ざっている

以降は、あなたのプロジェクトが .NET 5以降（.NET 6/7/8など） か、.NET Framework かで対処が変わります。

解決策1：.NET 5以降（.NET 6/7/8など）でWinFormsを使う正しい設定

.NET 5以降のSDKスタイルプロジェクトでは、WinFormsを有効化するために .csproj に明示設定が必要です。ポイントは2つだけです。

TargetFramework を netX.Y-windows にする
UseWindowsForms を true にする

例（.NET 8想定）：

XML

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>net8.0-windows</TargetFramework>
<UseWindowsForms>true</UseWindowsForms>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
</PropertyGroup>

</Project>

よくある落とし穴

TargetFramework が net8.0 のままだと、WinFormsの参照が前提に含まれず System.Windows.Forms が見つからない扱いになりやすいです。
OutputType を Exe のままにしても動く場合はありますが、フォームアプリとしては WinExe の方が意図に合います（コンソールを出したくない場合）。
Windows以外のOSでは実行できません。ビルド自体も環境や設定によって制約が出ます。

すでにあるプロジェクトを最短で直す手順

.csproj を開く
TargetFramework を netX.Y-windows に変更
<UseWindowsForms>true</UseWindowsForms> を追加
ターミナルで dotnet clean → dotnet build
まだ赤線が消えない場合は、VS CodeのC#拡張機能（言語サーバー）を再読み込み

解決策2：最初からWinFormsテンプレートで作り直す（いちばん確実）

WinFormsをやりたいなら、最初からテンプレートで作るのが事故りません。VS CodeでもCLIで作れます。

Bash

dotnet new winforms -n MyWinFormsApp
cd MyWinFormsApp
dotnet run

これで .csproj は最初からWinForms前提になり、using System.Windows.Forms; も正しく解決されます。
「consoleプロジェクトに後からフォームを足す」より、まずテンプレートで土台を作ってからコードを移すのが安全です。

解決策3：.NET Frameworkを使っている場合の考え方（参照の追加が必要）

.NET Framework（古い世代）では、プロジェクトが参照するアセンブリを明示的に追加する文化が強く、System.Windows.Forms 参照が入っていないと同じエラーになります。
ただし、VS Codeは.NET FrameworkのWinForms開発において、Visual Studioほど統合された体験にはなりにくいのが現実です。

.NET FrameworkでWinFormsを本格的にやるなら、Visual Studio（Communityでも可）の方が圧倒的に手早い
どうしてもVS Codeでやるなら、プロジェクト構成や参照の扱いを自分で管理する必要が出やすい

「VS CodeでWinFormsを作りたい」という条件があるなら、基本は .NET 6/7/8の netX.Y-windows + UseWindowsForms に寄せるのが無難です。

「Solution Explorerにusingを追加すれば直る」は誤解

たまに見かける「Solution Explorerで何かを追加して直す」系の話は、using の追加ではなく 参照（Reference）やプロジェクト設定 を整える手順を指していることが多いです。
今回のCS0234はまさにそれで、赤線の原因はコードの1行ではなく、プロジェクトがWinFormsを見に行けない状態にある点です。

まとめ：直すために見るべきはコードではなく.csproj

using System.Windows.Forms; がエラーになるときは、ほぼ確実に次のどれかです。

WinForms用プロジェクトではない（consoleなど）
TargetFramework が -windows になっていない
UseWindowsForms が有効化されていない
Windows以外の環境で実行しようとしている
.NET Frameworkと.NET 5以降の手順が混ざっている

最短ルートは、dotnet new winforms でプロジェクトを作り、必要ならコードを移植すること。既存プロジェクトを直すなら、.csproj に netX.Y-windows と UseWindowsForms を入れる。
これだけで、CS0234は「usingを書いても見つからない」状態から抜け出せます。