Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

Windows Store : créer un package et le valider avec le Windows App Certification Kit

[new:30/11/2012]Dans cette série dédiée à WinRT j’ai déjà eu l’occasion de vous présenter de nombreux aspects de la programmation sous ce nouvel environnement. La création d’un package de déploiement et sa validation avec le Certification Kit sont deux étapes cruciales avant l’accès au saint Graal : le Windows Store…

La validation étape obligatoire

Ce qui nous intéresse ici se résume à une chose : pouvoir publier une application sur le Windows Store. Pour y parvenir il y a toute une série d’étapes à franchir. Celle de l’idée, de sa mise en forme, celle de la réalisation, des tests, etc. Mais en bout de course il reste un obstacle : que l’application soit acceptée par le Windows Store qui, vous le savez certainement, utilise un processus de validation assez complexe et très strict. Louper cette étape c’est être obligé de repasser le cycle de validation ce qui a un coût au moins en tests et en temps perdu de présence sur le market place.

Le Windows App Certification Kit

Heureusement, Microsoft a eu l’excellente idée de nous fournir le WACK, le Certification Kit du Windows Store, un automate de même nature que ceux utilisés par Microsoft pour valider automatiquement les applications soumises au Windows Store. Le WACK ne teste pas tout, et certains aspects de la validation définitive restent dans les mains de Microsoft qui prend en compte des critères supplémentaires.

Toutefois ce qu’il faut en retenir est assez simple : si votre application est validée par le WACK elle peut néanmoins être rejetée par le Windows Store mais en revanche publier directement une application sans la passer sous l’œil inquisiteur du WACK est une erreur et une grosse prise de risque.

Packager pour publier, et aussi pour tester

Pour publier une application il faut la packager par un processus particulier disponible dans VS 2012. Cela est indispensable pour la soumettre au Windows Store ou même la déployer en entreprise.

Mais cette étape s’avère tout aussi indispensable pour tester l’application avec le WACK qui tente de simuler au plus près la validation réelle effectuée par Microsoft.

Construire un package

L’application

Je ne vais pas me lancer dans un grand développement ici, je vais créer une application de base en partant du modèle “blank” et lui ajouter un bouton, un évènement qui changera le contenu d’un TextBlock ainsi qu’une ou deux figures pour donner une illusion de contenu. On pourrait fort bien partir de l’application “blank” sans rien ajouter ou bien d’une application complète ou en cours de finition. Dans ce dernier cas cela permet de détecter au plus vite les éventuels problèmes que posera la certification et d’y remédier rapidement.

Donc ici nous supposons que nous disposons d’une application Windows Store, je ne détaillerai pas cette étape.

image

Comme on le voit sur la capture ci-dessus l’application ne fait pas grand chose, un clic sur le bouton “Go !” affiche la date et l’heure. Deux rectangles et un titre sont là pour donner une vague impression de contenu…

Le package

Ce qui nous intéresse vraiment ici n’est pas l’application elle-même mais de savoir comment créer un package de déploiement.

Et cela est très simple :

La première étape consiste à faire un clic droit sur le projet dans l’explorateur de solution et de sélectionner “Create App Package” dans l’option “Store” :

image

Ce qui va ouvrir un dialogue :

image

Ce dialogue vous demande si vous souhaitez diffusez l’application sur le Windows Store. La réponse est non ici, nous utiliserons le package en local uniquement pour les tests avec le WACK.

Certains liens proposés par cet écran sont de la plus grande importance, vous noterez notamment celui qui pointe vers le “sideloading” qui explique le mécanisme de déploiement d’une application WinRT en entreprise sans passer par le Windows Store. Une option dont la présence ou l’absence avait fait couler beaucoup d’encre il y a quelques mois…

Une fois le choix '”no” effectué, il faut cliquer sur “next”, ce qui amène un nouveau dialogue :

image

Les informations ne sont pas nombreuses mais essentielles :

  • Le choix de l’emplacement de sortie du package
  • Le choix de la version de l’application avec auto incrémentation ou non
  • Le choix du type de cible à tester (Neutre, x86, x64 ou ARM). Pour chaque cible il faut choisir une configuration de Build. Il doit s’agir de construction de Release et non de debug.
  • Enfin, le choix par une case à cocher d’inclure ou non les fichiers de symboles.

 

Je vous conseille de conserver certains de réglages par défaut comme l’auto incrémentation des versions et l’inclusion des fichiers de symboles.

Ne reste plus qu’à cliquer sur “Create”…

Ce qui se conclura, après une compilation réussie, par le dialogue suivant :

image

Il nous est rappelé, avec un lien cliquable ce qui est pratique, où se trouve le répertoire de stockage du package. Dans le même esprit le package qui va être testé est lui aussi indiqué par un lien qu’il suffit de suivre pour y accéder physiquement sur le disque.

Le dialogue permet surtout de lancer le WACK…

La validation par le WACK

image

Une fois le lancement du WACK validé dans le dialogue précédent le processus commence. Il se déroule en trois étapes :

La préparation

Le WACK commence par vérifier la présence de mises à jour sur le Web afin d’être le plus fidèle possible aux tests effectués sur le Windows Store. Il prépare les fichiers et passe à l’étape suivante. Cette première phase n’est pas instantanée même en l’absence de mise à jour. Il faut être patient et ne pas jouer avec l’ordinateur durant toute la phase de validation.

La validation de l’application

