DesktopAppConverter.exe -Setup -BaseImage "BaseImage-16299.wim" -verbose

DesktopAppConverter.exe -Setup -BaseImage "BaseImage-16299.wim" -verbose

//build/ Keynote 1 - https://blogs.msdn.com/b/sbovo/archive/2014/04/03/buildjour1.aspx 

Le Keynote du jour 2 nous a inondé de nouveautés développement et Azure. Plus de 44 annonces ont été mentionnées ! Voici celles qui ont retenu mon attention.

Nous pouvons maintenant créer nos machines virtuelles directement à partir de Visual Studio. Le débogage du code Azure se fait depuis le poste client comme si l’on débugue localement un processus : Un agent de débogage est déployé sur la VM de façon transparente. C’est une fonctionnalité réellement impressionnante !

En résumé :

• JAVA est disponible pour Azure Web Sites
• Browser Link --> Ou comment modifier le code HTML client à l’aide des outils de développement Internet Explorer ; la synchronisation s’effectue de façon transparente dans le code ASP.NET !
• Les Azure Mobile Services peuvent désormais se coder en .NET
• Pour gagner du temps, une page et un client de test sont générés automatiquement pour tester nos Azure Mobile Services
• Roselyn déstructure la boite noire nommée "Compilateur" : Microsoft la rend publique et le projet devient OpenSource. Nous pouvons créer un repository local et en modifier le code C# ! L’un des premiers outils à intégrer Roselyn sera surement Xamarin.
• Nous avons la preuve que Microsoft continue ses initiatives OpenSource avec la création de .NET foundation

• Les Web Application Template supportent le mode Offline : Ce qui permet aux applications de fonctionner même déconnectées du réseau à partir du moment qu’une navigation a été faite par l’utilisateur pour charger les données en local
• AppInsights est opérationnel dans Azure
• L'expérience DevOps intégré dans le portail Azure est impressionnante
• Pour les technologies existantes : Support des APIs Office365 multiplateformes

Le portail Azure a surement demandé beaucoup de travail : il nous apparaît entièrement personnalisable et particulièrement intuitif.

Pour terminer :

• Puppet Labs est maintenant disponible sur Azure et facilite la configuration des VMs (m’en demandez pas plus:-))
• Déployer une application Azure Web Site en Staging et la basculer en production peut se faire par un simple clic (fonctionnalité nommée SWAP)  
• Traffic Manager permet d'avoir une seule entrée DNS et de router les utilisateurs vers les serveurs Azure les plus proches de leur localisation sur le globe (dans leur région géographique)
• L'authentification sur les Azure Mobiles Services peut désormais utiliser Active Directory et ceci en multi-devices
• Concernant les bases de données SQL Azure, le SLA passe à 99,95% SLA et la limite monte à 500Go

Les deux Keynotes ont tenu leurs promesses, nous n’avons plus qu’à tester et mettre en pratique toutes ces innovations !

A bientôt,

//Sebastien.

--

Pour aller plus loin, toutes les sessions sont disponibles sur https://channel9.msdn.com/Events/Build/2014.

Références :

BUILD Day 2: Keynote Summary - https://blogs.msdn.com/b/steve_fox/archive/2014/04/03/build-day-2-keynote-summary.aspx

Welcome to the .NET Foundation - https://www.dotnetfoundation.org/

Le Keynote de la 1ere journée de la conférence Build n’a pas été avare en nouveautés Windows, Windows Phone et Xbox !

Office devient moderne à la fois sur tablette/PC et sur téléphone ! Développé à partir du même code (ou pour la majeure partie) !

La nouvelle version de Windows Phone est la 8.1. Elle sera compatible avec les téléphones Lumia déjà présents sur le marché. Voici quelques unes des innovations qui sont amenées :

