次の方法で共有

MAUI および Xamarin SDK のトラブルシューティング

重要

Visual Studio App Center は、2026 年 6 月 30 日まで引き続きサポートされる分析機能と診断機能を除き、2025 年 3 月 31 日に廃止されました。 詳細を参照してください。

詳細ログの収集

ログ レベルを VERBOSEに調整する方法については、「 その他の API」 セクションを参照してください。
詳細ログは、 Debug>Windows>Output ウィンドウで確認できます。

セットアップ中の問題

  1. Xamarin.Forms アプリの場合は、ライブラリを参照するすべてのプロジェクトにパッケージがインストールされていることを確認します。 それ以外の場合は、エラーが表示されます。
  2. Xamarin.iOS 用にビルドするときにこのエラーが表示される場合: MTOUCH: Error MT3001: Could not AOT the assembly 'obj/**/Build/Microsoft.AppCenter.**.iOS.Bindings.dll' (MT3001) Xamarin.iOS コンポーネントをバージョン 10.4.0.128 以降に更新する必要があります。
  3. Xamarin.iOS 用にビルドするときにこのエラーが表示される場合: MTOUCH: Error MT5210: Native linking failed, undefined symbol: _OBJC_METACLASS_$_MS{SomeSdkClassName}. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. (MT5210) または同様のエラー (App Center に関する同様のメッセージを含むMT5211 コード) は、特定のサービスの API を使用する前に必ず AppCenter.Start を呼び出してください。 Start呼び出しているが、この問題が発生している場合は、Xamarin.iOS コンポーネントをバージョン 10.4.0.128 以降に更新する必要があります。
  4. コンソールで、"App Center SDK が正常に構成されました" というメッセージが表示された Assert ログを探します。 これにより、SDK が正常に構成されていることが確認されます。

ポータルに分析データが表示されない

  1. SDK モジュールが正しく統合されていることを確認します。

  2. Start() メソッドの呼び出しと共に正しいアプリ シークレットが含まれていることを確認します。 ポータルでアプリを開き、[作業の開始] ページに移動して、正確な Start() コードをコピーできます。

  3. バックエンドに送信されるログを表示する場合は、アプリケーションでログ レベルを Verbose に変更すると、SDK によってコンソールにログが出力されます。 SDK を開始する前に、以下の API を呼び出します。

    AppCenter.LogLevel = LogLevel.Verbose;

    ログを確認し、"App Center SDK が正常に構成されました"（情報レベルのログ）が表示されていることを確認したら、次に HTTPS リクエストのログが表示されているかどうかを確認します。

  4. デバイスがオンラインであることを確認します。

  5. 場合によっては、ログがポータルに表示されるまでに数分かかる場合があります。 その場合はしばらく待ちます。

  6. App Center バックエンドがデータを受信したかどうかを確認するには、Analytics サービスのログ フロー セクションに移動します。 送信されると、イベントが表示されます。

