build

//Build 2017 Day2 – Sessions

Lors de cette journée consacrée à Windows, j’ai assisté à plusieurs sessions où malheureusement le  contenue tournaient autour de quasiment le même sujet.

App Model evolution

Dans cette session  Andrew Clinick a présenté les évolutions de l’app Model:

  • Simplification et l’amélioration de la vitesse de distribution.
  • Les delta de MAJ
  • Self UWP updating apps (pour les applications installées en dehors du store)
  • Microsoft conseille fortement l’utilisation du desktop bridge, non pas pour être dans le store, mais pour améliorer fortement l’expérience utilisateur, dans le sens où l’installation/désinstallation de l’application sera « propre » avec 0 impact sur le système.

Quelques infos sur le Desktop Bridge :

  • Il ne convertit pas les applications mais plutôt le MSI, xcopy …
  • l’application ne change quasiment pas
  • Office et Microsoft teams utilisent le desktop bridge
  • Amélioration de l’engagement des utilisateurs avec plusieurs outils :
    • Le project Rome
    • Les adaptatives cards (via la nouvelle fonctionnalité de Windows « timeline » ou via Cortana/Bots)
    • Microsoft Graph (sujet récurant lors de la build)

What’s New in TypeScript

Le nom de cette session est trompeur. Aucune nouveauté n’a été présentée. Anders Hejlsberg a déroulé exactement les mêmes slides qu’il utilise depuis plusieurs mois, avec exactement les mêmes démos.

Les nouveautés listées (ou vues lors des démos) sont celles des versions 2.0 à 2.2 et non pas des futures versions:

  • Non-nullable types
  • Literal types
  • Async Await ( pour de l’ES3/ES5)
  • type checking pour du JavaScript (dans VS Code)
  • Quick fixes (dans VS Code)
  • …

[JSS 2014] Session : BI et déploiement automatique avec TFS

Speaker : Romuald COUTAUD & Khirdine HADDAR
Level : 200

Objectif : Déploiement des solutions BI (SQL, SSIS, SSAS, SSRS) automatiquement avec TFS

Introduction :
Dans tous les projets BI, il y a différentes façons de gérer l’industrialisation de nos projets (SQL, SSIS, SSAS, SSRS). Cette session va permettre d’illustrer TFS (Team Foundation Server), l’un des moyens d’industrialisation de ces projets en automatisant la génération et le déploiement des livrables dans les différents environnements (Dev, Intégration, Prod).
Ce qui va être présenté ici, ce sont juste le versioning des solutions ainsi que la génération et le déploiement automatique des différents projets (TFS Build).

TFS :

  • Gestion des versions des projets
  • Packager les livrables
  • Build TFS
    • Extraction et copie automatique sur le serveur
    • Génération des projets (se fait à l’aide de MSBuild, un framework dotNet)
    • Déploiement

Le déploiement se fait à l’aide de WWF (Windows Workflow Foundation). Il est possible d’utiliser des scripts PowerShell pour compléter ces tâches.
Beaucoup de DLL (codeplex) ont été développées par la communauté et seront utilisées.

Outils :
SSIS : MSBuildSSIS2012 (génération & déploiement)
SSAS : SSASHelper (génération)
SSRS : SSRSMSBuildTasks

Démo : Déploiement SQL Server

  • définition du Build avec les différents arguments (deploy, environment, …)
    • fait appel à TFSBuild.exe

>> Toute la base a été déployée sur l’instance DB indiquée, avec les schémas associés.

Démo : Déploiement SSIS

  • le fichier .proj a été modifié pour prendre en compte des options non natifs
  • possibilité d’ajouter un fichier .xaml (WWF) pour avoir des options en plus aussi (BuildSSIS, …)
  • lancement du Build
    • compilation du projet SSIS + déploiement
    • le build peut se lancer aussi en ligne de commande. En changeant les paramètres, on peut facilement déployer les mêmes sources mais sur des instances différentes

Démo : Déploiement SSAS

  • mêmes procédés que précédemment à l’exception qu’un fichier de config.xml peut permettre de customiser ses différentes sources
  • comme indiqué dans la partie Outils, le codeplex pour SSAS ne permet pas de déployer les solutions SSAS. Pour la démo, un script PowerShell a été développé, permettant les déploiements