• Un centre d’actions regroupant entre autres les notifications des applications. Cet écran est affiché lorsque l’on fait un glissé tactile du haut de l’écran vers le bas
• Il est possible d’utiliser un fond d’écran pour notre menu de démarrage
• L’écran de verrouillage est maintenant entièrement personnalisable (pas seulement visuellement avec une image mais avec une application
• Cortana est notre nouvel(le) assistant(te) personnel(le) qui nous aidera dans toutes nos taches comme les recherches sur notre téléphone ou sur internet, le lancement/utilisation de nos applications
• WifiSense permettra de se connecter facilement à un réseau Wifi
• Le nouveau clavier Word flow est le plus rapide au monde
• Coté entreprise, le VPN fait son apparition ainsi que le chiffrement des emails (S-Mime)
• IE11, WebGL sont de la partie
• Le roaming est utilisable pour les applications Windows Phone
• La sauvegarde dans le Cloud nous permet de restaurer entièrement le menu de démarrage (que personnellement, je mets des jours a personnaliser ou optimiser :-))

Nokia annonce aussi de nouveaux téléphones dont un avec deux cartes SIM : les tuiles liées à chaque carte seront de couleurs différentes.

L’update 1 de Windows 8.1 est aussi une mine de nouveautés

• L’écran de démarrage s’enrichie d’une tuile de paramétrage ainsi que d’un bouton de recherche et de mise hors tension en haut à droite
• Le confort d’utilisation du tactile mais surtout du clavier/souris a été réellement privilégié
• Les applications modernes sont utilisables dans les fenêtres classiques de bureau
• Le Store Windows et téléphone est unifié

Les Universal Windows Apps sont disponibles dans Visual Studio 2013 Update 2 et permettent de créer à partir d’une même solution une application Windows Store et une application Windows Phone. Nous pouvons même aller jusqu’à la Xbox One !

Le code n’est pas 100% identique pour toutes les plateformes mais nous nous en rapprochons avec un projet partagé, le runtime Windows est, pour la très grande majorité des APIs, commun.

//Sebastien.

--

Pour aller plus loin, retrouvez le résumé du Keynote jour 2 - https://blogs.msdn.com/b/sbovo/archive/2014/04/03/buildjour2.aspx 

Toutes les sessions sont disponibles sur https://channel9.msdn.com/Events/Build/2014

Références :

Thoughts on Day 1 of Build 2014 - https://blogs.windows.com/windows/b/bloggingwindows/archive/2014/04/02/thoughts-on-day-1-of-build-2014.aspx 

Extending platform commonality through universal Windows apps - https://blogs.windows.com/windows/b/buildingapps/archive/2014/04/02/extending-platform-commonality-through-universal-windows-apps.aspx

Cortana (yes!) and Many, Many Other Great Features coming in Windows Phone 8.1 - https://blogs.windows.com/windows_phone/b/windowsphone/archive/2014/04/02/cortana-yes-and-many-many-other-great-features-coming-in-windows-phone-8-1.aspx

Windows 8.1 Update – important refinements to the Windows experience - https://blogs.windows.com/windows/b/windowsexperience/archive/2014/04/02/windows-8-1-update-important-refinements-to-the-windows-experience.aspx

Dans le premier article suite à la session TechDays, je vous ai présenté les points suivants :

• La méthode pour déboguer les applications lors de l’activation (par contrat ou par custom protocol par exemple)
• Le débogage de votre code lors du Suspend/Resume et le lancement de l’application après un Terminate

En parallèle, j’ai mentionné les outils

• PackageExplorer - https://www.c2i.fr/c2iPackageExplorer
• DbgView de SysInternals
• ByeBye de Christophe

Voici la suite :-)

Débogage Mémoire – Profilage Mémoire JavaScript

Pour illustrer la fonctionnalité de profilage Mémoire de Visual Studio 2013, créons un projet tout a fait standard de type Split App en Javascript :

Il vous suffit ensuite d’utiliser des images avec une grande résolution :

Et de modifier la fonction generateSampleData dans le fichier data.js pour utiliser ces images :

Testons directement l’application en activant le profilage mémoire JavaScript avec le menu ANALYSE / PERFORMANCE AND DIAGNOSTICS / JAVASCRIPT MEMORY de Visual Studio 2013 :

L’application est donc lancée. Nous pouvons l’utiliser et à tout moment revenir sur Visual Studio pour en prendre une capture mémoire en cliquant sur le bouton TAKE HEAP SNAPSHOT :

Il est ainsi possible de suivre l’évolution de la consommation mémoire de l’application en fonction de son utilisation et de prendre plusieurs captures. Visual Studio vous permet de comparer ces captures et de vous indiquer

