MENU

.NETのForm Class更新ポイント：System.Windows.Formsの影響範囲と移行確認を実務向けに解説

C#

.NET の Form Class (System.Windows.Forms) は、WinForms アプリの画面そのもの、つまりウィンドウやダイアログボックスを表す中核クラスです。2026年7月1日に公開または更新された公式情報を確認するうえで重要なのは、「Form の基本概念が変わった」のではなく、.NET 10 世代の WinForms 機能、非推奨 API、サポート期限を踏まえて、既存アプリの影響範囲を棚卸しすることです。Form は System.Windows.Forms 名前空間、System.Windows.Forms.dll に含まれ、アプリケーション UI を構成するウィンドウまたはダイアログボックスを表します。(Microsoft Learn)

特に管理者や開発リーダーが確認すべきポイントは、FormScreenCaptureMode による画面キャプチャ抑止、ShowAsync / ShowDialogAsync の非同期フォーム表示、OnClosing / OnClosed などの非推奨警告、そして .NET 8 / .NET 9 / .NET 10 のサポート期限です。すぐに全アプリを書き換える必要があるとは限りませんが、グローバル展開している業務アプリでは、対象 OS、配布方式、サードパーティ製 WinForms コントロール、セキュリティ要件をまとめて確認する必要があります。

目次

.NET の「Form Class (System.Windows.Forms)」で確認すべきポイント

Form クラスは、WinForms アプリにおける「画面の土台」です。ログイン画面、検索画面、設定ダイアログ、管理者向けツールのメインウィンドウなど、多くの Windows デスクトップアプリで直接または間接的に使われています。

Microsoft Learn の公式リファレンスでは、Form は ContainerControl を継承するクラスとして定義され、標準ウィンドウ、ツールウィンドウ、境界線なしウィンドウ、フローティングウィンドウ、モーダルダイアログ、MDI 親フォームなどを作成できると説明されています。(Microsoft Learn)

実務上は、次のように理解すると分かりやすいです。

観点Form が担う役割実務での確認ポイント
画面表示メイン画面や入力画面を表示するShow、ShowDialog、Application.Run の使い方
ダイアログOK / キャンセル付きのモーダル画面を作るAcceptButton、CancelButton、DialogResult の設計
ウィンドウ制御サイズ、位置、最大化、最小化、境界線を制御するFormBorderStyle、StartPosition、WindowState の確認
入力・イベントフォームの表示、終了、アクティブ化に反応するLoad、Shown、FormClosing、FormClosed の整理
セキュリティ機密画面のキャプチャ抑止を検討できるFormScreenCaptureMode の適用対象を選定

ここで注意したいのは、Form クラスの更新情報を「新機能一覧」として眺めるだけでは不十分という点です。WinForms アプリでは、画面そのものが業務フロー、入力検証、印刷、ファイル操作、認証情報の表示と密接に結びついています。そのため、API の追加や非推奨警告は、単なるコード修正ではなく、運用・セキュリティ・配布方式まで含めて確認する必要があります。

影響範囲：どのアプリが確認対象になるか

今回の確認対象になるのは、主に System.Windows.Forms.Form を使っている Windows デスクトップアプリです。WinForms は Windows 向けのデスクトップ UI フレームワークであり、.NET 版の Windows デスクトップアプリも引き続き Windows 専用です。(Microsoft Learn)

影響を受けやすいのは、次のようなアプリです。

対象影響の見方
.NET 10 に移行予定の WinForms アプリ新 API、非推奨警告、表示挙動の変化を確認する
.NET 8 / .NET 9 で稼働中の WinForms アプリサポート期限と次期移行先を確認する
.NET Framework から .NET へ移行中のアプリSDK スタイルのプロジェクト、API 差分、古いコントロールの利用を確認する
WPF と WinForms を併用するアプリContextMenu や MenuItem などの名前衝突を確認する
機密情報を表示する業務アプリキャプチャ抑止機能を使うべき画面を洗い出す
グローバル展開アプリOS バージョン、言語、IME、DPI、アクセシビリティの差を確認する

逆に、ASP.NET Core だけの Web アプリ、コンソールアプリ、WPF のみのアプリ、.NET MAUI アプリは、Form クラスそのものの影響は基本的に受けません。ただし、同じソリューション内に WinForms の管理ツールや社内ユーティリティが含まれている場合は見落としやすいため、リポジトリ単位ではなくアプリ単位で棚卸しするのが安全です。

更新ポイント：FormScreenCaptureMode で機密画面のキャプチャ対策を検討する

.NET 10 の WinForms では、画面キャプチャアプリケーションがフォームをキャプチャできないようにするための ScreenCaptureMode API が導入されています。これは、ユーザー名、ユーザー ID、パスワードなどの機密情報の漏えいリスクを下げる目的で使える機能です。(Microsoft Learn)

API リファレンス上は、Form に FormScreenCaptureMode プロパティがあり、値として ScreenCaptureMode を指定します。ScreenCaptureMode には Allow、HideContent、HideWindow の値があります。(Microsoft Learn)

値動作向いている画面
Allow既定値。フォームのキャプチャを許可する通常の一覧画面、公開情報の表示画面
HideContentキャプチャ時にフォーム内容を隠すパスワード、個人情報、認証コードの表示画面
HideWindowキャプチャ時にフォーム自体を隠す動作を狙う強い秘匿性が必要な管理者画面

実装例は次のとおりです。

public partial class LoginForm : Form
{
    public LoginForm()
    {
        InitializeComponent();

        // 認証情報を扱うフォームでは、キャプチャ時に内容を隠す
        FormScreenCaptureMode = ScreenCaptureMode.HideContent;
    }
}

ただし、この機能を「情報漏えいを完全に防ぐ仕組み」と考えるのは危険です。基盤となる Windows API の SetWindowDisplayAffinity は、トップレベルウィンドウに対する表示制御であり、OS の公開 API を使ったキャプチャに対する保護を目的としています。Microsoft の Win32 ドキュメントでも、写真撮影のような手段まで厳密に防ぐ DRM や完全なセキュリティ機能ではないと説明されています。(Microsoft Learn)

実務では、次の基準で適用対象を決めると失敗しにくくなります。

判断項目推奨
パスワード、トークン、個人番号、顧客情報を表示するHideContent 以上を検討する
画面共有を前提にしたサポート業務で使う適用するとサポート不能になる可能性があるため要検証
メッセージボックスやコンテキストメニューに機密情報が出るフォーム本体だけでなく派生表示も確認する
Windows 10 の古いバージョンが残っているHideWindow の動作差を検証する
監査要件が厳しい業務キャプチャ抑止だけでなくログ、権限、マスキングも併用する

非同期フォーム表示：ShowAsync と ShowDialogAsync の使いどころ

Form クラスの公式リファレンスには、従来の Show、ShowDialog に加えて、ShowAsync(IWin32Window)、ShowDialogAsync()、ShowDialogAsync(IWin32Window) が掲載されています。これらはフォームやダイアログを非同期に表示するための API です。(Microsoft Learn)

.NET 10 の WinForms では、非同期フォームのサポートが統合され、.NET 9 で必要だったプレビュー扱いの抑制が不要になったと説明されています。(Microsoft Learn)

使いどころは、単に「新しい API だから置き換える」ではありません。次のような場面で効果があります。

使う場面理由
複数ウィンドウを同時に扱う管理ツールウィンドウ終了を Task として扱いやすい
ダイアログ後に非同期処理を続けたいawait で処理順を読みやすくできる
UI 応答性を保ちたい同期的な待ち合わせを減らせる
既存の ShowDialog で十分な単純画面無理に置き換えなくてもよい

例として、設定画面を非同期ダイアログとして開く場合は次のように書けます。

private async void buttonSettings_Click(object sender, EventArgs e)
{
    using var dialog = new SettingsForm();

    DialogResult result = await dialog.ShowDialogAsync(this);

    if (result == DialogResult.OK)
    {
        SaveSettings();
    }
}

注意点として、非同期 API を使っても、重い初期化処理をフォームのコンストラクターや Load イベントに詰め込んだままでは、UI が固まる原因は残ります。DB 接続、外部 API 呼び出し、大量ファイル読み込みは、フォーム表示処理とは分離し、キャンセルやエラー表示まで含めて設計するのが実務向けです。

非推奨 API：OnClosing / OnClosed から FormClosing / FormClosed へ寄せる

.NET 10 では、一部の Windows Forms API が非推奨として扱われ、ビルド時にカスタム診断 ID 付きの警告が出るようになっています。Form に直接関係するものとして、Form.OnClosing(CancelEventArgs)、Form.OnClosed(EventArgs)、対応するイベントが WFDEV004 の警告対象です。推奨される代替は、OnFormClosing(FormClosingEventArgs)、OnFormClosed(FormClosedEventArgs)、FormClosing、FormClosed です。(Microsoft Learn)

古いコードでは、次のような実装が残っていることがあります。

protected override void OnClosing(CancelEventArgs e)
{
    if (HasUnsavedChanges)
    {
        e.Cancel = true;
    }

    base.OnClosing(e);
}

.NET 10 以降を意識するなら、次のように OnFormClosing へ寄せるのが分かりやすい対応です。

protected override void OnFormClosing(FormClosingEventArgs e)
{
    if (HasUnsavedChanges)
    {
        DialogResult result = MessageBox.Show(
            "保存していない変更があります。終了しますか？",
            "確認",
            MessageBoxButtons.YesNo,
            MessageBoxIcon.Warning);

        if (result == DialogResult.No)
        {
            e.Cancel = true;
        }
    }

    base.OnFormClosing(e);
}

この変更は、単に警告を消すだけではありません。FormClosingEventArgs には終了理由を示す CloseReason が含まれるため、ユーザー操作、Windows シャットダウン、MDI 親フォームの終了などを分けて扱いやすくなります。業務アプリでは、「ユーザーが閉じた場合は確認するが、OS シャットダウン時は長時間ブロックしない」といった制御が必要になるため、終了処理の見直しは優先度が高い項目です。

古い WinForms コントロールと WPF 併用アプリの注意点

.NET 10 の Windows Forms 非推奨警告には、ContextMenu、DataGrid、MainMenu、Menu、StatusBar、ToolBar など、.NET Framework とのバイナリ互換性のために残されている古いコントロールも含まれます。これらは WFDEV006 の警告対象です。(Microsoft Learn)

また、WPF と WinForms の両方を参照するアプリでは、ContextMenu や MenuItem などの型名が曖昧になり、コンパイルエラーになる可能性があります。Microsoft は、名前空間のエイリアスを使って型を明示する対応を推奨しています。(Microsoft Learn)

実務では、次のように対応方針を分けると判断しやすくなります。

検出されたもの対応方針
MainMenu / ContextMenu / ToolBarMenuStrip、ContextMenuStrip、ToolStrip への置き換えを検討
DataGridDataGridView または別のグリッドコンポーネントへの移行を検討
WPF と WinForms の ContextMenu 衝突using WinFormsContextMenu = System.Windows.Forms.ContextMenu; のように明示
サードパーティ製コントロールが古い API に依存ベンダーの .NET 10 対応状況を確認
警告を一時的に抑制したいWFDEVxxx 単位で抑制し、期限付きの技術負債として管理

警告をすべて NoWarn でまとめて消すのは避けたほうがよいです。移行初期はビルドを通すために抑制が必要なこともありますが、診断 ID ごとに理由、対象ファイル、解消予定時期を記録しておくと、後から安全に整理できます。

設定変更：プロジェクトファイルで確認する項目

WinForms を .NET でビルドするには、Windows 固有のターゲットフレームワークを指定し、UseWindowsForms を true にします。Microsoft の MSBuild リファレンスでは、WinForms または WPF を使う場合、TargetFramework に net8.0-windows のような Windows 固有 TFM を指定し、UseWindowsForms を true にすることが説明されています。UseWindowsForms を true にすると、.NET Desktop SDK が自動的にインポートされます。(Microsoft Learn)

