C# と VB.NET の質問掲示板

ツリー一括表示
.NET Frameworkから.NET8への移行 /カフェ (25/03/03(Mon) 22:55) #103576
`├` Re[1]: .NET Frameworkから.NET8への移行 /魔界の仮面弁士 (25/03/04(Tue) 01:01) #103577
`└` Re[1]: .NET Frameworkから.NET8への移行 /WebSurfer (25/03/04(Tue) 09:40) #103578
`└` Re[2]: .NET Frameworkから.NET8への移行 /カフェ (25/03/04(Tue) 15:48) #103579
`└` Re[3]: .NET Frameworkから.NET8への移行 /魔界の仮面弁士 (25/03/04(Tue) 16:42) #103580
`├` Re[4]: .NET Frameworkから.NET8への移行 /カフェ (25/03/04(Tue) 18:23) #103581 解決済み
`└` Re[4]: .NET Frameworkから.NET8への移行 /WebSurfer (25/03/05(Wed) 09:29) #103582 解決済み

分類:[.NET 全般]　

2025/03/03(Mon) 22:56:21 編集(投稿者)
2025/03/03(Mon) 22:56:18 編集(投稿者)

.NET FrameworkのVB.NETのフォームアプリケーションを
.NET8のVB.NETのフォームアプリケーションに書き換えたいと考えています。

試してみると、.NET Frameworkの

Form1.Designer.vb
Form1.resx
Form1.vb

の三つのファイルを
.NET8のプロジェクト内にD&Dで読み込ませると
簡単に移植できることが分かりました。

しかし、中のコードは流用できているようなのですが、
なぜかウインドウのサイズが1.7倍くらい大きくなり、
TableLayoutPanelやコントロール間の距離も1.7倍くらい大きくなってしまいます。

手動で一つずつサイズを修正していくのが面倒なのですが、
サイズをそのままで、フォームを移植する方法はありませんでしょうか？

2025/03/04(Tue) 14:11:41 編集(投稿者)

■No103576 (カフェさん) に返信
> なぜかウインドウのサイズが1.7倍くらい大きくなり、
> TableLayoutPanelやコントロール間の距離も1.7倍くらい大きくなってしまいます。

複数の要因が考えられるため、まず確認しておきたいのですが、
開発環境の Windows の画面設定(dpi)は、「100%」設定になっていますか?

高解像度ノートPCなど、画面が 125%、150%、175% などに設定されている環境の場合、
Windows Forms のデザインが崩れる原因となります。(VS上に警告が出るのでご存じとは思いますが)

100% 設定なのに崩れてしまう場合、旧環境と新環境とで、Form1.desginer.vb 内に
書き込まれる AutoScaleDimensions の設定値が変化している可能性があります。

AutoScaleDimensions 値の変化は、Form の AutoScaleMode プロパティが
None 以外の値に設定されている場合に特に顕著となります。
これは、Font プロパティを未設定時の既定のフォントが、.NET Core 3.0 の段階で
日本語環境では "MS UI Gothic, 9pt" ⇒ "Yu Gothic UI, 9pt"
英語版環境では "Microsoft Sans Serif, 8.25pt" ⇒ "Segoe UI, 9pt"
と変化したことに由来します。なのでコンテナ(Form や Panel)の Font プロパティが
(未設定ではなく)設定済みである場合には、その Font プロパティに対して
.NET Framework 環境下での Font プロパティ値と同じフォントを割り当てておくことで
問題を回避できる可能性があります。(AutoScaleMode が Font であった場合)
なお、Font は ambient なプロパティであるため、明示的に設定する場合は
コンテナ側を優先的に設定した方が良いでしょう。

あるいは Font を個別に明示指定することで対処する代わりに、
そもそも既定のフォントを変更する手法、すなわち .vbproj ファイルにて
<ApplicationDefaultFont>MS UI Gothic, 9pt</ApplicationDefaultFont>
を設定しておく方法でも、デザイン面の問題を解決できる可能性があります。。

また、必ずしもデザイン時のサポートが不要な場合は、実行時に
System.Windows.Forms.Application.SetDefaultFont メソッドを呼ぶという手もあります。

