MENU

.NET MAUI 9（.NET 9）でAutofac最新版は使える？Mac環境の互換性とReleaseで動かない原因・対処

C#

.NET MAUI 9（.NET 9）をMac環境で進めていると、「Autofacの最新版はそのまま使えるの？」「デバッグ実行は動くのにRelease（発行/デバッグなし）だと落ちる…」という2つの悩みが絡みがちです。結論と、実務で迷わないための確認手順をまとめます。

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

.NET MAUI 9（.NET 9）×MacでAutofac最新版は使えるのか：結論

まず押さえておきたいのは、「参照できる（インストールできる）」と「実行時に問題なく動く（Debug/Releaseどちらも）」は別物だという点です。MAUI 9（.NET 9）でAutofacを使う場合も、ここを切り分けると判断が速くなります。

結論としては、NuGet上のAutofacは“互換性の観点では”.NET 9でも利用できる可能性が高い一方で、Microsoft側がAutofacの動作保証を公式に断言できる立場ではないため、最終判断はAutofac側の情報（NuGet/GitHub）と自分のプロジェクト条件（トリミング/AOT/リフレクション利用など）で決めるのが現実的です。

確認したいこと意味判断の目安おすすめの確認先
インストールできるかNuGet参照として追加でき、ビルドが通るか多くの場合「通る」NuGet（対象TFM）、実プロジェクトでRestore/Build
Debugで動くかローカル実行（デバッグあり）で基本機能が動くかここが通れば“まず一歩”最小構成の実機/シミュレータ/エミュレータで確認
Releaseで動くか最適化（トリミング/リンク/AOT等）が入った状態でも動くかここで差が出やすいMAUIのトリミング資料、Autofacのクロスプラットフォーム注意点

Autofacは「Microsoft公式サポート」とは別枠になる

Microsoft Q&Aの回答でも明確ですが、AutofacはMicrosoft製ではないため、Microsoft側のフォーラムで「MAUI 9でAutofac最新版が公式にサポートされる」と断言するのは難しい、という扱いになります。これは「使えない」という意味ではなく、“最終的な互換性判断はライブラリの提供元（Autofac）で確認する”という整理です。

実務的には次の2段構えにすると安全です。

  • まずNuGetの対象フレームワーク（TFM）と更新状況を見て、.NET 9で参照できそうか判断する
  • 怪しい挙動（特にReleaseのみ不具合）が出るなら、AutofacのGitHub Issuesで同様事例を探す/最小再現を添えて相談する

最新版のAutofacは何で、.NET MAUI 9（.NET 9）と噛み合うのか

NuGet上のAutofacは、最新としてAutofac 9.0.0が公開されており、.NET 8.0 / .NET Standard 2.0をターゲットにしています（.NET 9は一般に“上位互換として利用される”前提で互換扱いになりやすい構造です）。

また、ASP.NET Core系でよく使う統合パッケージのAutofac.Extensions.DependencyInjectionは、NuGet上で10.0.0が公開され、.NET 6.0 / .NET Standard 2.0をターゲットにしています。MAUI側（.NET 9）で参照する場合でも、TFMの観点では十分に噛み合うケースが多いです。

パッケージ用途NuGet上の最新（参考）主なターゲットMAUI 9で見るポイント
AutofacDIコンテナ本体9.0.0.NET 8 / .NET Standard 2.0「参照できる」だけでなく、Release最適化下での挙動（反射/スキャン）を見る
Autofac.Extensions.DependencyInjectionMicrosoft.Extensions.DependencyInjection統合10.0.0.NET 6 / .NET Standard 2.0MAUIのServiceCollectionとつなぐ要（ConfigureContainer等）

Microsoft Q&Aの実例：.NET 9 MAUIプロジェクトにAutofacを追加できる

Microsoft Q&Aには、まさに「MAUI 9（.NET 9）MacでAutofac最新版はサポートされるのか？」という質問があり、回答では次のように整理されています。

  • Autofacはサードパーティであり、Q&Aで公式サポートを断言する対象ではない
  • NuGet上では主に.NET 8向けに見えるが、一般に.NET 9は後方互換がある
  • .NET 9のMAUIプロジェクトに、当時の最新版（例：Autofac 8.2.0）をPackageReferenceとして追加できることは確認できる
  • 疑わしい場合はAutofacのGitHub Issuesで確認・相談するのが筋

そして質問者自身も、GitHub Issue作成の流れを経て「サポートされている（動作した）」旨を共有しています。

ここで大事なのは、“参照できること”と“Releaseまで含めて安定して動くこと”を分けて考えることです。後者の問題が混ざると「Autofacが原因に見える」状態になりやすいので、次章の切り分けが効いてきます。

