Plantages d’App Center (Windows)

Important

Visual Studio App Center doit être mis hors service le 31 mars 2025. Bien que vous puissiez continuer à utiliser Visual Studio App Center jusqu’à ce qu’il soit entièrement mis hors service, il existe plusieurs alternatives recommandées vers lesquelles vous pouvez envisager de migrer.

En savoir plus sur les chronologies et les alternatives de support.

• Android
• iOS
• MAUI/Xamarin
• UWP
• WPF/WinForms
• React Native
• macOS
• tvOS
• Unity
• Cordova

Les incidents app Center génèrent automatiquement un journal des incidents chaque fois que votre application se bloque. Le journal est d’abord écrit dans le stockage de l’appareil et lorsque l’utilisateur redémarre l’application, le rapport d’incident est envoyé à App Center.

Le Kit de développement logiciel (SDK) App Center collecte uniquement les blocages causés par des exceptions .NET non gérées. Il ne collecte pas les plantages natifs, par exemple lors de l’utilisation de C ou C++. Toutefois, si vous avez une application avec des plantages C++, vous pouvez les charger dans App Center via l’API de chargement de plantages.

Suivez les Prise en main WPF/WinForms si vous n’avez pas encore configuré le SDK dans votre application.

Exceptions non gérées sur les applications WinForms

Notes

Cette section et les sous-sections suivantes s’appliquent uniquement à WinForms. Vous pouvez ignorer cette section si vous intégrez le Kit de développement logiciel (SDK) sur WPF.

Par défaut, une exception non prise en charge dans une application WinForms ne déclenche pas de blocage (l’application ne se quitte pas) si le débogueur n’est pas attaché.

Au lieu de cela, Windows affiche à l’utilisateur une boîte de dialogue indiquant la possibilité de continuer ou de quitter l’exécution de l’application. Par conséquent, le Kit de développement logiciel (SDK) App Center ne peut pas capturer automatiquement ces exceptions (même si l’utilisateur clique sur le bouton Quitter ).

Les incidents sont collectés sur App Center uniquement s’ils provoquent la fermeture automatique de l’application. App Center ne prend en charge qu’un seul incident par session.

Il existe deux façons de signaler des exceptions non gérées dans WinForms. L’application peut être configurée pour se bloquer sur des exceptions non gérées ou continuer à s’exécuter, mais signaler les exceptions non gérées comme des erreurs d’exécution.

Configurer l’application pour qu’elle se ferme en cas d’incident

Il s’agit de la seule façon de signaler l’exception non prise en charge en tant qu’incident sur App Center, et de faire en sorte que l’application quitte les exceptions non gérées.

Pour ce faire, appelez une méthode Windows avant d’initialiser le Kit de développement logiciel (SDK) :

Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);
AppCenter.Start(...);

Si cette option n’est pas acceptable dans votre application, vous pouvez signaler l’exception non prise en charge en tant qu’erreur d’exécution (décrite ci-dessous).

Signaler l’exception non gérée en tant qu’erreur d’exécution

Si votre application doit continuer à s’exécuter après une exception non prise en charge, vous ne pouvez pas signaler l’exception en tant qu’incident dans App Center, mais vous pouvez la signaler en tant qu’erreur.

Pour ce faire, vous pouvez utiliser l’exemple de code suivant :

Application.ThreadException += (sender, args) =>
{
    Crashes.TrackError(args.Exception);
};
AppCenter.Start(...);

Notes

Lorsque le débogueur est attaché, les exceptions non gérées entraînent la fermeture de l’application (blocages), sauf si un gestionnaire est attaché à Application.ThreadException.

Générer un incident de test

App Center Crashs vous fournit une API pour générer un plantage de test afin de tester facilement le SDK. Cette API recherche les configurations de débogage et de mise en production. Vous ne pouvez donc l’utiliser que lors du débogage, car il ne fonctionnera pas pour les applications de mise en production.

Crashes.GenerateTestCrash();

Obtenir plus d’informations sur un incident précédent

App Center Crashs a deux API qui vous donnent plus d’informations en cas de plantage de votre application.

L’application s’est-elle planté lors de la session précédente ?

À tout moment après le démarrage du Kit de développement logiciel (SDK), vous pouvez case activée si l’application s’est plantée lors du lancement précédent :

bool didAppCrash = await Crashes.HasCrashedInLastSessionAsync();

Cela s’avère utile si vous souhaitez ajuster le comportement ou l’interface utilisateur de votre application après un incident. Certains développeurs choisissent d’afficher une interface utilisateur supplémentaire pour s’excuser auprès de leurs utilisateurs, ou veulent un moyen d’entrer en contact après un incident.