なお Windows ユーザーエクスペリエンス (UX) のガイドラインによれば、Windows Vista 以降において
システムフォントが変更されたことから、マイグレーションを伴わない新規プロジェクトにおいては
既定のフォントを Segoe UI や Yu Gothic UI のままにしておいた方が良いかもしれません。

参考情報：

[Windows フォーム for .NET 6 の新機能]
https://learn.microsoft.com/ja-jp/dotnet/desktop/winforms/whats-new/net60?WT.mc_id=DT-MVP-8907&view=netdesktop-9.0

[Windows フォームでの自動スケーリング]
https://learn.microsoft.com/ja-jp/dotnet/desktop/winforms/automatic-scaling-in-windows-forms?WT.mc_id=DT-MVP-8907&view=netframeworkdesktop-4.8

[方法: Windows フォームアプリケーションのフォントパターンの変更に対応する]
https://learn.microsoft.com/ja-jp/dotnet/desktop/winforms/how-to-respond-to-font-scheme-changes-in-a-windows-forms-application?WT.mc_id=DT-MVP-8907&view=netframeworkdesktop-4.8

[Windows ユーザーエクスペリエンス (UX) - フォント]
https://learn.microsoft.com/ja-jp/windows/win32/uxguide/vis-fonts?WT.mc_id=DT-MVP-8907#fonts-and-colors

■No103576 (カフェさん) に返信
> 2025/03/03(Mon) 22:56:21 編集(投稿者)

質問に対する直接の回答ではなくてすみませんが・・・

> .NET FrameworkのVB.NETのフォームアプリケーションを
> .NET8のVB.NETのフォームアプリケーションに書き換えたいと考えています。

Windows OS 上で動く Windows Forms アプリとか WPF アプリは、.NET の新機能を利用
したいなどの理由がない限り、ターゲットフレームワークは ,NET Framework 4.8.1 で
作った方が良さそうです。

フレームワークを .NET とした場合、.NET Framework からの破壊的変更があるとか (コ
ントロールが多数削除されているなど)、特定の OS に依存する機能は Visual Studio
のテンプレートで作るプロジェクトには含まれてないとか (例: GDI+ に依存するグラフ
ィックス機能、エンコーディングの Shift_JIS)、ReportViewer や Chart が使えないと
か、データソース構成ウィザードが使えないとか、Visual Studio のデザイナが対応し
てないとか、乗り越えなければならない壁がいくつもあります。

サポート期間の長さを気にしてということなら、.NET 8.0 の 2026年 11 月 10 日よ
り (.NET 9.0 はそれより短い 2026 年 5 月 12 日)、 .NET Framework 4.8.1 の「サ
ポートされているバージョンの Windows にインストールされている限り」の方が長い
はずです。

Microsoft .NET および .NET Core
https://learn.microsoft.com/ja-jp/lifecycle/products/microsoft-net-and-net-core

.NET Framework サポートポリシー
https://dotnet.microsoft.com/ja-jp/platform/support/policy/dotnet-framework

開発環境の Windows の画面設定(dpi)は、「100%」設定になっております。

確認したところ、
AutoScaleMode プロパティは、AutoScaleMode.Fontになっていました。

仰る通り、
.NET Framework 環境だと
MS UI Gothic, 9pt
になっていたのが、
.NET8だと
Yu Gothic UI, 11.25pt
になっていました。
MS UI Gothic, 9ptに変更すると、
フォームのサイズが元のサイズになることが分かりました。

> なお Windows ユーザーエクスペリエンス (UX) のガイドラインによれば、Windows Vista 以降において
> システムフォントが変更されたことから、マイグレーションを伴わない新規プロジェクトにおいては
> 既定のフォントを Segoe UI や Yu Gothic UI のままにしておいた方が良いかもしれません。

これはつまり、
フォームのフォントを変更したことで、環境によっては
フォントが崩れたりなどの不具合が起きる可能性があるということでしょうか？

つまり、可能であれば、フォームフォントをデフォルトから変更せずに
フォームレイアウトを一つずつ修正した方が良いという意味で合っていますか？