Démo : Déploiement SSRS

  • pas de surprise par rapport aux précédentes démos. La DLL, récupérée sur codeplex, met à disposition plusieurs méthodes permettant de checker l’existance d’un rapport, l’ajout/suppression d’un rapport, la modification de la source, etc.
  • les étapes de génération et déploiement restent les mêmes que précédemment

Pré-requis :

  • avoir un server TFS configuré
  • adapter tous les codeplex récupérés

Conclusion :
On entend beaucoup parler de TFS (surtout chez les dotNetiens) mais durant mes différentes missions, je n’ai pas eu l’occasion de voir cette méthode mise en place.
Très bonne session, on a pu voir qu’une fois que toutes les configurations, pour chaque type de solution, ont été mises en place, on peut facilement déployer nos solutions sur chacun de nos environnements et du coup, faciliter la tâche à nos chers collègues du support (et nous même).
Reste à voir ce que TFS peut donner avec les tests unitaires par exemple…

[TFS] Supprimer définitivement une build

Dans cet article j’aimerai expliquer comment supprimer définitivement une build, que ce soit:

  • pour libérer de l’espace dans la base de TFS (comme expliqué dans mon autre article)
  • pour résoudre un problème que je rencontre souvent, c’est celui auquel une build échoue , lorsque je la relance , celle ci echoue directement car son numéro existe déjà. La solution consiste à supprimer la 1ere build échouée (soit manuellement soit par la rétention), puis à la supprimer définitivement.

Voici donc le détails des étapes pour effectuer cette suppression définitive

Etape 1 : La suppression

Par la rétention

Dans la configuration de la définition de la build, le dernier onglet permet de configurer la rétention, c’est-à-dire le nombre de builds à conserver selon leurs statuts.

Lire la suite →

[Build 14] – How to Analyze Performance Issues in Your Windows and Windows Phone Apps

Mail de John
Samedi 5 avril 2014 20:33
How to Analyze Performance Issues in Your Windows and Windows Phone Apps

La performance est un problème d’expérience utilisateur. C’est l’utilisateur qui jugera. Avoir une application performante améliore les notes dans le store.

Les outils :
– Visual Studio
– WP 8.1 SDK VS Dev Power Tools
o Tracer l’application
– Windows Performance Toolkit
o Tracer l’application et faire une analyse approdonfie
o http://aka.ms/downloadWPT

Identifier les scenarii :
– Se focaliser les scenarii qui
o Ont une vraie valeur pour les utilisateurs
o Sont les clefs de l’utilisation de l’application
o Ont des problèmes de performances visibles
– Fast scenarios
o App launch
o Page navigation
o User Interaction
– Fluid scenarios
o Glitch free animation
o Glitch free panning
o Keeping up with the panning

Demo :
– Capturer une trace
– Localiser un scenario dans la trace
– Investiguer les problèmes de vitesse
– Investiguer les problèmes de fluidité

Cette démonstration utilise à la fois de XAML et du HTML pour montrer que WPA fonctionne dans les deux environnements à la fois sur Windows et sur Windows Phone.
John

[Build 14] – Dealing with Data : Storage, Roaming, and Backup on Windows and Windows Phone

Mail de John
Samedi 5 avril 2014 20:32
Dealing with Data : Storage, Roaming, and Backup on Windows and Windows Phone
Les problèmes à résoudre :
– Chaque localisation a une API différente
– Les interactions avec les localisations des utilisateurs sont limitées.
– Créer des applications cross-device est difficile.
– Les données précieuses des données sont piégées dans les vieux appareils des utilisateurs

StorageFile and StorageFolder :
– La plupart des contenus des fichiers sont gérés par ces classes
o Fichiers/Dossiers locaux
o File activation
o Media libraries
o Share contract
o Pickers
– Les métadonnées disponibles varient par fichier.

Description du modèle de fichiers :
– Roaming
– Local
– LocalCache
– Temp

Dans Windows Phone 8, les fichiers existants dans l’IsolatedStorage sont disponibles avec l’API WinRT.


Accéder aux contenus de l’utilisateur
Les données de l’utilisateur sont exposées via KnownFolders (RemovableDevices, MusicLibrary, PicturesLibrary, VideosLibrary) et protégées par des capabilities.


Access Cache
Il est utilisé pour maintenir l’accès aux fichiers partagés (file activation, share contract, file picker). Il est mémorisé par le système même après une suppression. Il faut quand même copier le fichier si on veut le modifier.


