MENU

.NETのForm.AddOwnedFormとは？WinForms更新ポイントと移行確認事項

C#

.NET の Form.AddOwnedForm(Form) は、Windows Forms のメインフォームに補助フォームを「所有フォーム」として登録するためのメソッドです。2026年7月1日に公開または更新された公式情報を読むうえで最初に押さえるべき結論は、これはクラウド側の設定変更や管理ポータルの変更ではなく、WinForms アプリの画面制御に関わる API 確認事項だという点です。検索・置換ウィンドウ、プロパティパネル、ツールウィンドウのように「親フォームの背後に隠れてほしくない画面」を持つアプリでは、実装とテスト観点を見直す価値があります。Microsoft Learn では、このメソッドは System.Windows.Forms 名前空間、System.Windows.Forms.dll に属し、「Adds an owned form to this form.」と説明されています。(Microsoft Learn)

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

.NET の新機能・変更点：「Form.AddOwnedForm(Form)」で確認すべきポイント

Form.AddOwnedForm(Form) は、新しい業務機能を追加する API というより、既存の Windows Forms アプリで「フォーム同士の所有関係」を明示するための API です。所有フォームにすると、補助フォームは所有者フォームと連動して閉じる、隠れる、最小化されるなどの動作を取ります。また、所有フォームは所有者フォームの背後に表示されないため、ユーザーが作業中の補助画面を見失いにくくなります。(Microsoft Learn)

特に影響を受けるのは、次のようなアプリです。

影響を受ける可能性があるアプリ確認すべき理由
Windows Forms で複数フォームを表示する業務アプリ補助フォームが親フォームの背後に隠れる、最小化時に残る、といった挙動を制御できる
検索、置換、プロパティ、進捗表示などの非モーダル画面を持つアプリユーザーがメイン画面に戻っても補助画面を前面関係に保ちやすい
MDI を使っている古いデスクトップアプリ所有フォームと MDI 子フォームは別概念のため、取得・管理方法を分ける必要がある
.NET Framework から .NET へ移行中の WinForms アプリAPI 呼び出し自体より、ターゲットフレームワーク、プロジェクト形式、依存ライブラリの確認が重要になる

Form.AddOwnedForm(Form) の基本：何を追加するメソッドなのか

AddOwnedForm は、呼び出し元のフォームに対して、引数で渡した Form を「owned form」として追加します。シグネチャは C# では public void AddOwnedForm(System.Windows.Forms.Form ownedForm); または nullable 注釈付きで public void AddOwnedForm(System.Windows.Forms.Form? ownedForm); と示されています。引数 ownedForm は、このフォームが所有する対象の Form です。(Microsoft Learn)

所有関係を作る方法は、AddOwnedForm だけではありません。Microsoft Learn では、Owner プロパティに所有者フォームの参照を設定する方法でも、フォームを別フォームに所有させられると説明されています。つまり、実務上は次の3パターンを使い分けます。(Microsoft Learn)

方法向いている場面補足
AddOwnedForm(childForm)既に生成した補助フォームを、明示的に所有フォーム一覧へ追加したい所有関係が分かりやすい
childForm.Owner = this子フォーム側から所有者を設定したいOwner プロパティを直接使う
childForm.Show(this)表示と所有者指定を同時に行いたいShow(IWin32Window) は非モーダルフォーム表示時に Owner を設定する

Show(IWin32Window) は、指定した owner を持つフォームを表示するメソッドで、非モーダルフォームの Owner プロパティを設定してから Show() を呼ぶのと同等とされています。新規コードでは Show(this) のほうが読みやすい場面もありますが、所有フォーム一覧を明示的に管理したい場合は AddOwnedForm が適しています。(Microsoft Learn)

所有フォームにすると変わる実際の動作

所有フォームにした場合の重要な挙動は、単に「親子関係ができる」だけではありません。ユーザー体験に直接影響します。