■No103578 (WebSurfer さん) に返信

できれば、.NET Framework を使い続けたいのですが、
最新のDLLのほとんどが.NETになっており、
.NET Frameworkで使えるようにするためには
一つずつ自分で修正しないといけないので非常に面倒なのです。

■No103579 (カフェさん) に返信
> AutoScaleMode プロパティは、AutoScaleMode.Fontになっていました。
自動スケーリングが不要な場合は、あらかじめ None にしておいた方が良いのですが、
それはまぁ今更ですし、案件によっては None では都合が悪い場合もあるでしょうね。

> フォームのサイズが元のサイズになることが分かりました。
「Font が未設定」のコントロールの扱いに気を付けてください。
特に TableLayoutPanel や Form といったコンテナ系コントロール。

プロパティウィンドウで見た時に、
Font 欄の名称が太字フォントで描画されている場合は明示的な設定、
Font 欄の名称が通常幅で描画されている場合は、プロパティ未設定です。

プロパティ未設定の場合、親コントロール(Panel など)の Font を引き継ぎますが、
Form はそれ以上親コントロールが無いため、先の DefaultFont が採用されます。

※こういった、親のプロパティ値が引き継がれるものは ambient property と呼ばれます。
　コントロールによっては BackColor/ForeColor プロパティもアンビエントとなります。

> フォームのフォントを変更したことで、環境によっては
> フォントが崩れたりなどの不具合が起きる可能性があるということでしょうか？
フォントの差異によるズレは、Windows 2000 ⇒ XP の時にも発生していましたが
今回の変更はそれよりも影響度が大きいですよね。
https://tkb11.com/misc/winxp-fixedfontpitch-info.php

そのため先に紹介した URL にもあるように、
既定のフォントを指定できるオプションが追加されたわけです。

今回は .NET Framework 互換のレイアウトにすることが目的のようですし、
ひとまず ApplicationDefaultFont 設定で改善されるのではないでしょうか。

ちなみに既定のフォントが変更された経緯はこのあたり。
https://github.com/dotnet/winforms/issues/524

> つまり、可能であれば、フォームフォントをデフォルトから変更せずに
> フォームレイアウトを一つずつ修正した方が良いという意味で合っていますか？
いいえ。『マイグレーションを伴わない新規プロジェクト』と書きましたように、
あくまでも .NET Framework のデザインを継承しない「新規案件」の話です。

既存案件の画面設計をリデザインするべきかどうかに言及したわけでは無いです。

> できれば、.NET Framework を使い続けたいのですが、
自分のところは、.NET はサーバー案件や Web アプリでのみ使用していて、
デスクトップアプリの案件は .NET Framework のままにすることが多いです。

.NET Framework だと、ランタイムが OS に組み込まれている上に、
古い Windows が淘汰されたことでランタイムバージョンも絞られてきて、
アプリの配布も楽なんですよね…。

.NET だとランタイムが別途配布となるし、アプリに同梱すると結構なサイズになるので。

> 最新のDLLのほとんどが.NETになっており、
そうなんですよね…。
.NET Standard 対応のライブラリであれば、.NET Framework と .NET (Core)の両方に
対応できる可能性がありますが、最近は .NET Framework 向けでないものも増えてきてしまって。

依存ライブラリのバージョンが上がったときに、それに依存した他のライブラリのバージョンが
合致しなくなって頓挫する機会も増えてしまっていて、正直悩ましい。。。作りっぱなしにしないで、
継続的に短いサイクルで、バージョンアップ & リビルドしていけってことなんでしょうけれども。

ありがとうございます。
助かりました。
心より感謝いたします。

■No103580 (魔界の仮面弁士さん) に返信

>>最新のDLLのほとんどが.NETになっており、
> そうなんですよね…。
> .NET Standard 対応のライブラリであれば、.NET Framework と .NET (Core)の両方に
> 対応できる可能性がありますが、最近は .NET Framework 向けでないものも増えてきてしまって。

よろしければ具体例を教えていただけませんか？

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト