.NET MAUI アプリを exe で配布し、InstallShield でインストール/アンインストールすると、なぜか Windows 全体の文字が斜体(イタリック)になる――。この現象は「アプリ内フォント」と「システムフォント」の扱いが食い違ったときに起こりやすい問題です。OpenSans の役割、原因の切り分け、再発防止まで実務目線で整理します。
起きている現象を「再現手順」と「影響範囲」で整理する
まずは症状を、関係者が同じ言葉で共有できる形にまとめます。ここが曖昧だと、.NET MAUI 側・InstallShield 側のどちらを疑うべきかがブレます。
| 操作 | 結果(質問者の環境) | ポイント |
|---|---|---|
| InstallShield 2016 で作成したインストーラからインストール | インストール直後は PC のフォント表示は正常 | 「インストール時点」で OS 全体が壊れるわけではない |
| コントロールパネルからアンインストール | アプリは削除されるが、PC 全体のフォントがイタリックに見える | アンインストール処理で OS 側のフォント関連に変更が入っている疑い |
| もう一度インストール | フォント表示が元に戻る | 「削除時に崩して、追加時に戻している」パターンが濃厚 |
この時点で重要なのは、アプリ内だけのフォント崩れではなく「OS 全体の見た目」に影響しているという点です。MAUI の ConfigureFonts は本来アプリスコープの話なので、ここに食い違いがある場合、インストーラがフォントを OS に“登録”してしまっている可能性が上がります。
OpenSans は何のためのフォントか(.NET MAUI のデフォルト)
.NET MAUI のテンプレートでは、UI の見た目を一定にするために Open Sans が最初から同梱され、MauiProgram で利用登録されていることがあります。
builder.ConfigureFonts(fonts =>
{
fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
fonts.AddFont("OpenSans-Semibold.ttf", "OpenSansSemibold");
});
ここで押さえるべきポイントは次の通りです。
- AddFont は「アプリで使うフォントの登録」であり、通常は Windows 全体のシステムフォントを置き換えるものではありません。
- フォントファイルは「アプリに同梱して、アプリが参照する」設計が基本です。つまり、C:\Windows\Fonts に入れる必然性はありません。
- OpenSans は “必須コンポーネント” ではなく、見た目の統一目的のデフォルトに過ぎません。不要なら外して構いません。
言い換えると、OpenSans 自体が悪というより、OpenSans を「システムフォントとしてインストールしてしまう運用」が入ったときに、アンインストールで OS 側のフォント構成が揺らぐリスクが出ます。
「PC 全体のフォントがイタリックになる」が起こり得る理由
Windows の表示が斜体っぽく見えるとき、原因は大きく分けて次の系統に寄ります(あくまで一般的な切り口です)。
- システムフォント(例:Segoe UI)の通常スタイルが参照できなくなり、代替としてイタリック体や別フェイスが選ばれる
- フォントの登録情報(フォント名と実体ファイルの紐付け)が崩れ、Windows がフォールバックする
- フォントキャッシュが不整合になり、見た目が一時的におかしくなる
今回の症状で特に重要なのは、「アンインストール直後に壊れて、再インストールで戻る」という挙動です。これは、アプリの実行ロジックというより、インストーラが OS 側へ行った変更(追加・登録・置換)をアンインストールで“戻し切れていない”可能性を示唆します。
.NET MAUI が原因か?InstallShield が原因か?切り分けの考え方
質問内容では、Microsoft 側の検証として「MAUI アプリを通常の方法でインストール/アンインストールしても再現しなかった」「C:\Windows\Fonts にフォントが作成されず、PC 全体がイタリック化しない」という趣旨が示されています。ここから現実的な判断としては、次のように切り分けるのが妥当です。
| 観点 | MAUI 側の可能性 | InstallShield 側の可能性 |
|---|---|---|
| フォントが C:\Windows\Fonts に入る | 通常は行わない(アプリ内同梱が基本) | インストーラ設定で Fonts フォルダへ配置すると起こり得る |
| アンインストールで OS 全体の見た目が変わる | アプリ削除だけで OS のフォント設定を触る動機が薄い | フォント登録や削除、置換、参照情報の巻き戻し不備で起こり得る |
| 再インストールで元に戻る | アプリの実行だけで OS を戻すのは不自然 | インストール処理がフォント登録を再作成し、結果として回復して見える |
結論としては、MAUI 単体が Windows 全体のフォントを斜体化させる動きは考えにくく、症状のトリガーは InstallShield によるフォントの扱い(システムフォント扱いで入れている/削除が不完全)である可能性が高い、という整理になります。
そして実務上はここが重要で、サードパーティ製インストーラの挙動は .NET MAUI の範囲外になりやすいです。原因究明・修正を詰めるなら、InstallShield(Revenera)のサポート/コミュニティでの調査依頼が近道になります。
最優先の解決策:OpenSans を「OS に入れない」
この手の問題は、根本的には「OS のフォント領域に変更を入れる」運用がある限り再発の可能性が残ります。したがって最優先の方針は次のどちらかです。
- OpenSans をアプリに同梱し、アプリのローカル資産として扱う(OS に登録しない)
- OpenSans を使わず、Windows 標準フォント(例:Segoe UI)で統一する
今回のケースでは、OpenSans の登録をコメントアウトしたら再現しなくなったという経緯があるため、後者(OpenSans をやめる)が短期的に最も確実です。とはいえ、要件次第では OpenSans を継続したい場合もあるので、両方の現実解を整理します。
| 方針 | メリット | デメリット/注意点 | おすすめ度 |
|---|---|---|---|
| OpenSans を削除して OS 標準フォントへ | アンインストール時に OS フォントへ影響しづらい。運用が簡単 | UI の見た目が少し変わる可能性 | 高 |
| OpenSans を残すが「アプリ内だけ」で使う(OS に入れない) | デザインを維持しつつ安全性を上げられる | InstallShield 側の設定見直しが必要 | 中〜高 |
| OpenSans をシステムフォントとして入れる運用を続ける | 他アプリでも同フォントを使える | アンインストールや更新で OS 影響のリスクが高い | 低 |
OpenSans を削除して Windows 標準フォントだけにしてよいか
結論から言うと、不要なら削除して構いません。特に Windows 向けデスクトップ運用で、見た目の統一が OS 標準(Segoe UI など)で十分なら、OpenSans を維持する理由は薄いです。
実務での判断基準は次の通りです。
- UI/ブランド要件が厳密でない → OpenSans を外す
- 既存デザイン資産(画面キャプチャ、マニュアル、検収基準)がフォント前提 → OpenSans 継続(ただし OS へ入れない)
- 多言語対応・文字幅差が影響する画面がある → まずは フォント変更の影響確認(レイアウト崩れが出やすい)
OpenSans を削除する手順(MAUI 側)
OpenSans をやめる場合、ポイントは「登録を消す」だけでなく、参照を残さないことです。参照が残ると FontManager が読み込みを試みてエラーになります。
手順の全体像
- MauiProgram の ConfigureFonts から OpenSans 登録を削除
- プロジェクト内の OpenSans 参照(エイリアス/パス)を全消し
- 必要なら Windows 標準フォントを明示(明示しなくても既定で Segoe UI 相当になることが多い)
ConfigureFonts の削除例
builder.ConfigureFonts(fonts =>
{
// fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
// fonts.AddFont("OpenSans-Semibold.ttf", "OpenSansSemibold");
});
Windows 標準フォントを明示したい場合(例)
「アプリ内でフォントを固定したい」場合は、スタイルで指定します。XAML は HTML 出力上そのままだとタグとして解釈されるため、ここでは表示用にエスケープしています。
<Application.Resources>
<Style TargetType="Label">
<Setter Property="FontFamily" Value="Segoe UI" />
</Style>
<Style TargetType="Button">
<Setter Property="FontFamily" Value="Segoe UI" />
</Style>
</Application.Resources>
ポイントは「フォントファイルのパス」ではなく、フォントファミリー名(Segoe UI)で指定することです。Windows ではこの指定が最も安定します。
OpenSans を削除した後に FontManager のエラーが出る理由と直し方
OpenSans 関連を削除したのにログに次のようなエラーが残る場合、原因はほぼ一つです。
Error loading font 'Assets/Fonts/OpenSansRegular.ttf'.Error loading font 'Assets/Fonts/OpenSansRegular.otf'.Error loading font 'Assets/Fonts/Segoe UI.ttf'.System.InvalidOperationException: This operation is not supported for a relative URI.
これは、アプリのどこかで「まだ存在しないフォントを読もうとしている」状態です。MAUI(特に Windows/WinUI)では、ビルド時にフォント資産が Assets/Fonts のような配置に変換されることがあり、参照が残っていると FontManager がそこから読み込みを試みます。しかし、実体ファイルや登録が消えているため失敗します。
最短で直すチェックリスト
Visual Studio の「検索(Find in Files)」で、プロジェクト全体(ソリューション全体)を対象に次の文字列を洗い出してください。
| 探すべき文字列 | よく見つかる場所 | 対応 |
|---|---|---|
| OpenSansRegular / OpenSansSemibold | Styles.xaml / App.xaml / 各ページの XAML | 指定を削除、または Segoe UI に置換 |
| OpenSans-Regular.ttf / OpenSans-Semibold.ttf | .csproj / Resources\Fonts / ビルドアクション設定 | 不要ならファイルも項目も削除 |
| Assets/Fonts/OpenSans | 独自実装のフォント読み込みコード | パス参照をやめ、FontFamily 名で指定 |
| Assets/Fonts/Segoe UI.ttf | 「Segoe UI をファイルで読もうとした」痕跡 | Windows 標準フォントはファイルではなく名称で指定 |
「Segoe UI.ttf を読もうとしている」場合の注意
Windows の標準フォントは、アプリに同梱する前提ではありません。Segoe UI を “ttf ファイル” として扱って読み込もうとすると、環境差・パス差・権限差でハマりやすいです。Windows 向けに標準フォントを使いたいなら、基本は次のどちらかです。
- XAML/C# で FontFamily=”Segoe UI” のように名前で指定する
- そもそも指定せず、既定の UI フォントに任せる(Windows の標準に追従する)
例外メッセージにある「relative URI」は、相対パスを URI として扱った結果失敗しているケースでよく出ます。フォントをパスで指定する設計をやめ、エイリアス(AddFont の名前)かフォント名で指定する方が、運用コストが下がります。
OpenSans を残したい場合:アプリ内フォントとして運用する(OS に入れない)
OpenSans を残すこと自体は問題になりません。問題になりやすいのは、インストーラが OpenSans を C:\Windows\Fonts へ入れて「システムフォント」として扱うことです。
そのため、OpenSans を使いたい場合は次の方針が安全です。
- フォントは アプリのインストールフォルダ配下に配置する
- InstallShield 側で Fonts フォルダ(システム)へ配置しない
- InstallShield の「フォント登録」系の設定が入っていないか確認する
実際にどの設定が該当するかは InstallShield プロジェクトの作り方で変わりますが、目安としては以下を確認します。
- フォントファイルが「Fonts」カテゴリや FontsFolder に割り当てられていないか
- フォントを OS に登録するカスタムアクションやコンポーネントが入っていないか
- アンインストール時にフォント関連のレジストリやキャッシュに触っていないか
この部分は .NET MAUI ではなくインストーラの領域なので、原因調査が必要な場合はInstallShield(Revenera)側へ「フォントを含むインストーラのアンインストールで OS のフォント表示が斜体化する」として相談するのが現実的です。
PC がすでにイタリック表示になってしまった場合の復旧の考え方
「再インストールすると戻る」場合は、それを一時しのぎとして使えますが、根本解決にはなりません。復旧は、OS 側に残ってしまったフォントや登録情報を正しい状態に戻す方向で進めます。
確認すべき場所
- 設定:Windows の「個人用設定」→「フォント」に Open Sans が追加されていないか
- フォントフォルダ:
C:\Windows\Fontsに Open Sans が残っていないか - インストーラのログ:インストール/アンインストールでフォントを「追加」「削除」「置換」していないか
安全側の復旧ステップ(一般的な手順)
環境差が出やすい領域なので、以下は「一般的にやる順序」の提案です。作業前に復元ポイントやバックアップの準備を推奨します。
| 手順 | 狙い | 注意点 |
|---|---|---|
| Open Sans がシステムに入っているか確認し、不要なら削除 | 残骸フォントの排除 | 削除対象を誤ると別の表示崩れにつながるため慎重に |
| Windows の「既定のフォント設定を復元」相当の機能を利用 | フォント設定のリセット | 組織ポリシーや環境により操作が制限されることがある |
| フォントキャッシュの再構築(必要時) | キャッシュ不整合の解消 | 管理者権限が必要な場合がある。業務PCは手順に従う |
| それでも戻らない場合は OS/インストーラのサポートに相談 | 根本原因の特定 | InstallShield の案件として切り出すと進みやすい |
今回のように「アンインストールだけで OS 表示が変わる」場合、アプリ側の修正だけで完全に復旧しないことがあります。そのため、最終的には“OS にフォントを入れないインストール設計”へ寄せるのが再発防止として最も効きます。
再発防止のためのチェックリスト(配布前に必ず確認)
同じ問題を繰り返さないために、リリース前の最小チェックを用意しておくと安全です。特に “exe + インストーラ” で配布する場合は、環境差が出やすいので重要です。
- インストール後に C:\Windows\Fonts が増えていない(不要なシステムフォント追加がない)
- アンインストール後に OS の UI フォント表示が変わらない(見た目、文字幅、太さ、斜体)
- OpenSans を削除した場合、OpenSans の参照が 0 件である(エイリアス、パス、スタイル)
- FontManager のログに “Error loading font” が出ない
- テストは可能ならクリーンな仮想環境でも実施(既存フォント環境の影響を排除)
よくある質問
OpenSans フォントの目的は何か?本当に必要か?
OpenSans は .NET MAUI テンプレートでよく採用されている デフォルト UI フォントで、アプリの見た目をある程度統一するために同梱されます。ただし 必須ではありません。UI 要件が Windows 標準フォントで十分なら、削除して問題ありません。
不具合の原因は .NET MAUI 側なのか、InstallShield 側なのか?
MAUI のフォント登録は本来アプリ内に閉じた話で、通常は OS 全体のフォント設定を変更しません。一方で、フォントが C:\Windows\Fonts に追加される挙動や、アンインストールで OS 表示が変わる挙動は、インストーラ側の処理と整合します。したがって、現実的には InstallShield 側のフォント取り扱い(登録・削除・置換の不備)を疑うのが筋です。
問題をどう解決すればいいか?
最短の解決は次のどちらかです。
- OpenSans をやめて OS 標準フォント運用にする(最も安全で運用も軽い)
- OpenSans を使うが、OS にインストールしない(アプリ内同梱に徹する)
今回の症状は「アンインストールで OS が変わる」点が致命的なので、インストーラがシステムフォント領域を触らない設計に寄せるのが本筋です。
OpenSans を削除して Windows 標準フォントだけにしてよいか?
はい。デザイン要件がなければ、Windows 環境では Segoe UI を基準にするのが自然です。特に企業PCや共用PCでは、システム領域の変更がトラブルの温床になりやすいため、標準フォント運用は安定策になります。
OpenSans を削除したあと、FontManager のエラーが出るがどうすればよいか?
削除したフォントをまだ参照しているのが原因です。プロジェクト全体検索で OpenSans の参照(エイリアス/パス)を残さず削除し、必要なら FontFamily を Segoe UI に置換してください。特に Assets/Fonts/ のようなパス参照が残っていると、実体がないため読み込みに失敗します。
まとめ(実務での結論)
- OpenSans は .NET MAUI のデフォルト UI フォントだが必須ではない。不要なら削除してよい。
- OS 全体がイタリックになるのは MAUI の通常挙動としては考えにくい。インストーラ(InstallShield)のフォント扱いが原因になりやすい。
- 解決の近道は、フォントを OS に入れないこと。OpenSans を削除するか、アプリ内同梱に徹する。
- OpenSans 削除後の FontManager エラーは、参照が残っているだけなので、検索して置換・削除すれば解消できる。

コメント