Mac環境でハマりやすい：Debugは動くのにReleaseで落ちる原因パターン

「デバッグありだと動くのに、デバッグなし（Release実行／発行）だと動かない」は、Autofacそのものというより、Release時の最適化や挙動差が引き金になっていることがよくあります。MAUIでは特に、トリミング（リンク）やAOT、リフレクション絡みで差が出やすいです。

トリミング（ILLink）による挙動差

.NET MAUIはアプリサイズ削減のために、リンク（トリミング）を行えます。ILLinkは「使われていない」と解析されたメンバーを削除するため、反射で動的に参照する型/メソッドがあると、Releaseでだけ欠けて落ちることがあります。

特にMac絡みだと、Mac CatalystやiOSでのビルド条件が絡みます。Microsoft Learnの説明では、例えば次のような“デフォルト差”が明示されています。

  • AndroidとMac CatalystのReleaseは、既定で部分トリミングが使われる
  • iOSは実機ビルドで構成に関係なく部分トリミングが使われ、シミュレータはトリミングしない

つまり「Debugで動く」「Releaseでだけ落ちる」が成立しやすい前提が最初からあります。

「フル」トリミングやNative AOTを有効にしている

Release最適化として、Publish時にフル トリミングやNative AOTを入れていると、反射依存のコードはさらに壊れやすくなります。Microsoft Learnでも、Native AOT時には自動的にフル トリミングが走るため、TrimModeの扱いに注意する旨が書かれています。

Autofacの自動登録（アセンブリスキャン）×反射の組み合わせ

Autofacは「自動配線（コンストラクタ解決）」や「アセンブリスキャンによる登録」のような便利機能があり、これらは反射と相性が強い領域です。クロスプラットフォーム/ネイティブ環境では、反射が“そのままでは成立しない/削られる”ケースがあるため、追加の設定が必要になることがある、とAutofacドキュメントでも触れられています。

例外が表に出ない（ログ不足）

Debugではブレークや詳細例外が見えるのに、Releaseではクラッシュして「落ちた」しか分からない、という状況もあります。ここが曖昧だと、DI設定ミスなのか、リンクの影響なのか、初期化順序なのかが判断できません。Releaseで落ちる場合ほど、ログと最小再現が重要になります。

症状ありがちな原因確認ポイントまずやる対処（切り分け）
DebugはOK、ReleaseだけDI解決例外トリミングで必要な型/メンバーが消えたRelease時にトリミングが有効か一時的にトリミング影響を弱めて再現性が変わるか確認
Releaseでだけ起動直後にクラッシュAOT/最適化で初期化順が変わる、反射が失敗Publish設定、AOTの有無最小再現プロジェクトで同条件を作って現象を固定化
特定画面に遷移した瞬間に落ちる遅延解決した依存関係で反射/型解決が失敗どの型の解決で落ちるかDI解決箇所をログ化し、例外内容を確実に取る

まずはここから：最小再現（Minimal Repro）で切り分ける

「Autofacの互換性問題なのか」「MAUIのRelease最適化問題なのか」を最短で判断するには、最小再現が効きます。実務では、いきなり本番アプリの巨大な依存関係を追うより、次の順序が速いです。

手順のイメージ

  • 新規のMAUI 9プロジェクトを作る（空テンプレでOK）
  • Autofac（必要ならAutofac.Extensions.DependencyInjectionも）を追加
  • 1〜2個のサービスだけ登録して、画面表示時に解決する
  • DebugとReleaseで、それぞれ同じ操作をして差分を確認する

MAUIは標準でMicrosoft.Extensions.DependencyInjectionを使うため、Autofacを単に参照しただけでは“MAUIのDIとしては使われません”。AutofacをDIコンテナとして組み込むなら、MauiAppBuilderのConfigureContainerを使って、AutofacのServiceProviderFactoryを接続するのが王道です。Stack Overflowでも、このアプローチが具体例として示されています。

MAUIにAutofacを接続する例

using Autofac;
using Autofac.Extensions.DependencyInjection;

public static class MauiProgram
{
public static MauiApp CreateMauiApp()
{
var builder = MauiApp.CreateBuilder();


    builder
        .UseMauiApp<App>()
        .ConfigureFonts(fonts =>
        {
            fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
        })
        .ConfigureContainer(new AutofacServiceProviderFactory(), autofac =>
        {
            // ここにAutofac登録を書く（Buildは呼ばない）
            // autofac.RegisterType<MyService>().As<IMyService>().SingleInstance();
        });

    // それ以外の通常登録はbuilder.ServicesでOK
    // builder.Services.AddSingleton<...>();

    return builder.Build();
}


}

ここまで作って、Releaseのみで落ちるなら「Autofacそのもの」よりも「Release最適化×反射/型解決」の線が濃くなります。

