MENU

.NET MAUI iOSをdotnet publishでIPA発行するとprovisioning file not foundになる原因とCodesignProvisionの指定方法

C#

.NET MAUIでiOSアプリを「dotnet publish」からIPA（.ipa）として発行しようとした瞬間に、署名工程で「provisioning file not found」が出て止まるケースは珍しくありません。この記事では、CodesignProvisionに何を指定すべきか、プロファイル名・UUIDの調べ方、証明書との“ペア不一致”を最短で潰す手順をまとめます。

目次

「provisioning file not found」とは何が起きているのか

エラー文のとおり、ビルド（正確にはiOSのコード署名/パッケージング工程）で必要になるプロビジョニングプロファイル（.mobileprovision）がローカルで見つからない、または指定した識別子（名前/UUID）に一致するプロファイルが解決できない状態です。

.NET MAUIのiOS発行は、最終的に「アプリ本体（.app）」へ署名し、配布可能な形（多くはIPA）にまとめる流れになります。ここで必要になるのが、次の“セット”です。

要素役割どこにあるべきか代表的な確認方法
署名証明書（Certificate）署名の本人性（チーム/発行者）を示すMacのKeychain（秘密鍵付き）xcrun security find-identity -v -p codesigning
プロビジョニングプロファイル（.mobileprovision）Bundle ID/配布方式/証明書/権限（Entitlements）を束ねる~/Library/MobileDevice/Provisioning Profiles/ファイル存在確認＋中身をデコードしてName/UUIDを見る
Bundle ID（ApplicationId）アプリの識別子。プロファイルのApp IDと一致必須プロジェクト（csproj/Info.plist等）csprojの<ApplicationId>、iOSのInfo.plist
配布方式（Development / Ad Hoc / App Store…）どこへ配布するかでプロファイルの種類が変わるApple Developer Portal上のProfilesProfilesの種別、含まれる証明書、端末登録の有無

つまり、「CodesignKeyは分かったのにCodesignProvisionが分からない」という状況は、ローカルにある（または入っているはずの）プロビジョニングプロファイルを、dotnet publishが参照できる形で指定できていないのが本質です。

CodesignKeyとCodesignProvisionの役割を分解する

結論を先に言うと、CodesignProvisionは“署名に使うプロビジョニングプロファイルの指定”です。指定方法は大きく2通りあります。

  • プロファイル名（Name）を指定する（分かりやすい）
  • プロファイルUUIDを指定する（同名が複数ある/CIで確実にしたい場合に強い）

また、ここで誤解が起きやすいのが「CodesignProvision＝ファイルパスでは？」という発想です。多くの環境では、MSBuild側がインストール済みプロファイルを検索して解決するため、まずは“名前”か“UUID”で一致させるのが確実です（同名が多いならUUIDが安定します）。

最初に固定するべき前提：Bundle IDと配布方式

プロファイルはBundle ID（App ID）と配布方式に強く紐づきます。ここが曖昧なまま進めると、プロファイルを入れても「見つからない」「一致しない」を繰り返します。

csprojでBundle ID（ApplicationId）を確認する

.NET MAUIでは、csprojの<ApplicationId>がiOSのBundle IDとして使われる構成が一般的です（プロジェクトテンプレートでもよく見ます）。iOS向けに条件分岐している場合もあるので、該当TFMを見ます。

&lt;PropertyGroup&gt;
  &lt;ApplicationId&gt;com.example.myapp&lt;/ApplicationId&gt;
&lt;/PropertyGroup&gt;

&lt;PropertyGroup Condition="'$(TargetFramework)' == 'net8.0-ios'"&gt;
  &lt;ApplicationId&gt;com.example.myapp&lt;/ApplicationId&gt;
&lt;/PropertyGroup&gt;

このcom.example.myappがApple Developer Portal側のApp ID（Identifiers）と一致している必要があります。

配布方式でプロファイルの種類が変わる

どの種類のプロファイルを作る/選ぶべきかを、簡単に整理します。

配布方式用途必要な証明書の例端末UDID登録よくあるハマりどころ
Development開発中の実機動作確認Apple Development必要Distribution証明書で署名しようとして不一致
Ad Hoc社内配布/限定配布（実機）Apple Distribution必要端末UDID未登録でインストール不可
App StoreApp Store Connectへ提出Apple Distribution不要Ad Hocプロファイルを指定してしまう
Enterprise企業内配布（要Enterprise）Enterprise系不要契約種別が違い作れない/選べない

多くの「provisioning file not found」→「直したのに別エラー」パターンは、配布方式の選択ミスが根っこにあります。まずここを決め打ちしてください。

Apple Developer Portalで“正しいプロファイル”を用意する

本質は「プロファイルが存在する」だけではなく、そのプロファイルが“今ビルドしているアプリ（Bundle ID）”と“今使う証明書（CodesignKey）”に紐づいていることです。Apple Developer Portal（Certificates / Identifiers / Profiles）側で次を満たすように作成・選択します。

  • Identifiers（App ID）：Bundle IDに一致している
  • Certificates：Development用かDistribution用かが目的と一致している
  • Profiles：上記のApp IDとCertificateが含まれている（Ad Hoc/Developmentは端末も含む）

手順の“現場感”としては、次の流れにすると迷いが減ります。

  • （未作成なら）IdentifiersでBundle IDのApp IDを作成する
  • Certificatesで必要な証明書を作成する（開発用/配布用を区別）
  • Profilesで配布方式に合うプロファイルを作成し、上のApp IDと証明書を選択して紐づける
  • プロファイル（.mobileprovision）をダウンロードする

ここで重要なのが、“その証明書を選べるプロファイル”になっているかです。例えばApp Store用プロファイルにApple Development証明書は入りません。逆も同様です。

Mac側に「証明書（秘密鍵付き）」と「プロファイル」を入れる

CLI発行でよくあるのが、Portalでは作ったつもりでも、ビルドするMacに実体が入っていないパターンです。ローカル確認はここをチェックします。

証明書がKeychainに「秘密鍵付き」で存在するか

xcrun security find-identity -v -p codesigningで表示されるのは“署名可能なID”です。ここに出ていても、Keychain上で秘密鍵が欠けていると別の署名エラーになります。Keychain Access（キーチェーンアクセス）で「マイ証明書」側に証明書の下に鍵アイコン（秘密鍵）がぶら下がっている状態を確認すると確実です。

CLIで候補を見る例：

xcrun security find-identity -v -p codesigning

ここで選ぶCodesignKeyは、目的に合わせて次のようになります。

目的CodesignKeyの例（見え方）備考
開発（実機）Apple Development: 名前 (TEAMID)Developmentプロファイルとセット
配布（Ad Hoc / App Store）Apple Distribution: 組織名 (TEAMID)Distributionプロファイルとセット

プロビジョニングプロファイル（.mobileprovision）をインストールする

インストールの最短は、ダウンロードした.mobileprovisionファイルをダブルクリックして登録する方法です（Xcodeが関連付けられていれば取り込まれます）。

インストール後は、通常次のディレクトリに配置されます。

~/Library/MobileDevice/Provisioning\ Profiles/

ここにファイルが無いなら、まず「そもそもビルドしているMacにプロファイルが入っていない」状態です。CIや別Mac（リモートMac）でビルドしている場合は特に注意してください。

CodesignProvisionに入れる値の調べ方（名前/UUID）

ここが本題です。CodesignProvisionに指定したいのは、インストール済みプロビジョニングプロファイルの識別子です。基本は「プロファイル名」、迷ったら「UUID」で固定します。

手っ取り早い方法：まずは“プロファイル名”を使う

Portalで作ったプロファイルには「名前」があります（例：MyApp AppStore、MyApp AdHocなど）。まずはこの名前をCodesignProvisionに指定してみるのが分かりやすいです。

dotnet publish -f net8.0-ios -c Release \
  -p:ArchiveOnBuild=true -p:RuntimeIdentifier=ios-arm64 \
  -p:CodesignKey="Apple Distribution: 会社名 (TEAMID)" \
  -p:CodesignProvision="MyApp AppStore"

名前指定で通らない場合の代表例は次の2つです。

  • 同名プロファイルが複数あり、解決が曖昧になる
  • 名前が微妙に違う（スペース、記号、Team Provisioning Profile系の自動生成名など）

この場合はUUID指定に切り替えると一気に安定します。

確実な方法：プロファイルのUUIDを取得して指定する

インストール済みプロファイルは、たいてい次のフォルダにあり、ファイル名自体がUUIDになっています。

ls -1 ~/Library/MobileDevice/Provisioning\ Profiles/

ただし「ファイル名＝UUID」であっても、確実性を上げるならプロファイルをデコードしてName/UUID/Bundle ID（application-identifier）を同時に見るのが安全です。

プロファイルをデコードして中身（Name/UUID）を見る

PROFILE_DIR="$HOME/Library/MobileDevice/Provisioning Profiles"

# 例：対象ファイルを指定して中身を確認

PROFILE_FILE="$PROFILE_DIR/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.mobileprovision"

# デコードしてplistとして出力

security cms -D -i "$PROFILE_FILE" > /tmp/profile.plist

# プロファイル名

/usr/libexec/PlistBuddy -c 'Print :Name' /tmp/profile.plist

# UUID

/usr/libexec/PlistBuddy -c 'Print :UUID' /tmp/profile.plist

# Bundle IDの一致確認に便利（TeamID + BundleID 形式になっていることが多い）

/usr/libexec/PlistBuddy -c 'Print :Entitlements:application-identifier' /tmp/profile.plist

# TeamIdentifier

/usr/libexec/PlistBuddy -c 'Print :TeamIdentifier:0' /tmp/profile.plist

ここで出たUUIDを、CodesignProvisionに指定します。

dotnet publish -f net8.0-ios -c Release \
  -p:ArchiveOnBuild=true -p:RuntimeIdentifier=ios-arm64 \
  -p:CodesignKey="Apple Distribution: 会社名 (TEAMID)" \
  -p:CodesignProvision="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"

UUID指定は、次のような環境で特に強いです。

  • 同じBundle IDで、Development/Ad Hoc/App Storeなど複数プロファイルが並ぶ
  • Xcodeが自動生成するプロファイル名と手動作成プロファイル名が混在する
  • CI（ビルドサーバー）で再現性を最優先したい

インストール済みプロファイルを一覧化して“正解”を見つける

どれを使えばいいか分からない場合は、インストール済みプロファイルをName/UUID/Bundle ID付きで一覧化すると、一発で候補が絞れます。

PROFILE_DIR="$HOME/Library/MobileDevice/Provisioning Profiles"