動作実務上の意味
所有者フォームが閉じられると、所有フォームも閉じられるメイン画面終了後に補助画面だけ残る状態を避けやすい
所有者フォームが最小化されると、所有フォームも隠れるまたは最小化される補助画面だけがデスクトップ上に残る違和感を減らせる
所有フォームは所有者フォームの背後に表示されない検索・置換ウィンドウやツールウィンドウを見失いにくい
RemoveOwnedForm を呼ぶまで所有関係が続く一時的な補助画面では解除タイミングを設計する必要がある

Microsoft Learn では、所有フォームは所有者フォームとともに閉じられたり隠れたりし、所有者フォームの背後には表示されないと説明されています。また、所有フォームの関係は RemoveOwnedForm が呼ばれるまで継続します。(Microsoft Learn)

実装例：検索ウィンドウをメインフォームの所有フォームとして表示する

次の例は、メインフォームから検索ウィンドウを非モーダルで開き、メインフォームの所有フォームとして管理する実装です。検索ウィンドウを何度も開かないようにし、閉じたときに所有関係を解除します。

public partial class MainForm : Form
{
    private Form? _findForm;

    private void ShowFindWindow()
    {
        if (_findForm is { IsDisposed: false })
        {
            _findForm.Activate();
            return;
        }

        var findForm = new FindForm();
        _findForm = findForm;

        AddOwnedForm(findForm);

        findForm.FormClosed += (_, _) =>
        {
            RemoveOwnedForm(findForm);

            if (ReferenceEquals(_findForm, findForm))
            {
                _findForm = null;
            }
        };

        findForm.Show();
    }
}

この実装で重要なのは、ShowDialog() ではなく Show() を使っている点です。AddOwnedForm は「非モーダルの補助フォームを親フォームにひも付ける」用途に向いています。ユーザー操作を親フォーム側で止めたい設定画面や確認画面なら、所有フォームではなくモーダルダイアログを検討します。

より短く書くなら、次のように Show(this) を使う選択肢もあります。

var findForm = new FindForm();
findForm.Show(this);

ただし、所有フォームの解除や一覧管理を自分で明示したい場合は、AddOwnedForm と RemoveOwnedForm を使ったほうが意図を追いやすくなります。

2026年7月1日版で見る API 面の更新ポイント

今回の公式情報で確認しておきたいのは、「大きな破壊的変更が示された」というより、現在の .NET API リファレンスとして次の仕様を正しく読めるようにすることです。

確認項目読み解き方
nullable 注釈現在のシグネチャでは Form? としても示され、null を渡せる形で表現されている
null 指定時の動作公式ソースでは ownedForm is null の場合に何もせず戻る実装になっている
重複追加既に一覧に含まれている場合は重複追加しない実装になっている
Owner との関係ownedForm.OwnerInternal != this の場合、ownedForm.Owner = this を設定する流れになっている

公式ソースでは、AddOwnedForm(Form? ownedForm) が null の場合に return し、所有者が異なる場合は Owner を設定し、所有フォーム一覧に既に存在する場合は追加しない実装が確認できます。(GitHub)

このため、既存コードで AddOwnedForm(null) 相当の呼び出しがあっても、それ自体で例外が発生する設計ではありません。ただし、null を渡しても何も起きないだけなので、実務では「フォーム生成に失敗しているのに気付かない」ことのほうが問題になります。ログやデバッグ時の検証では、ownedForm が null になっていないかを確認しましょう。

MDI アプリでは OwnedForms と MdiChildren を混同しない

古い業務アプリでは MDI を使っているケースがあります。この場合、OwnedForms と MdiChildren は同じ意味ではありません。

OwnedForms は、このフォームが所有するフォームの配列を返します。一方、MDI 親フォームで開いている MDI 子フォームを取得したい場合は、MdiChildren を使う必要があります。Microsoft Learn でも、MDI 親フォームの場合、所有フォームの取得と MDI 子フォームの取得は区別されています。(Microsoft Learn)

やりたいこと使う API
メインフォームに所有される検索ウィンドウやツールウィンドウを管理するOwnedForms、AddOwnedForm、RemoveOwnedForm
MDI 親フォーム内で開いているドキュメント画面を列挙するMdiChildren
子フォーム側から所有者を参照するOwner
非モーダル表示時に所有者も指定するShow(IWin32Window)

