WinForms(.NET Framework 4.8)でDPI対応&longPathAwareを設定するマニフェスト完全解説【Visual Studio 2013/2019/2022対応】

WinForms(.NET Framework 4.8)アプリを高解像度モニターや長いパスを扱う環境で快適に動かすには、マニフェストでの DPI 設定と longPathAware の有効化が重要です。本記事では、VS2013 から VS2022 までの Visual Studio で共通して使えるマニフェストの書き方と、よくある「asmv3 が定義されていない」エラーの原因と対処方法を、具体的なサンプル付きで解説します。

目次

WinForms と DPI/長パス問題の整理

まず、今回のテーマを整理します。対象は次のようなプロジェクトです。

  • 言語:VB.NET(C# でも同様)
  • 種類:WinForms アプリケーション
  • フレームワーク:.NET Framework 4.8
  • 開発環境:Visual Studio 2013 / 2017 / 2019 / 2022

解決したいポイントは次の 3 つです。

  1. 高 DPI 環境でフォームがぼやけたり拡大縮小で崩れないように、マニフェストに dpiAware / dpiAwareness を正しく記述したい。
  2. パス長 260 文字制限を緩和するために、longPathAware をマニフェストに追加したい。
  3. VS2013・VS2022 で「asmv3 が定義されていない」と怒られずにビルドしたい。

結論から言うと「VS2013 のままでも VS2022 に移行しても、どちらでも対応可能」です。必要なのは、asm.v3 の名前空間を正しく宣言し、ルート <assembly> の閉じタグ直前に asm.v3 用の <application> ブロックを追加することだけです。

結論の要約:こうすれば VS のバージョンに関係なく動く

先に最重要ポイントだけを箇条書きで整理しておきます。

  • マニフェストのルートは従来どおり asm.v1(既定名前空間)。
  • DPI/長パスの設定は、閉じタグ </assembly> の直前に asm.v3 用ブロックとして追記する。
  • asm.v3 ブロックは、<application xmlns="urn:schemas-microsoft-com:asm.v3"> のように「そのブロックだけ既定名前空間を asm.v3 に切り替える」と簡潔に書ける。
  • プレフィックス(asmv3: など)で書く場合は、ルート要素で xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" を宣言して、開きタグ/閉じタグともに統一する。
  • VS2013 でも VS2022 でも、同じマニフェストファイルを問題なくビルド/実行できる。
  • ただし開発環境としては、サポート・テンプレート整備の面から VS2019 / VS2022 を推奨。

以下では、具体的なマニフェスト例や Visual Studio ごとの注意点、WinForms 側の DPI 設定まで含めて詳しく解説します。

マニフェストの基本構造と asm.v3 の役割

Windows のアプリケーション マニフェストでは、バージョンごとに以下のような名前空間が使われます。

名前空間URI主な役割
asm.v1urn:schemas-microsoft-com:asm.v1ルート <assembly> / ID / description / trustInfo / compatibility など基本情報
asm.v2urn:schemas-microsoft-com:asm.v2依存アセンブリやファイル情報など(WinForms マニフェストではあまり触らないことも多い)
asm.v3urn:schemas-microsoft-com:asm.v3DPI や longPath など「windowsSettings」配下の高機能設定

Visual Studio の既定マニフェストでは、たいていルートに以下のような宣言があり、asm.v1 が既定名前空間になっています。

&lt;assembly xmlns="urn:schemas-microsoft-com:asm.v1"
          manifestVersion="1.0"&gt;
  ...
&lt;/assembly&gt;

この状態でいきなり <dpiAware><longPathAware> を書き足しても、そこは asm.v1 の世界なのでコンパイラやツールが要素を認識できず、「asmv3 が定義されていない」等のエラーや警告が出ることがあります。そこで、DPI や longPath の設定を行う部分だけ、名前空間を asm.v3 に切り替える必要があります。

DPI/長パス対応付きマニフェストの最小サンプル

もっともシンプルで扱いやすい形のサンプルを示します。ポイントは次の 2 つです。

  • ルートの <assembly> は従来どおり asm.v1 のまま。
  • 閉じタグ直前に <application xmlns="urn:schemas-microsoft-com:asm.v3"> ブロックを入れる。
&lt;?xml version="1.0" encoding="utf-8"?&gt;
&lt;assembly xmlns="urn:schemas-microsoft-com:asm.v1"
          manifestVersion="1.0"&gt;

  &lt;assemblyIdentity version="1.0.0.0"
                    name="YourCompany.YourProduct" /&gt;

  &lt;trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"&gt;
    &lt;security&gt;
      &lt;requestedPrivileges&gt;
        &lt;requestedExecutionLevel level="asInvoker" uiAccess="false" /&gt;
      &lt;/requestedPrivileges&gt;
    &lt;/security&gt;
  &lt;/trustInfo&gt;

  &lt;!-- ここに compatibility GUID(Windows 7~10/11)などが入る想定 --&gt;

  &lt;!-- ここまでが既存の asm.v1 / asm.v3 セクション --&gt;

  &lt;!-- ▼DPI / longPath 設定:asm.v3 の application ブロックを末尾に追加 --&gt;
  &lt;application xmlns="urn:schemas-microsoft-com:asm.v3"&gt;
    &lt;windowsSettings&gt;
      &lt;dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"&gt;true&lt;/dpiAware&gt;
      &lt;dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings"&gt;PerMonitorV2&lt;/dpiAwareness&gt;
      &lt;longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings"&gt;true&lt;/longPathAware&gt;
    &lt;/windowsSettings&gt;
  &lt;/application&gt;
&lt;/assembly&gt;

この形であれば、以下をすべて満たせます。

  • .NET Framework 4.8 の WinForms プロジェクトでそのままビルド可能。
  • Visual Studio 2013 / 2017 / 2019 / 2022 のいずれでもマニフェスト エラーにならない。
  • DPI 対応(Per Monitor V2)と longPath 対応が適切に OS に伝わる。

要素ごとの役割を表にまとめておきます。

要素意味・効果
dpiAwaretrueアプリ全体がシステム DPI に対応していることを宣言。高 DPI でも OS による自動スケーリング(ぼやけ)を抑制。
dpiAwarenessPerMonitorV2モニターごとの DPI(Per Monitor v2)に対応していることを宣言。マルチモニター環境で DPI 変更に追従可能。
longPathAwaretrueアプリが長いパス(260 文字以上)を扱えることを宣言。OS 側で Win32 長パスが有効なら制限が緩和される。

「asmv3 が定義されていない」エラーの原因と対処

VS2013 や VS2022 でマニフェストを編集していると、次のようなエラーや警告が出ることがあります。

  • asmv3 が定義されていません
  • 要素 ‘application’ はこのコンテキストでは許可されていません … など

ほとんどの場合、原因は以下のどちらかです。

  1. asm.v3 の名前空間宣言がない、または中途半端。
  2. asm.v1 と asm.v3 の要素が混在しており、どの要素がどの名前空間か不明確。

ありがちな NG 例

&lt;assembly xmlns="urn:schemas-microsoft-com:asm.v1"
          manifestVersion="1.0"&gt;

  ...

  &lt;!-- NG: asm.v3 の宣言なしで突然 windowsSettings を書いている --&gt;
  &lt;windowsSettings&gt;
    &lt;dpiAware&gt;true&lt;/dpiAware&gt;
  &lt;/windowsSettings&gt;

&lt;/assembly&gt;

このように書くと、asm.v1 名前空間の中に windowsSettings という「知らない要素」が現れるため、ツールによっては「定義されていない」と解釈されてしまいます。

おすすめの OK 例(既定名前空間を切り替える方式)

もっともシンプルで読みやすいのが、先ほど紹介した「asm.v3 ブロックだけ既定名前空間を切り替える」方式です。

&lt;application xmlns="urn:schemas-microsoft-com:asm.v3"&gt;
  &lt;windowsSettings&gt;
    &lt;dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"&gt;true&lt;/dpiAware&gt;
    &lt;dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings"&gt;PerMonitorV2&lt;/dpiAwareness&gt;
    &lt;longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings"&gt;true&lt;/longPathAware&gt;
  &lt;/windowsSettings&gt;
&lt;/application&gt;

asm.v3 の URI を xmlns で指定しているため、このブロック内はすべて asm.v3 として扱われます。さらに、各子要素で WindowsSettings 用の URI を指定することで、dpiAware 等も正しく解釈されます。

プレフィックス方式で書く場合

XML のプレフィックスを使うのが好みであれば、次のような書き方も可能です。重要なのは、開きタグと閉じタグをすべてプレフィックス付きで統一することです。

&lt;assembly xmlns="urn:schemas-microsoft-com:asm.v1"
          xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"
          manifestVersion="1.0"&gt;

  ...

  &lt;asmv3:application&gt;
    &lt;asmv3:windowsSettings&gt;
      &lt;dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"&gt;true&lt;/dpiAware&gt;
      &lt;dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings"&gt;PerMonitorV2&lt;/dpiAwareness&gt;
      &lt;longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings"&gt;true&lt;/longPathAware&gt;
    &lt;/asmv3:windowsSettings&gt;
  &lt;/asmv3:application&gt;

&lt;/assembly&gt;

この場合、ルートで xmlns:asmv3 を宣言しているため、「asmv3:〇〇」はすべて asm.v3 として認識されます。どちらの方式でも構いませんが、混在させるとややこしくなるので、どちらか 1 つに統一するのがポイントです。

Visual Studio ごとの注意点とおすすめ構成

次に、Visual Studio のバージョンごとの特徴と注意点をまとめます。

Visual Studio.NET Framework 4.8 への対応テンプレートのマニフェストおすすめ対応
VS20134.8 自体は後から導入(ターゲット変更で対応可能)longPathAware は基本的に含まれない/DPI 設定もシンプルこの記事のサンプルを手動で貼り付けて利用。ビルド・実行は問題なし。
VS20174.8 対応一部テンプレートで DPI 関連がコメントアウトで入っていることあり既定マニフェストに asm.v3 ブロックを追記し、不要なコメント部分を整理。
VS20194.8 対応高 DPI 対応を意識したテンプレートが増加DPI/longPath 用のコメントアウト部分を活用しつつ、asm.v3 ブロックを整える。
VS20224.8 対応longPathAware がコメントアウトで含まれているテンプレートが多いlongPathAware のコメントアウトを外しつつ、PerMonitorV2 と組み合わせて利用する。

VS2013 を使い続けても良いか?

技術的には、VS2022 で作成した .NET Framework 4.8 の WinForms プロジェクトを VS2013 で開いてビルドすることも可能です。マニフェストが正しく書かれていれば、asm.v3 を使っていても問題なくコンパイル・実行できます。

ただし、以下の理由から、開発環境としては新しい Visual Studio を使うことを強くおすすめします。

  • VS2013 自体がサポート終了しており、セキュリティや安定性の面で不利。
  • 新しいテンプレートでは、DPI 対応や longPath 対応のコメントがあらかじめ用意されている。
  • デバッガやエディタの使い勝手、.editorconfig などの近年の開発スタイルに対応している。

「ビルドだけは VS2013、編集は VS2022」という混在も可能ですが、プロジェクトファイルのアップグレード等を考えると、いっそ VS2022 に統一するほうが管理は楽になります。

WinForms 側の DPI 対応設定(app.config とコード)

マニフェストで DPI 対応を宣言するだけでは、WinForms の UI が完全に自動調整されるわけではありません。特に PerMonitorV2 を有効にするときは、フォーム側の AutoScale 設定や app.config の設定も見直したほうが良いです。

app.config による高 DPI 自動リサイズの有効化

.NET Framework 4.8 の WinForms では、次のような設定を app.config に追加することがあります。

&lt;configuration&gt;
  &lt;appSettings&gt;
    &lt;add key="EnableWindowsFormsHighDpiAutoResizing" value="true" /&gt;
  &lt;/appSettings&gt;
&lt;/configuration&gt;

これは「高 DPI のときに WinForms の自動サイズ調整を積極的に行う」という意味合いのスイッチで、テンプレートのコメントに説明が書かれていることもあります。PerMonitorV2 を使う場合、UI が縮んだり崩れたりする場合はこの設定の有無を試してみると良いでしょう。

フォームの AutoScaleMode 設定

各フォームの AutoScaleMode プロパティも重要です。代表的な設定は以下の通りです。

AutoScaleMode特徴DPI 対応との相性
None自動スケーリングしない高 DPI でレイアウト崩れしやすい。原則おすすめしない。
Fontフォントを基準にスケーリング古いプロジェクトでよく使われる。DPI 変化に対しては限定的。
DpiDPI を基準にスケーリング高 DPI 対応では基本的にこれを推奨。PerMonitorV2 とも相性が良い。

既存の VS2013 プロジェクトから移行する場合、フォームの AutoScaleModeFontNone のままになっていることがあります。高 DPI 対応を本格的に行う場合は、デザイン崩れが起きない範囲で Dpi への変更を検討してください。

longPathAware の有効化と Windows 側の設定

longPathAware は、マニフェストに追加するだけで魔法のように何でも長いパスが通る、というものではありません。実際には、Windows 側で Win32 長パスを許可するポリシーが有効になっていることが前提になります。

代表的なポイントは次の通りです。

  • Windows 10 以降で、グループ ポリシーまたはレジストリの設定により「Win32 長いパスを有効にする」を ON にする必要がある。
  • アプリ側で longPathAware を true にしていない場合、OS は従来どおり MAX_PATH(260 文字)を前提とした動作を続ける。
  • 逆に longPathAware を true にしていても、OS 側の設定が OFF のままだと長いパスは相変わらず失敗する。

つまり、「OS 側の設定」+「マニフェストの longPathAware」の両輪がそろって初めて長パスが本格的に使えるようになる、という理解が重要です。

実装チェックリスト(配置場所・名前空間・VS 設定)

ここまでの内容を、実際に作業するときのチェックリストとして整理します。

項目確認内容
asm.v3 ブロックの位置</assembly> の直前に <application ...> ... </application> を配置しているか。
既定名前空間ルートの <assembly>xmlns="urn:schemas-microsoft-com:asm.v1" になっているか。
asm.v3 の宣言<application xmlns="urn:schemas-microsoft-com:asm.v3"> のように、asm.v3 の URI を正しく指定しているか。
WindowsSettings の URIdpiAware には 2005 の URI、dpiAwarenesslongPathAware には 2016 の URI を指定しているか。
プレフィックスの統一プレフィックス方式を採用している場合、開きタグ・閉じタグすべてで同じプレフィックスを使っているか。
compatibility GUID必要な OS(Windows 7/8/10/11)向けの GUID がコメントアウトされずに有効になっているか。
app.configEnableWindowsFormsHighDpiAutoResizing を必要に応じて true にしているか。
フォーム設定AutoScaleMode=Dpi(または Font から Dpi への移行)を検討したか。
Windows 側の長パス設定テスト環境の OS で Win32 長パスを有効にしているか。

Visual Studio での具体的な設定手順

共通:マニフェスト ファイルをプロジェクトに関連付ける

Visual Studio のバージョンに関係なく、基本の手順は同じです。

  1. ソリューション エクスプローラーでプロジェクトを右クリックし、「プロパティ」を開く。
  2. 「アプリケーション」タブ(または「アプリケーション」ページ)を開く。
  3. 「マニフェスト」または「アプリケーション マニフェスト」の項目を探す。
  4. 既定の app.manifest を使用するか、新規に「マニフェストの作成」から生成する。
  5. 生成された app.manifest を編集し、本記事の asm.v3 ブロックを追記する。

VS2022 テンプレートの longPathAware を活用する

VS2022 の .NET Framework WinForms テンプレートでは、あらかじめ longPathAware がコメントアウトされた状態で含まれていることがあります。その場合は、次のように進めるとスムーズです。

  1. app.manifest を開き、longPathAware がコメントになっている箇所を探す。
  2. そのコメントを削除し、本記事の asm.v3 ブロック内に移動するか、既存の windowsSettings の定義と統合する。
  3. 同時に dpiAware / dpiAwareness も追加し、PerMonitorV2 と longPathAware をまとめて設定する。

こうすることで、VS2022 テンプレートの利点(既に用意されている要素名や URI)を活かしつつ、VS2013 でもビルド可能なマニフェストを維持できます。

トラブルシューティングとよくある疑問

Q. PerMonitorV2 を指定したらフォームのサイズが変になる

A. よくある原因は以下の通りです。

  • フォームの AutoScaleModeNone または Font のまま。
  • デザイン時の DPI(96dpi など)と実行時の DPI(150% など)が大きく違うが、コントロール幅/高さを固定値で持っている。
  • EnableWindowsFormsHighDpiAutoResizing を有効にしていない。

まずは AutoScaleMode=Dpi のフォームを 1 つ試作してみて、どの程度自動調整されるかを確認すると、既存フォームをどこまで修正すべきか判断しやすくなります。

Q. VS2013 で asm.v3 を使うのは危険?

A. マニフェストは基本的に「テキスト ファイル」なので、VS2013 が asm.v3 を知らないからといってコンパイルできないわけではありません。XML として整合性が取れていれば、問題なくビルド・実行できます。むしろ重要なのは、Windows 側が asm.v3 の内容を解釈できる OS であるかという点です。

Q. Windows 7 では PerMonitorV2 はどうなる?

A. Windows 7 は PerMonitorV2 非対応です。この場合、dpiAwareness="PerMonitorV2" の宣言は無視されます。アプリが起動しなくなるわけではなく、対応していない OS では単に効果が出ないだけ、と理解しておくと安心です。

Q. 260 文字を超えるパスで例外が出る

A. 以下を順番にチェックしてください。

  1. マニフェストに longPathAware が正しく入っているか(URI も含めて)。
  2. テストしている Windows で Win32 長パスが有効になっているか。
  3. 一部の .NET API は内部で古い Win32 API を呼び出しており、longPathAware でも制限される場合があるため、パスの扱い方(\\?\ プレフィックスの付与など)を見直す必要がないか。

まとめ:閉じタグ直前に asm.v3 ブロック+新しい VS 推奨

本記事では、VB.NET の WinForms(.NET Framework 4.8)で DPI 対応と longPath 対応を行うためのマニフェスト設定と、Visual Studio のバージョン差異について解説しました。要点をあらためて整理すると次のようになります。

  • マニフェストのルートは asm.v1 のまま、閉じタグ </assembly> の直前に asm.v3 の <application> ブロックを追加する。
  • asm.v3 ブロックでは xmlns="urn:schemas-microsoft-com:asm.v3" を指定し、その中に windowsSettings > dpiAware / dpiAwareness / longPathAware を記述する。
  • 名前空間は必ず明示的に宣言し、プレフィックス方式を使うなら開き/閉じタグを統一する。
  • VS2013 でも VS2022 でも同じマニフェストでビルド可能だが、開発環境としては VS2019 / VS2022 を使うのが望ましい。
  • マニフェストだけでなく、WinForms の AutoScaleModeEnableWindowsFormsHighDpiAutoResizing などの設定も併せて見直すことで、高 DPI 環境での UI 品質が大きく向上する。
  • longPathAware は OS 側の長パス設定とセットで効果を発揮する点に注意する。

「asmv3 が定義されていない」というエラーに悩まされていた場合でも、名前空間の整理と配置場所さえ押さえれば、既存プロジェクトを大きく書き換えずに DPI/長パス対応を実現できます。ぜひ、手元の WinForms アプリでも一度マニフェストを見直してみてください。

この記事を書いた人

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

コメント

コメントする

目次