for f in "$PROFILE_DIR"/*.mobileprovision; do
  plist="/tmp/profile_$$.plist"
  security cms -D -i "$f" > "$plist" 2>/dev/null

  name=$(/usr/libexec/PlistBuddy -c 'Print :Name' "$plist" 2>/dev/null)
  uuid=$(/usr/libexec/PlistBuddy -c 'Print :UUID' "$plist" 2>/dev/null)
  appid=$(/usr/libexec/PlistBuddy -c 'Print :Entitlements:application-identifier' "$plist" 2>/dev/null)
  team=$(/usr/libexec/PlistBuddy -c 'Print :TeamIdentifier:0' "$plist" 2>/dev/null)

  rm -f "$plist"
  printf "%s\t%s\t%s\t%s\n" "$uuid" "$name" "$team" "$appid"
done

出力例の見方：

  • appidが「TEAMID.com.example.myapp」など、あなたのBundle IDと一致しているか
  • nameに「AppStore」「AdHoc」「Development」など目的に合う要素が含まれているか
  • teamが使用するApple Developer Teamと一致しているか

dotnet publishでIPAを発行するコマンド例（実用パターン）

ここでは、実務でそのままコピペして使える形に寄せた“概形”を載せます。ポイントは、CodesignKeyとCodesignProvisionが同じチーム・同じ目的で作られたペアであることです。

App Store提出用（Apple Distribution + App Storeプロファイル）

dotnet publish -f net8.0-ios -c Release \
  -p:RuntimeIdentifier=ios-arm64 \
  -p:ArchiveOnBuild=true \
  -p:CodesignKey="Apple Distribution: 会社名 (TEAMID)" \
  -p:CodesignProvision="MyApp AppStore"

Ad Hoc配布用（Apple Distribution + Ad Hocプロファイル）

dotnet publish -f net8.0-ios -c Release \
  -p:RuntimeIdentifier=ios-arm64 \
  -p:ArchiveOnBuild=true \
  -p:CodesignKey="Apple Distribution: 会社名 (TEAMID)" \
  -p:CodesignProvision="MyApp AdHoc"

開発実機用（Apple Development + Developmentプロファイル）

dotnet publish -f net8.0-ios -c Debug \
  -p:RuntimeIdentifier=ios-arm64 \
  -p:ArchiveOnBuild=true \
  -p:CodesignKey="Apple Development: 名前 (TEAMID)" \
  -p:CodesignProvision="MyApp Development"

開発用途でIPAが必須でないなら、署名やパッケージング方針を見直す余地もありますが、チーム内配布やテスト配布でIPAが必要な場面は多いので、上記の形で通る状態を作るのが実践的です。

「provisioning file not found」が消えないときの原因切り分け

同じ見た目のエラーでも、原因は複数あり得ます。再現の多いものを表にまとめます。

症状（エラーの傾向）起きがちな原因最短の対処確認ポイント
provisioning file not foundMacにプロファイルが入っていない.mobileprovisionをインストール（ダブルクリック）~/Library/MobileDevice/Provisioning Profiles/に存在するか
指定したプロファイル名で見つからない名前が違う/同名が複数UUID指定に切り替えるデコードしてName/UUIDを突合
プロファイルはあるのに署名が合わない系の後続エラー証明書とプロファイルの種別が不一致配布方式を決め直してプロファイルを作り直すDevelopment↔Distributionの混同がないか
Bundle ID不一致csprojのApplicationId変更後、古いプロファイルを使っているBundle IDに合うApp ID/プロファイルを再作成profileのapplication-identifierを確認
CIだけ失敗するCIのMacにプロファイル/証明書が入っていないプロファイルコピー＋証明書importをパイプライン化ビルド前にKeychainとProfilesをセットアップ

チェック順を固定すると解決が早い

時間を溶かさないために、次の順番で潰すのがおすすめです（現場で効く順番です）。

  1. Bundle ID（ApplicationId）を確定する（プロジェクト側）
  2. 配布方式を確定する（Development/Ad Hoc/App Store）
  3. PortalでApp IDとプロファイルが正しく作られているか確認し、プロファイルを再ダウンロードする
  4. Macへプロファイルをインストールし、Profilesフォルダに実体があるか確認する
  5. プロファイルをデコードしてName/UUID/application-identifierが期待どおりか確認する
  6. UUIDでCodesignProvisionを指定してpublishを再実行する

この流れで直らない場合は、ほぼ「証明書の秘密鍵が無い」「チームが違う」「CIのKeychainが正しくない」など、別の領域に原因があります。

CI（GitHub Actions等）で“provisioning file not found”が出やすい理由

ローカルMacだとXcodeが色々面倒を見てくれますが、CIは基本的に素のMac環境から始まるため、次の2点が欠けがちです。

  • Keychainに署名証明書（秘密鍵付き）が入っていない
  • ~/Library/MobileDevice/Provisioning Profiles/にプロファイルが置かれていない

CIで安定させるコツは、「プロファイルのインストール＝所定フォルダへ配置」と「証明書のimport＝Keychainへ追加」を必ずビルド前に行うことです。

CIでプロファイルを配置する例

（概形）ダウンロードしたプロファイルをリポジトリに直置きするのは避け、SecretsやSecure filesなどを使い、ビルド時に配置します。

mkdir -p "$HOME/Library/MobileDevice/Provisioning Profiles"

# 例：事前にUUIDを取り出してファイル名を揃える（中身のUUIDを使うのが安全）
security cms -D -i "./MyProfile.mobileprovision" > /tmp/profile.plist
UUID=$(/usr/libexec/PlistBuddy -c 'Print :UUID' /tmp/profile.plist)

cp "./MyProfile.mobileprovision" "$HOME/Library/MobileDevice/Provisioning Profiles/$UUID.mobileprovision"

この状態にしておけば、CodesignProvisionにUUIDを指定したときの再現性が高まります。

よくある質問（詰まりポイントだけ）

CodesignProvisionに「.mobileprovisionのファイル名」を入れるのは正しい？

結果としてファイル名がUUIDになっていることが多いため、UUIDを入れているのと同じになりやすいです。ただし、確実にするならデコードしてUUIDを取得し、そのUUIDを指定する方が安全です（ファイル名と中身UUIDが一致している保証を取りに行けます）。

“名前指定”が通ったり通らなかったりするのはなぜ？

主に同名プロファイルの混在が原因です。過去に作り直したプロファイルが残っていたり、Xcodeの自動生成と手動作成が混ざると、名前解決が不安定になりがちです。迷ったらUUID指定に寄せるのが実務的です。

証明書はあるのに署名で失敗する

Keychainに「証明書だけ」入っていて、秘密鍵が無いケースがあります（別Macで作った証明書をcerだけ持ってきた等）。Keychain Accessで秘密鍵付きになっているか確認し、必要なら.p12でimportします。

再発防止のチェックリスト

  • csprojのApplicationId（Bundle ID）が、PortalのApp IDと一致している
  • 配布方式（Development/Ad Hoc/App Store）を決め、その方式のプロファイルを使っている
  • CodesignKeyが目的に合う（Apple Development/Apple Distributionを混同しない）
  • プロファイルがビルドするMacに存在する（~/Library/MobileDevice/Provisioning Profiles/）
  • 同名プロファイルが多い環境ではCodesignProvisionはUUID指定に寄せる

参考（公式ドキュメント/関連情報）

C#
.NET MAUI iOS プロビジョニングプロファイル dotnet publish IPA CodesignProvision

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次