Notes

Cette méthode ne doit être utilisée qu’après Crashes avoir démarré. Elle sera toujours retournée false avant le début.

Détails sur le dernier incident

Si votre application s’est plantée précédemment, vous pouvez obtenir des détails sur le dernier incident.

ErrorReport crashReport = await Crashes.GetLastSessionCrashReportAsync();

Notes

Cette méthode ne doit être utilisée qu’après Crashes avoir démarré. Elle sera toujours retournée null avant le début.

Il existe de nombreux cas d’usage pour cette API, le plus courant étant les personnes qui appellent cette API et implémentent leur délégué ou écouteur de plantage personnalisé.

Personnaliser votre utilisation des incidents d’App Center

App Center Crash fournit des rappels permettant aux développeurs d’effectuer des actions supplémentaires avant et lors de l’envoi des journaux d’incident à App Center.

Notes

Définissez le rappel avant d’appeler AppCenter.Start(), car App Center commence le traitement se bloque immédiatement après le démarrage.

Le blocage doit-il être traité ?

Définissez ce rappel si vous souhaitez décider si un incident particulier doit être traité ou non. Par exemple, il peut y avoir un incident au niveau du système que vous souhaitez ignorer et que vous ne souhaitez pas envoyer à App Center.

Crashes.ShouldProcessErrorReport = (ErrorReport report) =>
{
    // Check the report in here and return true or false depending on the ErrorReport.
    return true;
};

Demander le consentement de l’utilisateur pour envoyer un journal d’incident

Si la confidentialité des utilisateurs est importante pour vous, vous pouvez obtenir une confirmation de l’utilisateur avant d’envoyer un rapport d’incident à App Center. Le Kit de développement logiciel (SDK) expose un rappel qui indique à App Center Crashs d’attendre la confirmation de l’utilisateur avant d’envoyer des rapports d’incident.

Si vous avez choisi de le faire, vous êtes responsable de l’obtention de la confirmation de l’utilisateur, par exemple via une invite de dialogue avec l’une des options suivantes : Toujours envoyer, Envoyer et Ne pas envoyer. En fonction de l’entrée, vous indiquez à App Center crash ce qu’il faut faire et le plantage sera ensuite géré en conséquence.

Notes

Le Kit de développement logiciel (SDK) n’affiche pas de boîte de dialogue pour cela. L’application doit fournir sa propre interface utilisateur pour demander le consentement de l’utilisateur.

Notes

L’application ne doit pas appeler NotifyUserConfirmation explicitement si elle n’implémente pas de boîte de dialogue de confirmation utilisateur ; le module Crashs gère implicitement l’envoi des journaux pour vous.

Le rappel suivant montre comment indiquer au KIT de développement logiciel (SDK) d’attendre la confirmation de l’utilisateur avant de bloquer l’envoi :

Crashes.ShouldAwaitUserConfirmation = () =>
{
    // Build your own UI to ask for user consent here. SDK doesn't provide one by default.

    // Return true if you built a UI for user consent and are waiting for user input on that custom UI, otherwise false.
    return true;
};

Si vous revenez true dans le rappel ci-dessus, votre application doit obtenir (à l’aide de votre propre code) l’autorisation utilisateur et envoyer un message au SDK avec le résultat à l’aide de l’API suivante.

// Depending on the user's choice, call Crashes.NotifyUserConfirmation() with the right value.
Crashes.NotifyUserConfirmation(UserConfirmation.DontSend);
Crashes.NotifyUserConfirmation(UserConfirmation.Send);
Crashes.NotifyUserConfirmation(UserConfirmation.AlwaysSend);

Obtenir des informations sur les status d’envoi d’un journal d’incident

Parfois, vous souhaitez connaître le status de l’incident de votre application. Un cas d’usage courant est que vous souhaitez afficher l’interface utilisateur qui indique aux utilisateurs que votre application envoie un rapport d’incident ou, si votre application se bloque rapidement après le lancement, vous souhaitez ajuster le comportement de l’application pour vous assurer que les journaux d’incident peuvent être envoyés. App Center Crash fournit trois rappels différents que vous pouvez utiliser dans votre application pour être informé de ce qui se passe :

Le rappel suivant sera appelé avant que le KIT de développement logiciel (SDK) envoie un journal d’incident

Crashes.SendingErrorReport += (sender, e) =>
{
    // Your code, e.g. to present a custom UI.
};