C’est la phase cruciale. Le WACK va lancer plusieurs fois votre application en plein écran, l’arrêter, réfléchir, etc. J’ai compté pour ce test au moins 6 lancements et arrêts de l’application. Sur ma machine de compétition cela a duré plusieurs minutes. Si vous disposez d’une machine plus standard vous aurez le temps d’aller faire un tour à la machine à café, surtout si l’application est plus grosse que l’exemple minimaliste que j’utilise ici.

Surtout ne rien toucher, ne pas tenter d’interagir avec l’application ni même avec le PC durant la validation. La présence d’autres applications exécutées en même temps ne gêne pas le processus mais pourrait le perturber et au moins le ralentir. Si votre machine n’est pas du genre monstre, je vous conseille de fermer toutes les applis et de décharger le PC des tâches non essentielles durant la validation.

Le résultat

En fin de validation le couperet tombe ! ça passe ou non…

image

Ici - et bien heureusement vu qu’il s’agit à 99% du template “blank” ! - nous voyons que notre application WinRT passe les tests avec succès. Il est possible d’accéder au rapport qui a été établi. Dans le cas présent cela ne présente guère d’intérêt mais en cas de souci ce rapport devient un outil de travail essentiel.

Le rapport généré est assez fin et balaye de nombreux aspects. Il reste consultable même après avoir fermé la fenêtre du dernier dialogue puisqu’il est généré sous la forme d’une page Html placée dans Bin\Debug (alors que cela devrait plus logiquement se trouver dans Bin\Release – petit bug ? peut-être, dans des versions précédentes de test c’était bien dans Release que le rapport était créé).

Exemple de rapport du WACK

Voici le rapport généré pour l’application de test utilisée, cela vous donnera une idée plus précise des points testés par le WACK (les petites croix représente des passages que j’ai “censurés”) :

Windows App Certification Kit - Test Results
Nom de l'application : 6946a716-6739-4020-xxxx-xxxxxxxxxxxx
Version de l'application : 1.0.0.0
Éditeur de l'application : xxxxxxxxxxxxxxxxx
Version du système d'exploitation : Microsoft Windows 8 Entreprise (x.x.xxxx.x)
Heure du rapport : xx/xx/2012 xx:xx:xx


Score général : RÉUSSITE

Test des blocages et pannes

RÉUSSITE
Tests de lancement de l'application

RÉUSSITE
Blocages et pannes

Test de conformité du manifeste de l'application

RÉUSSITE
Manifeste de l'application

Test des fonctionnalités de sécurité Windows

RÉUSSITE
Analyseur binaire

Test des API prises en charge

RÉUSSITE
API prises en charge
Test de performance

RÉUSSITE
Génération du code d'octet

RÉUSSITE
Performances du démarrage

RÉUSSITE
Performances de l'interruption

Test des ressources du manifeste de l'application

RÉUSSITE
Validation des ressources de l'application

Test de configuration de débogage

RÉUSSITE
Configuration de débogage

Codage de fichier

RÉUSSITE
Codage de fichier UTF-8

Prise en charge du niveau de fonctionnalité Direct3D

RÉUSSITE
Prise en charge du niveau de fonctionnalité Direct3D

Test des capacités des applications

RÉUSSITE
Capacités d'utilisation spéciales

Validation des métadonnées Windows Runtime

RÉUSSITE
Test de l'attribut ExclusiveTo

RÉUSSITE
Test d'emplacement du type

RÉUSSITE
Test de respect de la casse du nom du type

RÉUSSITE
Test d'exactitude du nom du type

RÉUSSITE
Test d'exactitude des métadonnées générales

RÉUSSITE
Test des propriétés


Conclusion

Malgré la complexité du processus de validation et de la soumission des applications Windows Store Microsoft a su proposer des outils parfaitement au point automatisant à la fois les tests et le déploiement.

Très franchement, WinRT est très agréable à programmer, comme du Silverlight.

Windows 8 est un excellent OS, WinRT est une plateforme de grande qualité servie par de grands outils. Le tout dans une cohérence unique sur le marché que l’annonce de Windows Phone 8 viendra celer dans peu de temps.

Enfin, et pour la première fois depuis des années, on arrête de nous proposer des copies de l’IPhone ou du Mac et de leurs interfaces totalement dépassées… Mieux, Microsoft nous offre l’opportunité rare d’un marché vierge où tout reste à faire. Que peut-il y avoir de plus passionnant que ça ? !

I’m a PC ? Depuis longtemps.

Mais aujourd’hui, I’m a Surface !

Pro MS ? C’est possible, mais lucide. Mes nombreux billets sont autant de preuves techniques et factuelles de la puissance de Windows 8, de C# et de Xaml, ai-je finalement besoin d’en dire plus ou de me sentir coupable, voire de me justifier de dire que j’aime quelque chose que je connais bien et dont j’apprécie la qualité ?

Pour moi l’avenir s’écrit en C# et en XAML, et ce depuis des années… Et ce que je vois de l’évolution de ce couple fantastique ne me donne pas envie de changer pour des ersatz de Java qui n’ont même pas le droit d’utiliser ce nom (Cf procès Oracle/Google) pas plus que des cocoa vieillots (qui datent de NeXSTEP) et mal ficelés (regardez comme un NSObject implémente un compteur cracra à côté de la gestion mémoire managée de .NET et on en reparlera…) !

Alors…

Stay Tuned !

blog comments powered by Disqus