Storage for Windows Phone Silverlight 8.1
Nouveau modèle de données :
– Roaming/Temp/Local
– IsolatedStorage == Local Folder
– IsolatedStorage APIs fonctionnent toujours

Les KnownFolders APIs sont disponibles pour les media et cartes SD. Les API XNA fonctionnent toujours.
Démonstration (Stockage de fichiers, CommonFileQuery, Pagination, Possibilité de préciser dans l’émulateur un dossier simulant une carte SD).

Roaming
OneDrive stocke jusqu’à 100Ko, si la taille est supérieur la synchronisation s’arrête. La synchronisation entre Windows 8 et Windows Phone fonctionne.

Bonnes pratiques pour le roaming :
– Settings
– Rester sur des types WinRT
– Eviter les dépendances entre le roaming et les fichiers

Démonstration du roaming entre une application Windows et une application Windows Phone (attention il faut que les appxmanifest des deux applications aient le même PackageFamilyName)

Backup/Restore
Les données du dossier AppData sont sauvegardées une fois par jour et ce même si le Roaming est désactivé. OneDrive ne maintient qu’un seul Backup par device et par application. La taille du backup compte dans la taille du stockage OneDrive de l’utilisateur.

La fonctionnalité de sauvegarde est activée par défaut pour toutes les applications 8.1 mais pas pour les applications 8.0 ou pour les applications d’entreprise ou side-loadée. On peut désactiver ce backup soit en sauvegardant le contenu dans le dossier LocalCache ou en décochant la fonctionnalité dans le manifest.

Startscreen
Dans Windows Phone 8.1 le StartScreen avec ses tuiles est aussi sauvegardé et peut donc être restauré suite à une installation. Certaines tuiles peuvent faire références à des fichiers du stockage local qui n’existeraient plus suite à une restauration. Il faut donc s’assurer que les applications que l’on développe ne plantent pas dans ce cas.
John

 

[Build 14] – App packaging and deployment for windows

Mail de Mehdi
Samedi 5 avril 2014 10:17

App packaging and deployment for windows


Speaker : Barclay Hill, Jason Salameh