• quels objets ont été créés
• lesquels ont été libérés

Lorsque que vous le souhaitez, utilisez le bouton STOP pour arrêter le profilage.

Nous pouvons donc visualiser les résultats dans un tableau :

Comment se fait-il que mes éléments <img> fassent 31Mo chacun alors que les images sur disque font au maximum 2,8Mo ? En définitive, nous avons des fichiers compressés et la décompression par Windows pour l’affichage créé des images de 3840*2160 = 8 Millions de pixels !

La solution dans notre cas est de fournir des images dont la résolution est adaptée à celle de l’écran mais aussi fonction du DPI.

Voici deux liens pour vous aider :

• Choosing your app images - https://msdn.microsoft.com/en-us/library/windows/apps/Hh846296.aspx
• Quickstart: Using file or image resources (Windows Store apps using JavaScript and HTML) - https://msdn.microsoft.com/en-us/library/windows/apps/hh465262.aspx

En réduisant la résolution à 800*450, nous avons plus qu’1,4Mo par tag <img> à la place de 31Mo (Nous divisons la taille par 22) ! Merci le profileur JavaScript Memory de Visual Studio !

Débogage Mémoire – Comparaison de dumps avec Visual Studio

Regardons maintenant une application C# dont la consommation mémoire est, quelque peu, inquiétante. Pour s’en rendre compte, je vous invite à utiliser Process Explorer de SysInternals et de suivre les private Bytes (Mémoire réelle utilisée). Pour le processus correspondant à notre application, nous avons une courbe de ce type :

Comment savoir qui consomme la mémoire et surtout pourquoi il ne la libère pas ?

Avant, à l’ancienne :-), je prenais 2-3 dumps de mémoire séparés par quelques secondes et les ouvrais dans WinDbg. Le but du jeu était d’essayer d’identifier les objets .NET qui étaient chargées et quels étaient leur root. C’est à dire l’objet gardant un pointeur sur eux et empêchant leur libération par le Garbage Collector.

Mais ca… C’était Avant…. Maintenant, nous prenons toujours des dumps mais nous pouvons utiliser Visual Studio !

Pour la prise de dumps, j’utilise ProcDump de SysInternals. Il vous faut juste repérer le PID du processus (dans Process Explorer par exemple) et utiliser en ligne de commande administrateur :

Prenez, par exemple, deux dumps séparés par quelques secondes d’utilisation de l’application afin d’avoir une différence de mémoire et de pouvoir ainsi comparer. Dans le cas ci-dessous, j’ai un premier dumps de 286Mo et un second de 359Mo.

Maintenant, ouvrons Visual Studio et glissons/déplacer le premier dumps à l’intérieur :

Visual Studio analyse le contenu du fichier et nous propose dans un tableau tous les objets .NET issues de notre code. Il est ainsi aussi facile de les visualiser que si nous travaillons avec un tableau Excel. Vous retrouvez donc vos structures, objets, collections d’autant plus qu’ils portent les noms que vous leur avez donné :

Le plus intéressant dans le cas d’une fuite mémoire est de pouvoir comparer deux dumps :

Le tableau s’en trouve modifié comme suivant. Il nous montre notamment les différences en préfixant les valeurs par un "+" ou "-". Je ne pense pas que l’on puisse faire plus simple !

Dans la capture ci-dessous, nous avons 6 objets de type SampleDataGroup de moins dans le premier dumps par rapport au second.

Dans la partie basse de la fenêtre, nous avons l’objet root qui _SampleDataSource. Il s’agit de notre contexte de données de l’application. Il nous reste donc à travailler sur le code afin de savoir comment nous ajoutons les SampleDataGroup à l’ObservableCollection.

--

Pour être totalement complet, il nous manque les explications/étapes correspondant à l'analyse de dumps provenant du Store.

Stay tuned!

Sebastien.

Je ne vous donne pas le lien vers les diapositives car il n’y en a pas :-) C’est l’effet de bord de notre idée “Session 100% démos” ;-)

Aussi, je vous prépare le second article sur les outils avec, entre autres,

• L’ouverture et la comparaison de dumps de mémoire avec Visual Studio 2013
• Le profiling mémoire d’applications JavaScript toujours avec Visual Studio 2013
• L’analyse d’un minidump provenant du Store avec WindDbg

