• Home

Release Management vNext : configuration avec WebDeploy

Le déploiement d’une Web App dans Azure avec Release Management vNext est relativement simple. La tâche « Azure Web App Deployment » permet de déployer un package WebDeploy en quelques clics. Il est également possible de spécifier une « connection string » qui sera intégrée au Web.config lors du déploiement. Cependant, par défaut, impossible d’utiliser le fichier SetParameters.xml qui est un élément clé de la gestion de la configuration avec WebDeploy. Voyons comment utiliser ce fichier .

azure web app deployment

Configurer WinRM

Ceux qui utilise les nouvelles machines virtuelles dans Azure auront sans doute remarqué que WinRM n’est pas configuré par défaut. Cet état de fait pose problème notamment lors de l’utilisation de Release Management vNext car ce dernier fait un usage intensif de cette technologie. Je vais donc vous montrer comment configurer WinRM sachant que cette technique est valable pour n’importe quelle machine, aussi bien dans Azure que on premise.

WinRM, quel protocole choisir : HTTP ou HTTPS ?

Cette question est souvent la première, quel est le protocole à utiliser. La réponse est simple et est clairement expliqué dans la MSDN : l’utilisation du mode HTTP doit servir uniquement lors des phases de mise au point. Avec un environnement de production, c’est la version sécurisée qui doit être employée. Or comme on peut le constater ci-dessous, par défaut seul la version HTTP est activée, nous allons donc configurer WinRM avec HTTPS.

winrm http

AzureRM avec un agent de build vNext

Dans cet article je vais vous montrer comment utiliser la dernière version des commandes PowerShell AzureRM avec un agent de build vNext.

Différence entre Azure et AzureRM cmdlets

Un nouveau mode de gestion des ressources est apparu dans Azure : Azure Resource Management. Concrètement ce nouveau mode permet de regrouper tous les composants au sein d’un groupe de ressources et ce mode de gestion sera à terme celui qui subsistera. Il me parait donc important de capitaliser dessus pour ne pas avoir à réécrire les scripts PowerShell à l’avenir.

Mais pour bénéficier de toutes les fonctionnalités de ce nouveau mode de gestion, il faut avoir la dernière version des commandes Azure (version > 1.0.0) qui n’est pas disponible sur le Hosted Agent. C’est pourquoi nous allons installer notre propre agent avec la toute dernière version disponible.

Installation de la machine

La première chose à installer est PowerShell 5. J’ai choisi d’utiliser Chocolatey pour gagner du temps :

install powershell 5

Ensuite il faut installer les cmdlets AzureRM. Si comme moi vous avez déjà une version antérieure installée, il faudra la désinstaller au préalable :

install azurerm

La désinstallation est possible directement depuis PowerShell :

remove azure PowerShell package

Quelle version du Framework .Net est installée ?

A priori cette question peut sembler simpliste mais quand on souhaite savoir quelle version du Framework .Net est installée sur une machine, les choses ne sont pas si évidentes. Preuve en est la page de Microsoft pour répondre à cette question : msdn.

Maintenant voyons pourquoi avoir un script donnant la version peut être intéressant : dans mon cas je dois gérer un certain nombre de serveurs de builds. Or en janvier prochain, le 16 pour être précis, le support du Framework 4.5.1 sera terminé. Il faudra donc mettre à jour toutes les machines avant cette date. Or j’ai déjà installé le Framework 4.5.2 sur quelques machines, il me faut donc ce script pour déterminer la liste des machines à mettre à jour. Mais il peut également servir dans beaucoup d’autres situations.

2000px-Microsoft_.NET_Logo.svg

Build App Package avec Visual Studio Online

Dans ce nouveau billet je vais vous montrer comment créer le package d’une application Windows Store. L’objectif est d’automatiser au maximum la validation et la création du package. La seule étape manuelle restante est l’upload du package via le Dashboard du store.

Génération du numéro de version

Avant de pouvoir générer un package, il faut avoir un numéro de version unique pour ce dernier. Il existe de nombreuses options pour numéroter un package, voici donc l’option que j’ai retenue, chaque élément étant séparé par un point :

  • Un numéro de version majeur
  • Un numéro de version mineur
  • Un numéro contenant les deux derniers chiffres de l’année courante suivi du numéro du jour dans l’année
  • Le numéro de révision de la build

Cette combinaison permet d’avoir avec certitude un numéro de version unique et permet surtout d’identifier facilement un package et sa date de génération. Pour achever cette opération, la première étape consiste à créer deux variables qui contiendront les deux premiers numéros :

major minor variables

Migration Windows Phone 8.1 vers Universal App – Partie 2

Dans ce second volet de cette série d’articles sur la migration d’application Windows Phone, je vais vous montrer comment migrer la partie globalisation de votre application. Comme je l’ai dit dans un précédent article, il me semble primordiale d’avoir dans une application du store au minimum deux langues : le français (ou autre) et l’anglais. Nous allons donc voir comment gérer au mieux les différentes ressources pour internationaliser une application.

Principe général

Le principe général n’a pas changé avec Windows Phone 8.1, pour les différentes langues prises en charge, on retrouvera un ou plusieurs fichiers qui contiendront pour un élément donné la traduction correspondante. Ensuite dans l’application, plutôt que d’insérer le texte pour un bouton par exemple, on fera à la place une référence vers la ressource contenant le texte du bouton. Ensuite au chargement de l’application, en fonction des paramètres linguistiques de la machine, le bon fichier de ressources sera chargé et donc l’application sera traduite dans la bonne langue.