Si nous avons des problèmes réseau ou une panne sur le point de terminaison et que vous redémarrez l’application, SendingErrorReport est à nouveau déclenché après le redémarrage du processus.

Le rappel suivant sera appelé une fois que le KIT de développement logiciel (SDK) a envoyé un journal d’incident avec succès

Crashes.SentErrorReport += (sender, e) =>
{
    // Your code, e.g. to hide the custom UI.
};

Le rappel suivant sera appelé si le KIT de développement logiciel (SDK) n’a pas pu envoyer un journal d’incident

Crashes.FailedToSendErrorReport += (sender, e) =>
{
    // Your code goes here.
};

FailedToSendErrorReport La réception signifie qu’une erreur non récupérable telle qu’un code 4xx s’est produite. Par exemple, 401 signifie que le appSecret est incorrect.

Ce rappel n’est pas déclenché s’il s’agit d’un problème réseau. Dans ce cas, le KIT de développement logiciel (SDK) continue de réessayer (et interrompt également les nouvelles tentatives lorsque la connexion réseau est interrompue).

Ajouter des pièces jointes à un rapport d’incident

Vous pouvez ajouter des pièces jointes binaires et de texte à un rapport d’incident. Le KIT de développement logiciel (SDK) les envoie avec l’incident afin que vous puissiez les voir dans le portail App Center. Le rappel suivant sera appelé juste avant d’envoyer le blocage stocké à partir des lancements d’application précédents. Il ne sera pas appelé lorsque le plantage se produit. Assurez-vous que le fichier de pièce jointe n’est pas nommé minidump.dmp , car ce nom est réservé aux fichiers minidump. Voici un exemple de la façon d’attacher du texte et une image à un incident :

Crashes.GetErrorAttachments = (ErrorReport report) =>
{
    // Your code goes here.
    return new ErrorAttachmentLog[]
    {
        ErrorAttachmentLog.AttachmentWithText("Hello world!", "hello.txt"),
        ErrorAttachmentLog.AttachmentWithBinary(Encoding.UTF8.GetBytes("Fake image"), "fake_image.jpeg", "image/jpeg")
    };
};

Notes

La limite de taille est actuellement de 7 Mo. La tentative d’envoi d’une pièce jointe plus volumineuse déclenche une erreur.

Activer ou désactiver les incidents App Center au moment de l’exécution

Vous pouvez activer et désactiver les incidents App Center au moment de l’exécution. Si vous le désactivez, le SDK n’effectuera aucun rapport d’incident pour l’application.

Crashes.SetEnabledAsync(false);

Pour réactiver les incidents true App Center, utilisez la même API, mais passez en tant que paramètre.

Crashes.SetEnabledAsync(true);

Vous n’avez pas besoin d’attendre cet appel pour rendre les autres appels d’API (par IsEnabledAsyncexemple) cohérents.

L’état est conservé dans le stockage de l’appareil au cours des lancements d’application.

Vérifier si les incidents App Center sont activés

Vous pouvez également case activée si les incidents App Center sont activés ou non :

bool isEnabled = await Crashes.IsEnabledAsync();

Erreurs gérées

App Center vous permet également de suivre les erreurs à l’aide d’exceptions gérées. Pour ce faire, utilisez la TrackError méthode :

try {
    // your code goes here.
} catch (Exception exception) {
    Crashes.TrackError(exception);
}

Une application peut éventuellement attacher des propriétés à un rapport d’erreurs géré pour fournir un contexte supplémentaire. Transmettez les propriétés sous la forme d’un dictionnaire de paires clé/valeur (chaînes uniquement) comme indiqué dans l’exemple ci-dessous.

try {
    // your code goes here.
} catch (Exception exception) {
    var properties = new Dictionary<string, string>
    {
        { "Category", "Music" },
        { "Wifi", "On"}
    };
    Crashes.TrackError(exception, properties); 
}

Vous pouvez également ajouter des pièces jointes binaires et de texte à un rapport d’erreurs géré. Transmettez les pièces jointes sous forme de tableau d’objets ErrorAttachmentLog , comme indiqué dans l’exemple ci-dessous.

try {
    // your code goes here.
} catch (Exception exception) {
    var attachments = new ErrorAttachmentLog[]
    {
        ErrorAttachmentLog.AttachmentWithText("Hello world!", "hello.txt"),
        ErrorAttachmentLog.AttachmentWithBinary(Encoding.UTF8.GetBytes("Fake image"), "fake_image.jpeg", "image/jpeg")
    };
    Crashes.TrackError(exception, attachments: attachments);
}