はじめに
Visual Studio 2022 がリリースさせて、私が一番驚いたことは 64bit化 されたことでした！！
なぜなら、Microsoft社は長年「Visual Studioを64bitにする予定はない」と公言していたからです。（絶望でした…）
メモリ効率や互換性の観点から、IDEは32bitのままで十分だと考えられていました。
しかし現実は違いました。大規模開発の増加、IntelliSenseの高機能化、拡張機能の多様化――32bitの限界は、もはや無視できないレベルに達していたのです。
そして64bit化は、メモリ不足の解消だけにとどまりませんでした。
列幅が勝手に変わる。
カスタムコントロールがデザイナーで表示されない。
ツールボックスからアイテムが消える。
――そんな地味な「あるある」に、現場の私たちはこっそり泣いていたとか...
そして、長年「謎のバグ」として放置されてきたWinFormsデザイナーの問題たちに、ついに終止符が打たれたのです！！
今回は、Visual Studio 2022によって解決された32bit時代のWinFormsデザイナー問題を、具体的な症状・原因・回避策を交えながら振り返ります。
「あったあった！」と懐かしくなる方も、「そんな時代があったのか」と驚く方も、ぜひ最後までお付き合いください。
Visual Studio 2022以前の32bit問題
Visual Studio 2019以前は32bitアプリケーションだったのに対し、.NET Framework 4.0以降のプロジェクトはデフォルトでAnyCPU（実質64bit）としてコンパイルされていました。このアーキテクチャの不一致が、デザイナーで様々な問題を引き起こしていたのです。
問題その1 - DataGridViewの謎の挙動
列幅が勝手に変わる問題
症状
- デザイナーで列幅を設定したのに、実行時に勝手に変わる
- AutoSizeColumnsMode を設定していないのに自動調整される
- 列の表示順序が勝手に並び替わる
当時の回避策
// プロジェクトのプラットフォームを「x86」に変更
// または、コードで明示的に列幅を再設定
private void Form1_Load(object sender, EventArgs e)
{
dataGridView1.Columns[0].Width = 100; // デザイナーで設定したはずなのに...
dataGridView1.Columns[1].Width = 150;
}
なぜ起きていたのか
Visual Studioのデザイナープロセスとプロジェクトのアーキテクチャが異なるため、デザイン時と実行時でDataGridViewの描画処理に微妙な差が生じていました。特に、DPI設定やフォントメトリクスの計算で誤差が発生しやすかったのです。
問題その2 - ユーザーコントロールがデザイナーで表示されない
「型 'XXX' が見つかりませんでした」エラー
症状
- ユーザーコントロールを作成したのにデザイナーで開けない
- エラーメッセージ: 「型 'ClassName' が見つかりませんでした」
- ビルドは成功するのにデザイナーだけエラー
当時の回避策
<!-- プロジェクトファイルでプラットフォームを明示的に指定 -->
<PropertyGroup>
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
または、ソリューション構成でプラットフォームを 「Any CPU」から「x86」 に変更。
なぜ起きていたのか
64bitでコンパイルされたアセンブリを、32bitのVisual Studioデザイナーが読み込めなかったためです。特に、プロジェクト参照や依存関係が複雑になると頻繁に発生していました。
問題その3 - ツールボックスのコンポーネントが消える
カスタムコントロールがツールボックスから消失
症状
- サードパーティ製コントロールがツールボックスから消える
- 「ツールボックス アイテムの読み込みに失敗しました」エラー
- 一度は表示されたのに、再起動すると消えている
当時の回避策
- プロジェクトプラットフォームをx86に変更
- Visual Studioを再起動
- ツールボックスアイテムを手動で再登録
なぜ起きていたのか
32bit専用でコンパイルされたコンポーネントや、32bit COM/ActiveXコンポーネントを参照しているコントロールが、Visual Studioのデザイナープロセス内でインスタンス化できなかったためです。
問題その4 - プロパティグリッドの不具合
カスタムエディターが突然消える
症状
- PropertyGridのカスタムエディターが表示されない
- TypeConverterが正常に動作しない
- デザイン時プロパティの値が保存されない
当時の回避策
// DesignModeプロパティでデザイン時の処理を分岐
if (!this.DesignMode)
{
// 実行時のみの処理
InitializeCustomComponents();
}
Visual Studio 2022での解決 - アウトプロセスデザイナー
Visual Studio 2022では、これらの問題を解決するためにアウトプロセスデザイナーが導入されました。
アウトプロセスデザイナーとは
Visual Studioのメインプロセスとは別に、専用のデザイナープロセス（FxDesignToolsServer.exe）が起動し、そこでWinFormsデザイナーが動作します。これにより・・・
- 32bitコンポーネントも読み込み可能
- .NET Framework と .NET の両方をサポート
- COM/ActiveXコンポーネントも使用可能
有効化方法
.NET Frameworkプロジェクトの場合、プロジェクトファイルに以下を追加
<PropertyGroup>
<UseWinFormsOutOfProcDesigner>True</UseWinFormsOutOfProcDesigner>
</PropertyGroup>
それでも残る制限事項
アウトプロセスデザイナーは多くの問題を解決しましたが、完全ではありません。
- 高度にカスタマイズされたデザイナー は互換性がない場合がある
- 一部のサードパーティコントロール で対応が必要
- パフォーマンスは従来のインプロセスデザイナーより若干劣る
まとめ
Visual Studio 2022の 64bit化 は、メモリ使用量の改善だけでなく、長年WinFormsデザイナーを悩ませてきた32bit起因の問題も解決してくれました。
当時「なんでこうなる...」と頭を抱えていた問題の多くが、実はアーキテクチャの不一致が原因だったというのは、今振り返ると感慨深いものがあります。
これらの問題を経験された方は、Visual Studio 2022への移行で開発効率が大幅に向上したのではないでしょうか。
参考リンク
- 32 ビットの問題のトラブルシューティング - Microsoft Learn
- WinForms Designer Selection for 32-bit .NET Framework Projects
おわりに
Visual Studio 2022になって、こうした問題で悩む時間が大幅に減りました。開発者としては本当にありがたい進化ですね。