MDI アプリの移行では、「コンパイルできるか」だけでなく、ウィンドウの前後関係、最小化時の動き、閉じる順序を確認してください。特にグローバル展開している業務アプリでは、複数画面、複数 DPI、リモートデスクトップ環境で見え方が変わることがあります。

設定変更は必要か：AddOwnedForm 専用の管理設定はない

Form.AddOwnedForm(Form) の利用にあたり、Microsoft 365 管理センターや Azure ポータルのような管理画面で変更する設定はありません。影響範囲は Windows Forms アプリのコードと実行環境です。

ただし、.NET Framework から現在の .NET へ移行している場合は、プロジェクト設定を確認する必要があります。Windows Forms を .NET Desktop SDK プロジェクトで使うには、Windows 固有のターゲットフレームワークモニカー、たとえば net8.0-windows のような指定と、UseWindowsForms の有効化が必要です。Microsoft Learn では、WinForms または WPF を使う場合、TargetFramework を Windows 固有の TFM にし、UseWindowsForms を true に設定すると説明されています。(Microsoft Learn)

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

ここで注意したいのは、AddOwnedForm のためにこの設定を追加するのではなく、Windows Forms アプリとして .NET でビルドするために必要な設定だという点です。既に WinForms アプリとして正常にビルド・実行できているプロジェクトなら、AddOwnedForm 専用の追加設定は基本的にありません。

移行期限：API ではなく .NET ランタイムのサポート期限で判断する

Form.AddOwnedForm(Form) 自体に、特定日までの移行期限が示されているわけではありません。管理者やアプリ責任者が見るべき期限は、アプリが依存する .NET ランタイムや .NET Framework のライフサイクルです。

Microsoft Lifecycle では、.NET 8 と .NET 9 の終了日が 2026年11月10日、.NET 10 の終了日が 2028年11月14日として示されています。日付は太平洋時間基準で表示されます。(Microsoft Learn)

対象公式ライフサイクル上の確認ポイント
.NET 8LTS だが、終了日は 2026年11月10日。長期運用なら次の LTS への計画が必要
.NET 9終了日は 2026年11月10日。STS のため、早めの更新計画が必要
.NET 10終了日は 2028年11月14日。新規移行先として検討しやすい
.NET Framework 4.6.2終了日は 2027年1月12日。古い WinForms アプリでは優先確認対象
.NET Framework 4.8 / 4.8.1Microsoft Lifecycle では個別の終了日が表内に示されていないが、OS や配布形態とあわせて確認が必要

.NET Framework 4.5.2、4.6、4.6.1 は既に 2022年4月26日にサポート終了済みで、4.6.2 は 2027年1月12日に終了予定です。古い業務端末に残っている WinForms アプリでは、AddOwnedForm の動作確認以前に、対象ランタイムがサポート内かを棚卸ししてください。(Microsoft Learn)

管理者が確認すべきポイント

管理者やアプリ運用担当者は、AddOwnedForm のコードだけを見ても十分ではありません。実行端末、配布方式、サポート期限、UI テストを合わせて確認します。

確認項目具体的な確認方法
対象アプリの把握ソースコードで AddOwnedForm、Owner、Show(this)、OwnedForms を検索する
実行ランタイムdotnet --list-runtimes で端末に入っている .NET ランタイムを確認する
SDK とランタイムの状態dotnet sdk check でインストール済み SDK と Runtime が最新か、サポート外かを確認する
UI 回帰テストメインフォームの最小化、復元、終了時に補助フォームが意図どおり動くか確認する
MDI 利用有無MDI 子フォームを OwnedForms で扱っていないか確認する
グローバル展開言語設定、DPI、マルチモニター、リモートデスクトップで補助フォームが見失われないか確認する

dotnet --list-runtimes はインストール済み .NET ランタイムを表示するコマンドで、dotnet sdk check は SDK と Runtime の最新状態やサポート外状態の確認に使えます。端末管理の観点では、コードレビューだけでなく、実行環境の棚卸しにも組み込むと安全です。(Microsoft Learn)

dotnet --list-runtimes
dotnet sdk check

開発者が失敗しやすいポイント

AddOwnedForm は便利ですが、意図を誤ると画面制御の不具合につながります。