クラッシュがポータルに表示されない

  1. SDK モジュールが正しく統合されていることを確認します。

  2. Start() メソッドの呼び出しと共に正しいアプリ シークレットが含まれていることを確認します。 ポータルでアプリを開き、[作業の開始] ページに移動して、正確な Start() コードをコピーできます。

  3. クラッシュ後にアプリを再起動します。 App Center のクラッシュは、再起動後にのみクラッシュ ログを転送します。 また、Xamarin.iOS と Xamarin.Mac では、デバッガーをアタッチした場合、SDK はクラッシュ ログを保存しません。 iOS アプリをクラッシュさせたときにデバッガーがアタッチされていないことを確認します。 Xamarin.Android では、デバッガーをアタッチしているときにクラッシュする可能性がありますが、ハンドルされない例外に分割した後も実行を続行する必要があります。

  4. バックエンドに送信されるログを表示する場合は、アプリケーションでログ レベルを Verbose に変更すると、SDK によってコンソールにログが出力されます。 SDK を開始する前に、以下の API を呼び出します。

    AppCenter.LogLevel = LogLevel.Verbose;

    ログを確認し、"App Center SDK が正常に構成されました"（情報レベルのログ）が表示されていることを確認したら、次に HTTPS リクエストのログが表示されているかどうかを確認します。

  5. Xamarin Insights や HockeyApp などのクラッシュ レポート機能を提供する他のライブラリは使用しないでください。 統合できるクラッシュ レポート SDK は 1 つだけです。

  6. デバイスがオンラインであることを確認します。

  7. 場合によっては、ログがポータルに表示されるまでに数分かかる場合があります。 その場合はしばらく待ちます。

  8. 次のアプリの起動時に SDK がクラッシュを検出したかどうかを確認する場合は、API を呼び出して、最後のセッションでアプリがクラッシュしたかどうかを確認し、アラートを表示できます。 または、クラッシュ コールバックを拡張して、サーバーに正常に送信されたかどうかを確認することもできます。

  9. App Center バックエンドがクラッシュを受け取ったかどうかを確認するには、Analytics サービスのログ フロー セクションに移動します。 送信されると、クラッシュがそこに表示されます。

配布とアプリ内の更新によって自動化された UI テストがブロックされている

自動 UI テストを実行している場合、アプリ内更新を有効にすると、App Center バックエンドに対する認証が試行されるため、自動 UI テストがブロックされます。 UI テストでは、App Center Distribute を有効にしないことをお勧めします。

DistributePlay を追加した後、Google Play がアプリケーションを拒否する

Google Play では、アプリ内更新の実装が含まれているため、 Distribute モジュールを使用するアプリは拒否されます。 このような状況を回避するために、App Center SDK には、メイン モジュールのスタブを含む DistributePlay モジュールがあります。 メイン アセンブリをスタブ アセンブリに置き換えます。これは、 Distribute API を模倣します。 クライアント アプリケーションで追加の変更は必要ありません。 DistributePlayには、アプリ内更新関連のコードはありません。 DistributeモジュールをアプリDistributePlayに置き換えた後も拒否される場合は、次の手順に従って、Distribute モジュールが正しく置き換えられたことを確認してください。

  • Google Play Console のすべての公開グループのすべてのリリースで、 Distribute を DistributePlay に置き換えたかどうかを確認します。
  • Xamarin.Formsを使用する場合は、共有プロジェクトとDistributePlay プロジェクトの両方に Xamarin.Android モジュールを追加してください。
  • 出力ファイルに Microsoft.AppCenter.Distribute.Android.Bindings.dll アセンブリが含まれていないことを確認します。 APK アナライザーを使用して確認できます。

iOS でデータベースを開けなかったことを示すコンソール内のメッセージ

App Center では、SQLite を使用して、バックエンドに送信される前にログを保持します。 OS によって提供されるライブラリを使用するのではなく、独自の SQLite ライブラリでアプリケーションをバンドルしている場合は、コンソール [AppCenter] ERROR: -[MSACDBStorage executeSelectionQuery:]/147 Failed to open database でこのようなエラーが表示され、バックエンドに分析情報やクラッシュ情報が表示されない可能性があります。 SDK をバージョン 0.16.0 以降に更新します。

App Center シークレット値を保護する

app_secretはアプリの識別子であり、トラフィックが適用されるアプリを把握する必要があり、既存のデータを取得または編集するために使用することはできません。 app_secretが公開されている場合、最も大きなリスクはアプリに不適切なデータを送信することですが、データのセキュリティには影響しません。

機密データを取得するには、クライアント側で生成されるアプリ/ユーザー トークンを指定する必要があります。 クライアント側のデータを完全にセキュリティで保護する方法はありません。

環境変数を使用してアプリ シークレットをコードに挿入することで、アプリのセキュリティを向上させることができます。 そうすれば、シークレットはコードに表示されません。

  • Last updated on