A très vite,

Sebastien.

Ce livre est une référence sur l’utilisation de Bing Maps pour les applications Windows Store 8.1. Qui plus est, il est gratuit !

• Description du livre
• Téléchargement direct 

Tous les exemples sont fournis (C#, VB.NET , JavaScript) –> https://code.msdn.microsoft.com/Location-Intelligence-for-1c691d0e

Bonne lecture,

Sebastien.

Voici les premiers.

Débogage de l’activation des applications

L’exemple est le suivant : Votre application implémente le contrat de partage et plante seulement lorsqu’elle reçoit des données. Bien évidement, il va sans dire que votre application se comporte tout a fait correctement si elle est déjà lancée de façon traditionnelle.

La question posée est : Comment déboguer une application qui ne fonctionne pas (crashe) lors d’un lancement (c’est à dire une Activation) par contrat ou par protocole ?

Simplement en modifiant les propriétés du projet dans Visual Studio 2013 avec un clic droit sur le projet / Properties / Onglet Debug et en cochant

Do not launch, but debug my code when it starts

Initiez ensuite le débogage classiquement avec F5 ; Visual Studio ne lance pas l’application mais déboguera le processus dès que vous allez le lancer par quelque moyen que ce soit. Merci Visual Studio !

De la même façon, pour l’activation par protocole, activez cette option et lancez votre application par une des méthodes suivantes :

• IE moderne ou classique en tapant "VotreProtocole:Vos paramètres"

IE vous demande de confirmer le changement d’application :

L’application ActivationURI est ensuite lancée

• Touche Windows + R
• Dans la barre de l’explorateur Windows
• Par une application comme celle de Richard Clark - https://www.c2i.fr/c2iPackageExplorer 

Débogage des évènements Suspend/Resume/Terminate

Votre application plante sur du code s’exécutant lors du Suspend ou du Resume : Comment la déboguer ? En effet, si vous lancez l’application avec Visual Studio, nous n’aurons jamais de Suspend car une application WinRT déboguée n’est jamais suspendu !

Visual Studio à encore une fonctionnalité pour nous : la barre d’outils Debug Location

L’utiliser simule les évènements Suspend, Resume voire Suspend suivi par une Terminaison. Vous pouvez, de ce fait, déboguer votre code mais aussi vérifier que vous faites le nécessaire pour sauvegarder/charger l’état de votre application en cas de Terminaison.

L’exemple que nous avons montré pendant la session n’était pas une simple exception lors du Suspend. En effet, nous avons simulé un traitement long. Le plantage venait donc du dépassement du temps alloué pour l’exécution du Suspend.

D’ailleurs, pour mentionner ce temps maximum alloué, fut un temps où il était indiqué dans les Certification requirements des applications Windows Store (je me souviens de la version archivée 4.7 où le temps alloué était même de 2s !). Ce n’est plus le cas mais cela ne change pas le fait que ce temps est court et pour vous le prouver nous avons ajouté des traces dans le Suspend :

Pour les visualiser, Visual Studio nous les affiche dans la fenêtre Output lors du débogage :

Nous pouvons aussi les intercepter lorsque l’application est installée ou hors de Visual Studio avec DbgView.exe de SysInternals :

Cela confirme que notre code n’a que 5s pour travailler lors d’un Suspend. La recommandation est donc de mémoriser ce qui est important au fil de l’eau pour ne pas alourdir le traitement demandé lors d’un Suspend.

Vous allez me dire, oui ok, nous pouvons tester le Suspend hors Visual Studio car il suffit de basculer vers une autre application en plein écran et attendre que la notre soit suspendue. Mais comment simuler la Terminaison hors de Visual Studio ?

Nous avons ByeBye bien sùr ! Merci Christophe :-) L’outil se charge d’allouer le maximum de mémoire RAM afin de forcer Windows à s’alléger des applications Windows Store qui seraient en mode Suspend. Nous pouvons donc vérifier que notre application se comporte correctement lorsque nous la relançons après une Terminaison.

Il me restera à aborder dans mon prochain billet le débogage Mémoire et de dumps du Store.

Bon debug !

Sebastien.