失敗パターン起きる問題対策
モーダル画面の代わりに使う親フォームを操作できてしまい、入力順序が崩れる入力を止めたい画面は ShowDialog() を使う
RemoveOwnedForm を考慮しない一時的なフォームの所有関係が残る閉じる・破棄するタイミングで解除する
MDI 子フォームと混同する子ドキュメント一覧の取得や制御を誤るMDI には MdiChildren を使う
所有者を複数箇所で設定するOwner、Show(owner)、AddOwnedForm の責務が曖昧になるプロジェクト内で実装ルールを統一する
画面テストを省略するビルドは通るが、前後関係や最小化時の挙動が崩れるUI 操作シナリオをテストケースに入れる

Show(IWin32Window) には、既に表示中のフォーム、無効化されたフォーム、トップレベルではないフォーム、自分自身を owner にするケースなどで例外が発生する条件があります。AddOwnedForm の周辺コードを整理するときは、単に呼び出しを置き換えるのではなく、表示状態と所有者の整合性を確認してください。(Microsoft Learn)

実務での判断基準：AddOwnedForm を使うべき場面、避ける場面

AddOwnedForm を使うべきか迷ったら、「その補助画面はメイン画面と一緒に扱われるべきか」で判断します。

判断基準推奨
メイン画面の作業を補助する検索・置換・ツール画面AddOwnedForm または Show(this) が向いている
ユーザーに必ず回答させたい確認画面ShowDialog() が向いている
複数ドキュメントを MDI 内で管理する画面MdiChildren を中心に設計する
独立したメイン画面として扱う画面所有フォームにしないほうが自然
アプリ終了時に一緒に閉じたい補助画面所有フォームにする価値がある

検索・置換ウィンドウのように、親フォームを選択しても背後に隠れてほしくない画面は、所有フォームの代表的な活用例です。Microsoft Learn でも、所有フォームは検索・置換ウィンドウのような用途に使えると説明されています。(Microsoft Learn)

.NET Framework から .NET へ移行する場合の追加確認

.NET Framework 版の WinForms アプリを .NET へ移行する場合、AddOwnedForm だけを確認しても不十分です。Microsoft Learn の Windows Forms 移行ガイドでは、.NET Framework から .NET への移行は大きな変更であり、プロジェクトファイル形式、API、利用できない技術、依存ライブラリ、破壊的変更を確認する必要があると説明されています。(Microsoft Learn)

移行時は、次の順序で確認すると手戻りを減らせます。

  1. 現行アプリのターゲットフレームワークと依存ライブラリを棚卸しする
  2. Windows Forms 固有の画面制御コードを検索する
  3. AddOwnedForm、Owner、Show(owner)、ShowDialog() の使い分けを整理する
  4. .NET のターゲットを net10.0-windows などに変更する前に、破壊的変更を確認する
  5. ビルド後、ウィンドウの前後関係、最小化、終了、DPI、マルチモニター環境をテストする

特に注意すべきなのは、移行で発生する問題がコンパイルエラーとして出るとは限らない点です。Microsoft Learn でも、破壊的変更には実行時の動作変更、バイナリ互換性、ソース互換性、デザイン時互換性などがあると説明されています。画面制御系の不具合は、実際に操作しないと見つからないことがあります。(Microsoft Learn)

まず取るべきアクション

Form.AddOwnedForm(Form) の更新ポイントを確認するうえで、最初にやるべきことはシンプルです。対象アプリのコードを検索し、所有フォームを使っている画面を洗い出してください。そのうえで、親フォームの最小化・終了・再表示時に補助フォームが期待どおり動くかをテストします。

同時に、対象アプリが使っている .NET ランタイムのサポート期限を確認します。AddOwnedForm 自体に移行期限があるわけではありませんが、.NET 8、.NET 9、.NET Framework 4.6.2 などにはライフサイクル上の期限があります。API の意味、プロジェクト設定、ランタイム期限、UI 回帰テストをセットで確認することが、グローバルに展開される Windows Forms アプリを安全に維持する最短ルートです。

C#
C# .NET WinForms Microsoft Learn Windows Forms

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次