Premières nouveautés :
Seulement les ressources nécessaires (fichier de localisation, images seront téléchargées (on nous annonce un gain de 10% ou plus au niveau du stockage)

Pour les images, le système est capable de choisir quel scale d’image il lui faut.

Le speaker nous montre un projet universal app, plus précisément les manifets des projets puis, il génère une app phone, il nous montre les bundle (comme quoi ce n’est pas obligatoire mais que ça serre à optimiser les packages)

Les applications Silverlight sont générées toujours avec un xap mais sont déployés comme un appx (en plus du manifest normal on a un manifest du style Windows 8)

La création d’une application WP 8.0 est toujours possible.

Les mises à jour de 8 à 8.1 et de 8.1 Silverlight vers universal app est dans un seul sens, pas de retour en arrière possible.

Avec les applications Silverlight on joue avec deux manifest, dans cet exemple, le speaker change le mode de notification et le passe vers du WNS (dans le manifest silverlight) on voit alors que des options disparaissent, ce qui est normal puisque c’est le nouveau manifest (type Windows) qui gère ça.

Pour les nouvelles features, elles sont toutes gérées dans le nouveau manifest.

Dans le store, on peut maintenant réserver un nom d’application pour toute la « famille » phone/windows en même temps.

On parle maintenant des améliorations de stockage :

On peut partager des fichiers entre applications !
Résultat, on consomme de 10 à 25 % de mois en disque. Le speaker nous conseille de ne pas minifier les fichiers (exemple de jQuery) pour que toutes les applications qui l’utilisent, prennent un seul fichier commun.

Les utilisateurs peuvent maintenant installer des applications sur carte SD, les applications peuvent être encryptées et les développeurs peuvent interdire l’installation des apps sur les cartes SD avec une option dans le manifest.

C’est l’utilisateur qui choisit ou il installe les applications par défaut depuis l’application storage sence.

Il nous montre un exemple d’appli lourde (Halo) qui tourne très bien sur une carte SD (milieu de gamme) avec un téléphone bas de gamme.

Mehdi

[Build 14] – Windows Runtime for Windows Phone Developers

Mail de Mehdi
Vendredi 4 avril 2014 10:31

Windows Runtime for Windows Phone Developers

// Speakers : Doug Holland, Jerry Nixon

On débute la session par un petit Historique de WP (7.0 Silverlight, 7.5 Silverlight, 7.8 Silverlight, 8.0 Silverlight, 8.1 Silverlight et maintenant WinRT)
Le speaker commence par nous dire pourquoi nous devons rester sur du Silverlight : Beaucoup d’investissement (une base importante de code) utilisation de certaines API toujours pas disponible avec WinRT (exemple : VoIP, Lock Screen WP) et que Microsoft respecte nos investissements et que Silverlight pour WP continuera à être supporté/amélioré en parallèle que WinRT.

Ensuite il nous dit pourquoi nous devons re targeter nos applications en Silverlight 8.1. La réponse est simple : pour avoir accès à plusieurs nouvelles API (accès à la carte SD, GeoFencing, App Sharing)

Et enfin, il nous dit dans quel cas nous pouvons/devons choisir WinRT. Et là aussi la réponse est plutôt simple : plus de convergences (avec Windows) nouveaux contrôles (lesquels ? aucune présentation) choix de langage …

Petit rappel sur le async await (avec comme règle toute méthode qui dépasse les 50 millisecondes doit être en asynchrone pour ne pas bloquer l’interface et c’est ce qui fait dans WinRT).

Si on choisit le développement avec WinRT le speaker nous présente plusieurs API qui ne sont plus disponibles et qui sont généralement remplacées par l’API équivalente sur Windows.

Si on utilise Microsoft.Phone.Task :
– MarketplaceReviewTask n’est plus disponibleet doit être remplacé par un lacement d’une uri qui redirige vers le store
– Même chose pour le MarketplaceSearchTask
– Le WebBrowserTask est remplacé par Windows.System.Lancher.LanchUri
– AdressChooserTask remplacé par Windows.ApplicationModel.Contacts.ContactPicker
– PhoneCallTask remplacé par Windows.ApplicationModel.Cells.PhoneCallManager
– SmsComposeTask remplacé par Windows.ApplicationModel.Chat.ChatMessageManger
Microsoft.Phone.BackgroundAgent est remplacé par BackgroundTask (comme sur windows 8) avec plus de features.

La navigartion sur WP ne se fait plus par chemin, mais par type de page (comme sur windows 8)

Le bouton back ne ferme plus automatiquement l’application.

Les fichiers de localisation sont maintenant de resw en XAML nous avons maintenant x : UId l’identifiant qu’on utilise uniquement dans ces fichiers. On peut spécifier une propriété genre LeUidDunElement.text ou LeUidDunElement.Foreground.

Dernier point de la session, on nous reparle de la particularité du fileOpenPicker, quand on l’utilise on quitte l’application (elle passe donc en suspended voir elle est tuée par l’OS) donc quand on sélectionne un fichier l’application est relancée on passe par l’event activeted avec en arguement l’activation par fichier.
Mehdi

[Build 14] – Strategies for developing Cross-Device applications with Visual Studio 2013

Mail de John
Vendredi 4 avril 2014 06:09

Strategies for developing Cross-Device applications with Visual Studio 2013

 

Retour sur les choix inhérents au développement Cross Platform.

Doit-on choisir le développement natif ou le développement utilisant des technologies web ?
C’est la réponse que cherche à apporter cette session.
Natif : Plus grande flexibilité de customisation par device, accès complet au matériel, device dependant
Web : Device independant, facile à gérer mais possibilités d’intégration à la plateforme limitées.

 

Présentation de stratégies pour le développement web :

– Ne rien faire
– S’adapter au niveau du client
o Duplication minimale mais pas de customisation par device et inefficience au niveau de la bande passante
– S’adapter au niveau du serveur
o Flexibilité maximale mais probablement pas mal de duplication de code
– Tenter d’imiter le fonctionnement natif
o La meilleur expérience sur chaque device mais ce n’est toujours pas du natif

Démonstration sur le CSS et les Media Queries, Bootstrap.
Démonstration JQuery Mobile
Démonstration avec Knockout, TypeScript, Cordova.
Développement natif :

– Utiliser les outils de chaque plateforme
o Impose d’apprendre à développement avec divers IDE, langages
o Pas de partage de code
– Utiliser Xamarin
o Applications complètement native
o Utilisation de Visual Studio
o Partage de la logique du code entre chaque plateforme grâce à des PCL
o 100% des APIs de chaque device sont exposées par Xamarin

Démonstration avec Xamarin et MVVMCross (Breakpoints et remote debug Android)
John