Mise en place des fichiers de ressources

Auparavant, l’extension utilisée était le « resx », maintenant il faut utiliser le « resw ». De plus les différents fichiers de ressources devront être placés dans une arborescence spécifique du projet comme le montre la capture ci-dessous. Le répertoire racine « strings » contient pour chaque langue souhaitée un répertoire. Et ce sont ces répertoires qui contiennent les traductions.

project structure

Pour chaque répertoire créé, une langue de traduction sera disponible. Il n’est plus nécessaire de les déclarer dans les propriétés du manifeste de l’application comme auparavant. La seule chose à configurer est la langue par défaut. Comme le montre la capture ci-dessous, il s’agit de l’anglais. Ainsi sur un poste en français, l’application sera traduite. Pour tous les autres pays, l’application sera en anglais.

manifest

Point à noter : il est également possible de traduire le manifeste en utilisant la syntaxe « ms-resource : » comme sur la capture ci-dessus.

Utilisation des traductions dans le code

L’utilisation des fichiers « resw » ne génère plus de classe d’accès aux traductions, il faut donc les créer soit même. Voici un exemple de classe permettant d’accéder aux différentes ressources depuis le code C# :

Il s’agit d’un simple singleton qui fournit un accès simplifier aux différentes ressources.

Voyons ce que cela donne dans le code XAML

C’est maintenant qu’intervient le changement majeur via l’utilisation de la propriété « x :Uid ». C’est cette dernière qui définit quelle entrée dans le fichier « resw » sera utilisée. Voici un exemple :

La première chose que l’on peut remarquer est qu’aucune mention n’est faite à la propriété « Icon » et « Label » du bouton. Et pour cause car ces dernières sont définies dans le fichier « resw » comme le montre la capture suivant :

. resw file

Ainsi pour le bouton « Account », la propriété « Label » sera remplacée par la valeur de l’entrée « Account.Label ». Ce principe est repris pour tous les composants graphiques et à un énorme avantage, vous pouvez stocker la traduction des images et de toutes les propriétés dans un seul et même emplacement.

NuGet 3.0 : what’s new ?

Le 20 juillet dernier, Microsoft nous a livré une nouvelle version du Framework .Net et de Visual Studio. Cette édition 2015 apporte son lot de nouveautés et entre autre une évolution de NuGet : la version 3.0. Je vais donc profiter de cet article pour vous montrer les différentes améliorations apportées à cet outil devenu incontournable dans le développement d’application.

nuget

Diagnostic tools avec Visual Studio 2015

Il existe plusieurs outils dans Visual Studio pour diagnostiquer les problèmes d’une application, le plus connu étant bien sur le débuggeur. Mais il est parfois utile d’avoir une vue plus élargie sur le fonctionnement de son projet. Ainsi la consommation CPU, le nombre d’objets instanciés et les différents événements peuvent mettre en lumière un éventuel problème. Pour cela il existe les « diagnostic tools » dans Visual Studio et ils sont de deux types : ceux qui donnent des informations en « live » et ceux qui collecte les informations pour ensuite les restituer de manière consolidée. Ce sont ces outils que je vais vous présenter dans cet article.

Diagnostic Live

Cet outil permet d’avoir un suivi en temps réel des différents indicateurs. Pour les activer, il suffit d’ouvrir la fenêtre suivante :

show diagnostic tools

Migration Windows Phone 8.1 vers Universal App – Partie 1

Cet article est le premier d’une série dont l’objectif est de présenter la migration d’une application Windows Phone 8/8.1 de type « Silverlight » vers une Universal App. Dans un premier temps, nous verrons comment migrer le code en utilisant les nouvelles apis. De plus même si les applications « Silverlight » seront toujours compatibles avec Windows 10, l’arrivé de ce nouvel OS est une bonne occasion pour débuter une migration. Elle permettra de tirer parti des dernières nouveautés et elle assurera également la pérennité de l’application.

windows10

Qu’est-ce qu’une « Universal App »

L’application universelle est le nouveau modèle de développement pour les applications Windows. Ce modèle permet de mutualiser le code entre toutes les plateformes. Avec l’arrivée de Windows 10 ce modèle est renforcé car il sera possible de déployer sur les téléphones, Xbox, IOT, soit l’ensemble des appareils acceptant la dernière version de l’OS de Microsoft.

IsolatedStorageSettings

Cette classe permet de stocker des informations de manière permanente. Elle est très utile par exemple pour stocker le paramétrage de l’application comme le montre l’exemple ci-dessous.

Débogage à distance avec les Remote Tools

Lors de la phase de mise au point d’une application universelle, il est impératif de tester son interface avec un écran tactile. Si comme moi votre poste de développement n’en dispose pas, il faut trouver un moyen pour déployer son application sur un autre appareil. La solution la plus simple est d’utiliser les fonctionnalités de « remote debugging » de Visual Studio. Vous pourrez ainsi déployer votre application facilement et surtout la tester avec le débogueur activé. Si en plus votre appareil cible dispose de Windows 10 comme dans cet article, vous aurez également le loisir de valider son bon fonctionnement avec le nouvel OS de Microsoft.

Installation des « remote tools »

La première étape consiste à télécharger les « remote tools » pour Visual Studio puis de les installer. Comme vous pourrez le constater sur la capture ci-dessous, il n’y a rien de compliqué, il suffit simplement de valider l’installation :

remote tools

RT @vsreleasemgmt: New features rolled out into RM service today: Parallel environments, manual promotion, queuing, deferred deployment:htt…