.NET 10 へ移行する場合の基本形は次のようになります。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net10.0-windows</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
</Project>

既存アプリでは、次の項目を確認してください。

確認項目見る場所判断基準
対象フレームワーク.csproj の TargetFrameworknet8.0-windows、net9.0-windows、net10.0-windows など
WinForms 有効化.csproj の UseWindowsFormstrue になっているか
配布形式発行設定、CI/CDFramework-dependent か Self-contained か
SDK バージョン固定global.json古い SDK に固定されていないか
高 DPIApplicationHighDpiModeマルチモニター環境で崩れないか
既定フォントApplicationDefaultFont.NET Framework からの移行で画面崩れがないか
Visual StylesApplicationVisualStyles既定値変更で見た目が変わらないか

グローバル企業では、開発者 PC とビルドエージェントで SDK のバージョンが違うことがよくあります。global.json で SDK を固定している場合は、ローカルでは通るが CI では失敗する、またはその逆が起きやすくなります。移行時は、開発 PC、CI、署名環境、配布用 VM の SDK とランタイムを同時に確認してください。

移行期限：Form 固有の期限ではなく .NET ライフサイクルで判断する

Form クラス単体に「この日までに移行しなければならない」という独立した期限が設定されているわけではありません。実際の期限は、アプリが対象にしている .NET ランタイム、SDK、Windows OS、サードパーティ製コンポーネントのサポート期限で決まります。

2026年7月時点で重要なのは、.NET 8 と .NET 9 のサポート終了が 2026年11月10日、.NET 10 のサポート終了が 2028年11月14日であることです。.NET 10 は LTS、.NET 9 は STS として扱われ、サポートを受けるにはリリース済みパッチを最新状態に保つ必要があります。(Microsoft)

利用中のバージョン状態実務上の判断
.NET 10LTS。2028年11月14日までサポート新規開発・中長期運用の本命候補
.NET 9STS。2026年11月10日までサポート早めに .NET 10 移行計画を作る
.NET 8LTS。2026年11月10日までサポート2026年内の移行計画が必要
.NET 6 / .NET 7サポート終了済み優先度高で移行
.NET Framework 4.8 / 4.8.1OS コンポーネントとしてのサポートが中心新機能は期待せず、必要に応じて .NET へ移行

配布方式による違いも重要です。Framework-dependent deployment のアプリは、Windows 上の .NET 更新の恩恵を受けやすい一方、Self-contained deployment のアプリは、アプリに同梱したランタイムを開発・運用側で更新する必要があります。Microsoft のサポートポリシーでも、Microsoft Update による自動パッチ適用と、Self-contained deployment ではアプリ側がランタイム更新に責任を持つ点が説明されています。(Microsoft)

管理者が確認すべきチェックリスト

Form Class の更新ポイントを実務に落とし込むには、コードの検索だけでなく、アプリ資産管理、配布、利用部門への影響確認まで含める必要があります。

確認項目確認内容優先度
アプリ棚卸しWinForms アプリ、管理ツール、社内配布 EXE を一覧化する高
対象 .NETTargetFramework と実行環境のランタイムを確認する高
配布方式Framework-dependent / Self-contained を判別する高
非推奨警告WFDEV004、WFDEV005、WFDEV006 をビルドログで確認する高
機密画面認証、個人情報、管理者画面に FormScreenCaptureMode が必要か判断する高
OS バージョンWindows 10 2004 未満が残っていないか確認する中
WPF 併用ContextMenu、MenuItem などの曖昧参照を確認する中
UI 差分ダークモード、高 DPI、フォント、StatusStrip の表示を確認する中
アクセシビリティスクリーンリーダー、キーボード操作、IME を確認する中
サードパーティ製品グリッド、帳票、バーコード、印刷系コンポーネントの .NET 10 対応を確認する高

特にグローバル環境では、英語 OS、日本語 OS、欧州言語 OS、右から左へ書く言語、複数 DPI のモニター、リモートデスクトップ、VDI、画面共有ツールが混在します。Form の表示やキャプチャ抑止は、開発者の PC だけで確認しても不十分です。少なくとも代表的な OS 言語、解像度、リモート接続方式、画面共有ツールを組み合わせたテストを用意してください。