Releaseで落ちる場合の実務的な対処：まず“原因特定”、次に“最適化と両立”

Releaseのみ不具合は、最適化を緩めると消えることが多いです。ただし、最適化を恒久的にオフにしてよいかは別問題です。おすすめは次の2段階です。

段階1：まず原因を確定させる（トリミング/リンクが犯人か）

MAUIのトリミングはILLinkが関与します。まずは「トリミングが入ると壊れるのか」を切り分けてください。Microsoft Learnでも、トリミングにより未使用メンバーが削除され、互換性のないコードは警告（trim warnings）が出るので、警告を解消しつつ十分にテストすべき、とされています。

コミュニティでも「Releaseが動かない問題は、トリミングやAOTを無効化して解決した」という報告があります（あくまで一例）。

段階2：必要なコードを“保持”して最適化と両立する

トリミングが原因だと分かったら、次は「どの型/メンバーが削られて困っているのか」を特定し、保持する方向に寄せます。MAUI（Androidのリンク設定例）では、次のような手段が案内されています。

  • DynamicDependency属性で動的参照を宣言して保持する
  • TrimmerRootAssemblyで特定アセンブリをトリミング対象から外す
  • TrimmerRootDescriptorでXMLルート指定し、型/メンバーを保持する
手段向いている状況メリット注意点
DynamicDependency自分のコード側で反射対象が分かっている必要最小限に保持できる指定漏れがあると再発しやすい
TrimmerRootAssembly外部ライブラリの内部が原因で手が出せない手早く“丸ごと保持”できるサイズ増、保持範囲が広くなりがち
TrimmerRootDescriptor（XML）保持したい型/メンバーをある程度絞れる外部ライブラリでも制御しやすい管理が増える（更新で追従が必要）

例えば、Android向けのリンク設定ドキュメントでは、XML（トリマーのディスクリプタ形式）を指定して型/メンバーを保持できることが説明されています。

Autofac側の観点：ネイティブ/クロスプラットフォームでは“反射に追加対応が必要”になり得る

Autofacのドキュメントにも、Xamarinやネイティブコンパイル環境では、反射が絡む機能のために追加作業が必要になることがある、と書かれています。例として、リンク設定でAutofacアセンブリを保持するようなXML例も挙げられています。MAUIはXamarinの後継にあたるため、考え方としては同じ罠にハマり得ます。

実務的に言うと、次のような使い方はRelease最適化の影響を受けやすいので注意が必要です。

  • アセンブリスキャンで大量に自動登録する
  • 名前や属性を頼りに型を動的に探す
  • 実行時にAssembly.Loadしてプラグイン的に読み込む

対策として、まずは「明示的登録（RegisterType/As/SingleInstanceなど）中心に寄せる」「必要なら保持設定を足す」という順で安定化させると、MAUIでは事故率が下がります。

困ったときの相談先：情報が散らばるならサポートチケットも選択肢

今回のように、Autofac互換性の話と「Releaseのみ不具合」が絡むと、コメントやスレッドが増えて情報が散らばりがちです。Microsoft Q&Aでも、複数スレッドに情報が散逸して原因特定が難しいケースはフォーラムの範囲を超えるため、MAUIのサポートチケットで状況整理してもらう提案がされています。

一方で、Autofac自体の互換性や不具合の最終判断はAutofac側になるので、最小再現（Minimal Repro）を添えてAutofacのGitHub Issuesへという動線も強力です。MAUI/ランタイム側の問題か、Autofac側の問題かを切り分けたうえで投げると、解決速度が上がります。

チェックリスト：.NET MAUI 9（.NET 9）×Autofac×Macで詰まらないために

チェック項目見るべき理由具体的なアクション
NuGetのターゲットTFMと更新日.NET 9での参照可否の一次判断になるAutofac/統合パッケージのTFMと最新版を確認
AutofacをMAUIのDIに接続できているか参照しただけではMAUIのDIは置き換わらないConfigureContainerでAutofacServiceProviderFactoryを使う
Releaseだけの差（トリミング/AOT）“DebugはOK、ReleaseはNG”の典型原因トリミング設定・Publish設定の差を把握し、保持設定を検討
最小再現が作れているか原因の切り分けと相談の質が決まる依存を減らしたプロジェクトで再現させる
相談先を間違えていないかMicrosoftとAutofacで責任範囲が違うAutofacの問題はGitHub、MAUI全体はサポートチケットも検討

この順で整理できると、「Autofac最新版は使えるの？」という疑問に対して、単なるYes/Noではなく、自分のプロジェクト条件で“どこまでが互換で、どこからが最適化との相性問題か”まで判断できるようになります。

C#
トリミング .NET MAUI Mac .NET 9 Autofac

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次