Windows Phone : Crash au démarrage

Parfois, après un remplacement de texte hasardeux, ou après une copie de projet, il arrive que son application Windows Phone ne veuille tout simplement plus démarrer, c’est le crash fatal, inopiné et sans appel, le rideau s’abaisse après l’écran du splashscreen.

Go debug

Dans ces cas-là, le réflexe du bon vieux développeur est de placer un breakpoint dans le constructeur de l’Application et sur le UnhandledException n’est-ce pas ? Ok, allons-y, pressons F5 …

Breakpoint_01

Le suspens est à son comble, malheur ô désarroi, ce fichu mode debug ne veut pas s’arrêter sur mon breakpoint, et l’application crash toujours ! Alors que faire, si le dieu du debug n’est plus avec moi ? Voici une liste de pistes et causes possibles pour vous aider dans ce malheureux traquenard :

Build Action

Lorsqu’on copie ou ajoute comme lien l’App.xaml, le vilain a tendance à perdre son Build Action qui se réinitialise à sa valeur par défaut, à savoir Page.

Pour que l’application se lance correctement, le point d’entrée – par défaut l’App.xaml – doit absolument avoir un Build Action = ApplicationDefinition.

BuildAction

Startup object

Si le problème persiste, allons explorer les propriétés du projet…

Il se peut qu’après une manipulation (copié/collé, ajout en tant que lien…), la propriété Startup object saute et pointe dans le vide. Cette valeur est plutôt importante puisqu’il s’agit de la classe point d’entrée de l’application.

Pas de soucis, 2 clics suffisent à rétablir la situation ! Hop, on remet la valeur vers la classe Application, ici il s’agira de PhoneApp1.App :

StartupObject

AssemblyCulture

Toujours pas ?! Alors investiguons du côté de l’AssemblyInfo.cs.

Le fichier contient de nombreux attributs. Celui qui nous intéresse se nomme [AssemblyCulture].

En temps normal, vous n’avez jamais à toucher cette propriété, qui sert à spécifier une culture aux assemblies satellites. Comme notre projet est l’assembly principale, il ne faut surtout pas spécifier de valeur à l’attribut, sous peine de plantage.

AssemblyInfo

Propriétés statiques

Petit rappel sur une base du langage C# : les propriétés statiques d’une classe sont initialisées avant que la première instance soit créée, c’est-à-dire avant même de passer dans son constructeur.

Aussi, si l’App contient un champ statique qui fait planter l’application, le programme s’arrête avant même d’atteindre le constructeur App(). Du coup, le breakpoint n’est jamais atteint, et la migraine commence …

Donc pensez à vérifier les propriétés statiques de votre App !

Navigation Page

En plus du startup object qui donne le point d’entrée de l’application, vous devez également spécifier la page d’entrée de l’application. Par défaut, la valeur est MainPage.xaml. Si vous êtes un maniaque du rangement comme moi et que vous préférez stocker la page dans un sous-répertoire, il va falloir configurer cela.

Pour ce faire, il suffit de se rendre dans le manifeste (WMAppManifest.xml) et indiquer dans Navigation Page le chemin vers la page principale.

Manifest

N.B.: Si jamais vous mettez un breakpoint dans le App.UnhandledException, vous aurez un message d’erreur relativement explicite pointant vers un soucis de navigation. Ce cas se démêle donc plus facilement que les autres :)

Conclusion

En résumé et pour faire simple :

  • App.xaml : Build Action = ApplicationDefinition
  • Propriétés du projet : Startup object = MonProjet.App
  • Pas de [assembly: AssemblyCulture("XX-XX")]
  • Propriétés statiques de l’App.xaml.cs à vérifier
  • WMAppManifest.xml : Navigation Page à initialiser

Avec cette checklist, vous devriez être paré à tout et avoir une application qui se lance. C’est un bon démarrage non ? :)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>