開発チームが最初にやるべき実務手順

最初から大規模リライトを始める必要はありません。まずは、影響を可視化し、移行の優先順位を決めることが重要です。

手順作業内容成果物
1リポジトリ内で System.Windows.Forms、: Form、ShowDialog、OnClosing を検索影響フォーム一覧
2.csproj の TargetFramework と UseWindowsForms を確認対象 .NET 一覧
3.NET 10 SDK でビルドし、警告を保存警告一覧
4WFDEV004 などの警告を分類修正対象リスト
5機密情報を扱うフォームを抽出FormScreenCaptureMode 適用候補
6代表画面を Windows 10 / 11、複数 DPI、リモート環境で確認UI 差分レポート
7.NET 8 / 9 利用アプリの移行期限を決める移行ロードマップ

コード検索では、次のキーワードを使うと効率的です。

: Form
System.Windows.Forms.Form
ShowDialog(
ShowAsync(
ShowDialogAsync(
OnClosing(
OnClosed(
FormClosing
FormClosed
ContextMenu
MainMenu
DataGrid
StatusBar
ToolBar
Clipboard.GetData

この段階で重要なのは、「警告が出たからすぐ直す」ではなく、「どの警告が本番リスクにつながるか」を分類することです。たとえば OnClosing の置き換えは比較的進めやすい一方、古い DataGrid を使った複雑な画面は、レイアウトや入力操作の再テストが必要になります。

既存コードで失敗しやすいポイント

.NET の Form 更新対応では、次のような失敗がよく起きます。

警告だけを抑制して移行完了にしてしまう

WFDEV004 などの警告は、将来の保守性や移行性に関わります。すぐに直せない場合でも、警告 ID、対象ファイル、抑制理由、解消予定を管理してください。警告をまとめて消すと、後から本当に危険な変更を見つけにくくなります。

画面キャプチャ抑止を過信する

FormScreenCaptureMode は有用ですが、物理的な撮影や API を迂回するツールまで防げるものではありません。機密情報は、表示しない、マスクする、必要な権限のユーザーだけに見せる、操作ログを残す、といった対策と組み合わせるべきです。

Self-contained 配布のランタイム更新を忘れる

Self-contained deployment は、対象 PC に .NET ランタイムを入れなくても動かせる反面、アプリに含めたランタイムの更新責任が開発・運用側に残ります。脆弱性対応のたびに再発行・再配布が必要になるため、配布手順を自動化しておくことが重要です。

.NET Framework からの移行で画面崩れを軽視する

.NET Framework から .NET へ移行する場合、フォント、DPI、既定のレンダリング、古いコントロールの互換性で画面差分が出ることがあります。帳票入力、金融・製造系の固定幅画面、バーコード印刷、ラベル印刷などは、ピクセル単位のずれが業務影響につながるため、スクリーンショット比較や利用部門レビューを入れるべきです。

まとめ：Form Class の更新は「API確認」ではなく「WinForms資産の棚卸し」として進める

.NET の Form Class (System.Windows.Forms) は、WinForms アプリのウィンドウやダイアログを表す基本クラスです。2026年7月時点で確認すべきポイントは、Form の意味が大きく変わったかどうかではなく、.NET 10 世代の機能追加、非推奨警告、サポート期限を踏まえて、既存の Windows デスクトップアプリを安全に維持できるかです。

まずは、WinForms アプリを棚卸しし、TargetFramework、配布方式、非推奨 API、機密情報を表示するフォームを確認してください。そのうえで、.NET 8 / .NET 9 のサポート終了が近いアプリは .NET 10 への移行計画を立て、機密画面には FormScreenCaptureMode の適用可否を検証します。

開発チームは警告の解消、管理者はランタイム更新と配布方式、セキュリティ担当者はキャプチャ対策と情報表示ルールを確認する。これが、Form Class の更新ポイントを実務で安全に活かすための最短ルートです。

C#
C# .NET Windows Forms System.Windows.Forms

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次