Configuration de l’API App “Doc.Search.API”

Rendez-vous sur le portail Azure et sélectionnez les paramètres (“All Settings” en anglais) de votre API App : parmi tous les groupes de paramètres disponibles, localisez celui dénommé ‘'Fonctionnalités” (“Features” en anglais) et cliquez sur la fonction “Authentification/Autorisation” :

Activez l’authentification App Service (commutateur sur “ON”)

Ensuite, la solution initiale étant basée sur une authentification Azure Active Directory, nous continuerons donc à utiliser ce fournisseur :

1. Dans la liste des actions à entreprendre pour toute requête non authentifiée, nous sélectionnons “Login avec Azure Active Directory” car notre application n’autorise l’authentification que via Azure AD. Si toutefois vous souhaitez pouvoir offrir à vos utilisateurs la possibilité de s’authentifier avec différents fournisseurs d’identité, alors vous laisserez la valeur par défaut “Autorise les requêtes (aucune action)”. Cette option offre donc plus de flexibilité pour les applications.
2. Puis dans la liste des fournisseurs d’authentification supportés, nous opterons pour Azure Active Directory ce qui ouvrira une nouvelle fenêtre où nous sélectionnerons le mode “Express”: 
3. Notez que l’application par défaut qui sera enregistrée automatiquement dans Azure AD correspond bien à notre application DocSearchAPI. Si vous cliquez cet élément vous verrez une nouvelle fenêtre :
4. En cliquant sur “OK”, votre application  (dans notre cas “DocSearchAPI”) sera automatiquement enregistrée dans l’annuaire Azure AD par défaut (c’est-à-dire le tenant Azure AD identique à celui que vous utilisez lorsque vous accédez au portail Azure avec votre compte). C’est le mode “Express”
5. Afin de bien vérifier que votre application a bien été enregistrée dans votre annuaire Azure AD, vous pouvez vous rendre sur l’ancien portail Azure :
6. Sélectionnez ensuite l’onglet “Applications” puis votre application DocSearchAPI :

Vous noterez que le Client ID ci-dessus correspond bien au Client ID accessible à l’étape 3.

Remarques :

• Si vous souhaitez enregistrer votre application dans un autre annuaire Azure AD, c’est tout à fait possible en configurant manuellement une nouvelle application dans l’annuaire Azure AD de votre choix depuis l’ancien portail puis en reportant le Client ID correspondant dans la section “Avancé” de l’étape 2 ci-dessus. Cette configuration manuelle est décrite ici. Encore une fois, cette configuration d’authentification est d’une grande flexibilité.
• Plus besoin de configurer l’API de passerelle

Prochaine étape : enregistrer l’application Windows 10 UWP “Thot” dans Azure AD

Enregistrement de l’application Doc.SearchApp dans Azure AD

Comme nous n’utilisons plus de passerelle, il est indispensable d’enregistrer notre application native Windows 10 dans notre annuaire Azure AD afin qu’elle puisse continuer à accéder à l’API App “Doc.SearchAPI”. Pour cela rien de plus simple :

1. Rendez vous sur l’ancien portail Azure
2. Sélectionnez votre annuaire, puis l’onglet Applications. Cliquez alors sur “Ajouter” tout en bas de la page afin de créer un nouvel enregistrement d’application
3. Optez pour “ajouter une application développée par ma société” :
4. Donnez lui un nom, optez pour l’option “Application native” et cliquez sur suivant :
5. Renseignez une URI de redirection (cette URI n’a pas besoin d’être une URI réelle : c’est juste un identifiant qu’il faudra impérativement réutiliser depuis votre application native) puis validez :
6. Une fois l’application ajoutée, cliquez sur l’onglet Configurer et notez les champs Client ID et Redirect URIs (cette dernière devant correspondant à ce que vous avez saisi à l’étape 5) que vous reporterez plus tard dans le code de l’application universelle.
7. Sur la même page, scrollez jusqu’en bas de page et cliquez sur le bouton “Ajouter une application” : s’ouvre alors la fenêtre suivante :
8. Dans la fenêtre précédente, sélectionnez l’API App Doc.Search.API (sélectionnez “Affichez toutes les applications” au besoin), cliquez sur l’icône + puis validez
9. De retour sur la page principale de votre application, vous verrez alors une nouvelle permission accordée à votre application: la permission d’accéder à l’API Doc.Search.API. Attention : par défaut cette permission n’est pas active (le compteur “Delegated Permissions” est à 0) : pour l’activer dérouler la liste et cochez la case “Accès Doc.Search.API). Puis sauvegardez le tout.
10. 

Et voilà l’application universelle native est dorénavant autorisée à accéder à l’API app “Doc.Search.API” sous réserve que l’utilisateur soit bien référencé dans l’annuaire Azure AD.

Dernière étape : modifier l’application Windows 10 UWP “Thot” afin d’utiliser la librairie ADAL (Active Directory Authentification Library

Evolution du code de l’application universelle Thot

L’application universelle initiale utilisait une librairie dénommée Microsoft Azure AppService SDK. Cette librairie qui fonctionnait avec l’API de passerelle est aujourd’hui marquée comme obsolète (deprecated en anglais). Il nous faut donc impérativement remplacer ce SDK par une autre librairie nous permettant de réaliser l’authentification de l’utilisateur. C’est là qu’intervient la librairie d’authentification ADAL. Cette librairie a été implémentée pour différentes plateformes/langages (iOS, Android, Web, Cordova etc). Par conséquent vous avez la possibilité d’appliquer cette solution pour une application native autre que Windows 10.

1. Ajouter une référence à la librairie ADAL dans le projet d’application universelle Doc.Search.App. Pour cela, utiliser le gestionnaire de package nuget :
2. Ensuite voici la liste des fichiers à modifier par rapport au projet initial :
   • MainViewModel.cs
   • TokenExpiredHandler.cs
   • ThotSettings.cs
3. Fichier MainViewModel.cs : nous allons y définir l’URL du service d’authentification Azure AD, un jeton d’accès (Token)  et nous allons instancier la librairie ADAL (objet AuthenticationContext) :
4. Notez au passage la mise en commentaire de l’objet IAppServiceClient faisant parti du SDK Azure AppService, aujourd’hui déprécié.
5. Puis nous allons modifier le délégué de la gestion d’authentification pour déclencher l’authentification Azure AD de l’utilisateur via la méthode ADAL AcquireTokenAsync : en cas de succès nous renvoyons le jeton d’accès qui sera passé dans le header http de toute requête ultérieure :
6. Fichier TokenExpiredHandler.cs : nous allons modifier une seule méthode qui aura la responsabilité d’appeler l’API App en positionnant le jeton d’authentification (récupéré via le délégué d’authentification) dans le header http (propriété “Authorization”) de la requête web :
7. Fichier ThotSettings.cs : il contient un certain nombre de constantes correspondant aux identifiants AAD de l’application native (Client ID et Redirect URI), à l’URL de base de l’API App et aux identifiants du fournisseur d’identité AAD (URL d’authentification + identifiant du tenant AAD)
8. En lançant l’application Thot, il nous est alors demander de nous authentifier avec notre compte Azure AD :
9. Une fois authentifié, je peux alors faire une requête de recherche :

Et voilà : j’espère que cet article vous aura convaincu quant à la grande flexibilité et simplicité de ce nouveau modèle d’authentification des “Azure App Services” qui peut facilement s’appliquer à tout type de plateforme native ou web. En quelques clics + quelques lignes de codes, il est donc très simple de sécuriser l’accès à une API dans un contexte d’entreprise. Maintenant il est temps pour moi de discuter avec Stéphane car le bleu utilisé dans son application me pique un peu les yeux

A bientôt pour de nouveaux articles autour d’Azure et Windows 10

1. Faciliter la relation « business » entre un éditeur et ses clients

2. Proposer aux organisations un moyen simple d’accès à des applications dites « métier » (aussi dénommées « LOB – Line O Business)

Comment cela fonctionne t-il ? C’est tout l’objectif de cet article

Ce schéma illustre les différents acteurs impliqués dans la distribution et l’utilisation d’applications modernes ainsi que les plateformes mises en œuvre pour faciliter ces actions.

Rôles

Nous distinguons 3 rôles :

1. L’éditeur de logiciel (aussi appelé ISV – Independent Software Vendor) dont un des objectifs est de vendre ses logiciels via un store d’application

2. L’administrateur IT d’une organisation dont un des rôles est de mettre à disposition des employés des logiciels dans le respect des politiques IT (sécurité, licence etc)

3. Les employés qui utilisent des logiciels depuis une machine (ordinateur, tablette ou smartphone) administrée par l’entreprise

Point de vue « Employé »

Un employé pourra selon les politiques de sécurité IT en vigueur, accéder au magasin public d’applications (Public store) et/ou accéder au magasin privé d’applications (Private Store).

Les prérequis logiciels et matériels sont les suivants :

• Disposer d’une machine sous Windows 10 (Obligatoire)
• Disposer d’un compte Microsoft (MSA) pour accéder au store public [Optionnel]
• Disposer d’un compte Azure Active Directory (AD) pour accéder au store privé [Optionnel]

L’accès aux applications se fera depuis l’application Store présente nativement aussi bien sur Windows 10 que Windows 10 mobile :

Comme vous pouvez le constater sur l’illustration précédente, l’accès au store privé est bien intégré via la mise à disposition d’un nouvel onglet (ici « DemoZone9.com ») correspondant à l’identifiant unique de son organisation. A noter que ce store privé est accessible uniquement si l’employé est authentifié avec son compte Azure AD.

Et voici à quoi ressemble un store privé (lorsqu’on clique sur « DemoZone.9.com) :

Sont visibles ici deux catégories d’applications :

1. Les applications dites grand public (B2C)

2. Les applications dites « métier » (B2B) aussi appelées « LOB – Line Of Business » identifiables par le libellé « Propriétaire »

Les applications éligibles à la diffusion via le store privé sont :

• Les applications Windows 10 Universelles (UWP)
• Les applications universelles Windows 8 et Windows Phone 8

Remarques

• Le contenu du store privé est défini et contrôlé par l’administrateur IT de l’organisation
• L’onglet « DemoZone9.com » est visible et accessible uniquement par les employés de l’organisation
• Les utilisateurs doivent s’authentifier avec leur compte Azure AD

Démo

Vous trouverez ici une vidéo de démonstration du store privé

Point de vue « Editeur/Développeur »

Avec Windows 10 et le store pour les entreprises, un éditeur de logiciels peut désormais gérer le cycle de vie de ses applications métiers depuis l’interface de publication Windows Dev Center.

Côté prérequis, l’éditeur doit simplement disposer d’un compte de développement Windows, compte individuel ou entreprise. Plus d’infos ici

Lors de la publication d’applications, un éditeur a désormais la possibilité de choisir le mode de gestion et distribution de licence :

Licence en ligne (Online)

C’est le modèle sélectionné par défaut permettant  :

1. aux applications d’un éditeur d’être visibles dans le store pour entreprises.
2. de gérer les licences automatiquement : en effet dans ce mode, la validation de licence est gérée par le Store Microsoft de manière similaire aux applications publiques.

Une conséquence est que les employés d’une organisation ayant fait l’acquisition d’une application en mode online ne pourront y accéder que depuis un équipement (smartphone, tablette ou PC) connecté au store Windows, connexion indispensable pour l’acquisition de l’application et de sa licence associée.  Cela signifie que l’organisation ayant fait l’acquisition ne peut accéder physiquement à l’application et sa licence. Elle pourra toutefois contrôler le déploiement sur son parc.

License hors-ligne (Offline)

Ce mode n’est pas activé par défaut : les développeurs doivent explicitement cocher l’opt-in correspondant qui permettra aux entreprises clientes de télécharger les licences et applications pour les déployer dans leur infrastructure IT. Quelques conséquences directes liées à ce mode :

• Aucune connexion au store Windows n’est requise pour la flotte entreprise : autrement dit il est possible d’opérer un mode de déploiement de type side-loading.
• La gestion des licences des applications acquises est à charge des entreprises comme pour une gestion de logiciels traditionnelle
• L’accès aux applications à licence hors-ligne ne nécessite pas de comptes Azure AD pour les employés
• Le déploiement peut être réalisé via des outils de gestion (SCCM, MDM, autres)

Remarques

• Si aucune option de licence n’est sélectionnée, les applications correspondantes seront uniquement disponibles sur le store grand public.
• Il est possible de sélectionner les deux modes de licence en parallèle

Application métier (LOB – Line Of Business)

La question en suspens est de savoir comment faire en sorte qu’une application métier ne soit visible que pour un client unique. Comme nous le verrons en troisième partie de cet article (Point de vue de l’administrateur IT d’une organisation), un administrateur IT pourra configurer depuis l’interface du “store entreprises” les éditeurs reconnus officiellement :

Une fois que l’administrateur IT vous aura ajouté dans sa liste d’éditeurs de confiance, vous recevrez une demande d’acceptation par email :

En vous rendant sur votre interface de notification …

… vous pourrez alors accepter la demande de mise en relation. Une fois la demande acceptée, vous pourrez soumettre une application métier à destination de l’entreprise pour laquelle vous aurez accepter la mise en relation. Dans la section “Distribution et visibilité”, vous pourrez sélectionner “Distribution métier (LOB)”. Apparaitra alors les comptes clients pour lesquelles vous pourrez publier une application privée :

Remarques

• il est possible de distribuer la même application LOB à différentes entreprises
• Une application LOB est soumise à validation Microsoft. A ce titre elle doit respecter les Windows Store Policies
• La certification est pris en charge par Microsoft
• Il est possible de faire un déploiement d’application LOB en mode side-loading

Démo

Vous trouverez ici une vidéo démontrant la publication d’une application LOB

Point de vue « Administrateur IT d’une organisation »

Jusqu’ici nous avons vu :

1. comment un employé d’une organisation pouvait accéder à une application métier depuis un store privé
2. comment un éditeur de logiciel pouvait vendre et distribuer une application métier à destination d’une organisation

Reste donc à voir comment tout cela est administré au niveau d’une organisation. C’est là qu’intervient le “Windows Store pour les entreprises” qui peut se définir comme un portail web d’administration d’applications accessibles depuis l’url suivante : https://businessstore.microsoft.com

Le “Windows Store pour les entreprises” permet notamment de :

• Gérer un catalogue d’applications publiques et/ou privées pour les employés d’une organisation
• Faire l’acquisition d’applications en volume de licence
• Configurer le mode de distribution/déploiement
• Gérer des rôles d’utilisateurs pour l’accès au store pour les entreprises

En prérequis, une organisation devra disposer :

• d’un compte d’accès au “Windows Store pour Entreprises”
• une flotte d’équipements sous Windows 10 (PC, tablette ou smartphone)

Inscription au “Windows Store pour Entreprises”

Lorsque vous vous connecterez au “Windows Store pour Entreprises” pour la première fois, on vous demandera soit de vous inscrire soit de vous connecter avec un compte Azure Active Directory :

La procédure complète est très bien documentée ici

Si vous possédez un tenant Office365, vous disposez déjà d’un compte Azure AD que vous pouvez réutiliser pour l’accès au Windows Store pour Entreprises.

Utilisation du Windows Store pour Entreprises

Voici les différentes actions que vous pouvez réaliser depuis cette interface :

• Gérer un inventaire d’applications publiques (B2C) et privées (LOB)
• Faire l’acquisition d’applications B2C et LOB
• Gestion de licence (achat, affectation/récupération)
• Gérer la distribution de ces applications au sein de votre organisation
• Store privé (mode connecté)
• Affectation nominative (mode connecté)
• Side-loading
• Gérer les utilisateurs avancés ayant accès au Windows Store pour Entreprises
• Gérer les outils de déploiement d’applications (MDM, SCCM)
• Gérer les éditeurs (ISV) d’applications LOB

Voici un exemple d’inventaire d’entreprises :

Distribution

La distribution d’applications peut être réalisée selon deux canaux :

• Via le store privé
• L’administrateur gère un inventaire ou catalogue d’applications
• Les applications de ce catalogue sont visibles uniquement par les employés de l’organisation
• Les employés doivent s’authentifier avec leur compte Azure AD
• Seules les applications en mode de Licence Online sont accessibles depuis le store privé
• A tout moment l’administrateur peut récupérer des licences
• Distribution Nominative
• L’administrateur assigne une application à un utilisateur donné
• Seules les applications en mode de Licence Online sont accessibles
• Les utilisateurs doivent s’authentifier avec leur compte Azure AD
• Possibilité de récupérer les licences depuis le portail Windows Store pour entreprises

Dans l’exemple ci-dessous, l’application LOB DemoZone9.com est disponible dans le store privé et a été installée par deux employés :

Dans cet autre exemple, nous pouvons télécharger une application (package, licence et métadonnées) dont la licence est “hors-ligne” :

Services Windows Store

• Le Windows Store pour Entreprises expose une API accessible aux outils de Management (MDM, SSCM )
• Permet la synchronisation des applications achetées et leur mise-à-jour
• Les Meta-données (App Details, Icons), packages (offline), et Licences (offline) sont synchronisées
• Les applications à licence “Offline” sont téléchargeables depuis le portail du Windows Store pour Entreprises

Vous trouverez plus d’information sur cette API ici

Configuration des outils de Management

• Ces outils doivent être enregistrés en temps qu’applications Azure AD
• Ces outils doivent également être configurés dans le portail Windows Store pour Entreprises
• Azure AD requis pour l’authentification des ces outils auprès des services du Windows Store pour Entreprises

Démo

Vous trouverez ici une vidéo démontrant l’accès au Windows Store pour Entreprises

FAQ

Azure Active Directory est-il requis pour utiliser le Windows Store  pour Entreprises ?

• Azure AD est requis pour l’enregistrement au Windows Store pour Entreprises et l’achat d’applications
• Uniquement pour les IT Pro.
• Azure AD est requis pour l’installation depuis le store privé.
• Tous les employés de l’organisation.
• Azure AD non requis pour les applications installées en mode hors-ligne.

Puis-je installer/déployer mes applications sans passer par le store ?

Oui : déverrouillage des devices et déploiement d’applications signées par votre organisation est toujours possible. Voir ce lien pour plus d’infos. Néanmoins le store privé présente une alternative possible

Ai-je besoin d’un serveur de management pour gérer mes applications ?

Non, le cycle de vie des applications peut être géré différemment (par script, DISM ou encore du provisioning à l’execution)

Ressources

Voici un ensemble de liens pour en savoir plus :

• Accès au Windows Store pour Entreprises :
• Documentation MSDN
• Session Ignite 2015 sur le Windows Store pour Entreprises

Sans trop rentrer dans les détails de ce bug, je vais quand même vous expliquez comment j’en suis arrivé à devoir générer mon package appx à la main. Il se trouve que le fameux designer de package dont le rôle est de générer un package prêt à être publié sur le Windows Store va modifier à la volée le fichier Package.appxmanifest afin par exemple d’y ajouter des métadonnées. Jusque-là rien de neuf sous le soleil. Le problème est apparu lorsque j’ai souhaité utiliser Cortana et ajouté au fichier manifest l’extension suivante afin de pouvoir lancer mon application depuis Cortana :

<uap:Extension Category="windows.personalAssistantLaunch"/>

A chaque fois que je souhaitais créer un package pour le distribuer à un client via le designer de package :

… l’extension précédente était systématiquement effacer du fichier manifest !!! Plutôt embêtant pour faire valider à mon client une fonctionnalité clef de mon application. Du coup j’ai cherché un moyen de pouvoir générer un package différemment. J’ai pour cela identifié deux scénarios possibles.

Scénario 1 : Modifier le package Appx généré par VS2015

Je suis parti du package appx généré par Visual Studio (package contenant le fichier manifest dont l’extension “windows.personalAssistantLaunch” a été effacé par erreur) et j’ai réalisé les actions suivantes :

• dézipper le package (en effet un fichier appx n’est qu’un fichier d’archive compressé)
• localiser et éditer le fichier manifest dénommé AppxManifest.xml en y ajoutant la fameuse extension manquante
• rezipper le package
• générer un certificat local de signature de code
• signer le package avec le certificat de signature

Pour cela j’ai utilisé les utilitaires disponibles dans le Windows Software Development Kit (SDK) for Windows 10 localisés dans les répertoires suivants :

C:\Program Files (x86)\Windows Kits\10\bin\x86

C:\Program Files (x86)\Windows Kits\10\bin\x64

C:\Program Files (x86)\Windows Kits\10\bin\arm

Dans mon cas je vais générer un fichier appx pour cible desktop (x86). Pensez à modifier votre répertoire si vous souhaitez cibler un jeu d’instructions ARM pour windows phone. Pensez également à ajouter le répertoire “bin” correspondant dans votre variable d’environnement PATH afin de simplifier la saisie de commande. Le répertoire contenant mon fichier appx généré par Visual Studio est le suivant :

Etape 1 : dézipper le fichier MonAppli_1.0.0.0_x86_Debug.appx

• Ouvrez une console en ligne de commande (Touche “Windows” + R puis tapez “cmd” suivi de la touche “Entrée”)
• Déplacez-vous dans le répertoire contenant votre fichier appx généré par Visual Studio
• Dézippez votre fichier appx en tapez la commande suivante :

   makeappx.exe unpack /p MonAppli_1.0.0.0_x86_Debug.appx /d .\unpacked /l

Vous obtenez alors un répertoire “unpack” contenant le fameux fichier manifest à éditer :

Etape 2 : rezipper le fichier MonAppli_1.0.0.0_x86_Debug.appx en modifiant son nom

Ouvrez le fichier AppxManifest.xml avec un éditeur de texte et mémorisez la valeur de l’attribut “Publisher” dans la section suivante :

  <Identity
    Name="f786839b-6b88-4374-8865-cf7628099bbc"
    Publisher="CN=myname"
    Version="1.0.0.0" />

Ce nom correspond à votre nom d’éditeur de logiciel et nous en aurons besoin ultérieurement pour la génération de certificat numérique.

Un fois le fichier manifest modifié, je vais pouvoir rezipper le fichier appx en tapant la ligne de commande suivante :

makeappx.exe pack /d .\unpacked /p MonAppli_1.0.0.0_x86_Debug_UPDATED.appx /l

Et voici le nouveau fichier appx :

Au passage vous pouvez effacer le répertoire “unpack”.

Etape 3 : générer un certificat de signature de code auto-signé et une clef privée

Et oui … les applications ne peuvent pas s’installer aussi facilement : elles doivent être signées numériquement. Pour cela il est nécessaire de générer un certificat numérique. Si vous regardez bien la capture d’écran précédente, vous y trouverez un fichier certificat d’extension “.cer” qui  a été initialement généré par Visual Studio lors de la création du package. Malheureusement nous ne pouvons pas le réutiliser car nous ne connaissons pas le mot de passe de la clef privée associée à ce certificat et utilisée pour la signature. Nous allons donc en créer un nouveau. Donc je vous invite à effacer le fichier MonAppli_1.0.0.0_x86_Debug.cer. Ensuite je vous invite à taper la commande suivante :

makecert.exe -sv MyCertificatePrivate.pvk -n "CN=myname" /h 0 /eku "1.3.6.1.5.5.7.3.3,1.3.6.1.4.1.311.10.3.13" MyCertificate.cer -a sha256 -r

Cette commande va générer deux fichiers :

• Une clef privée stockée dans un fichier d’extension “.pvk”
• Un certificat numérique de signature stockée dans un fichier d’extension “.cer”

Comme vous l’avez remarqué, l’exécution de cette commande a affiché successivement deux boites de dialogue suivante :

puis

Toute clef privée est en effet protégée par un mot de passe (pensez à le mémoriser car il vous sera redemandé à l’étape suivante).

Etape 4 : convertir le certificat et la clef privée en un unique fichier “pfx”

Afin de signer le fichier appx, nous avons besoin d’un fichier de type “Personal Information Exchange” (format PKCS#12) dont l’extension est “.pfx”. Pour cela nous allons utiliser un autre utilitaire dénommé “pvk2pfx.exe”. Toujours dans la même console, tapez la commande suivante :

pvk2pfx.exe -pvk MyCertificatePrivate.pvk -spc MyCertificate.cer -pfx MyCertificate.pfx

Au passage notez qu’il vous sera demandé de saisir le mot de passe protégeant la clef privée, mot de passe défini lors de l’étape précédente :

Voilà nous avons dorénavant notre fichier pfx et nous sommes prêt à signer notre fichier appx :

Etape 5 : signer le package appx

Pour ce faire, vous allez taper la ligne de commande suivante :

signtool.exe sign /a /v /fd SHA256 /f MyCertificate.pfx MonAppli_1.0.0.0_x86_Debug_UPDATED.appx

Et voilà : dorénavant vous pouvez envoyer votre package appx fraichement générer. Avant d’envoyer le script powershell d’installation, pensez à effacer le fichier appx original.

Ce premier scénario a donc couvert les différentes étapes pour modifier un package appx initialement généré par VS2015. Cela est pratique dans certains cas pour diffuser une version “Debug” en mode “side-loading”. Néanmoins il y a un problème majeur : vous ne pouvez pas publier  sur le store un tel package en mode Release. En effet depuis VS2015 le mode Release inclut un mode de compilation .NET Natif afin d’optimiser les performances de votre application. Et malheureusement il n’est pas possible de publier sur le store un package appx précompilé en .NET natif. Vous aurez le message d’erreur suivant :

Nous touchons ici les limites de ce premier scénario. Heureusement il existe une seconde approche : utilisez MSBuild

Scénario 2 : Générer un package appx avec MSBuild

A la différence du premier scénario, nous génèrerons ici le package “from scratch”. Cette génération est réalisée en trois temps :

• Associer votre application avec le store Windows
• Editer votre fichier Package.appxmanifest notamment pour définir le numéro de version (optionnelle)
• Générer votre package en utilisant MsBuild

Etape 1 : Associer votre application avec le store

Depuis Visual Studio, sélectionnez votre projet et cliquez sur le bouton droit de la souris pour afficher le menu contextuel. Puis sélectionnez le menu “Store” puis “Associate App With Store” :

Cette phase nécessite de vous authentifier avec votre compte développeur. Vous pourrez alors sélectionner un nom d’application. Cette association avec le store aura pour conséquence la récupération de deux fichiers qui seront utilisés par la procédure de build pour générer et signer vos différents packages :

• Package.StoreAssociation.xml
• MonAppli_StoreKey.pfx

Etape 2 : Editer votre fichier Package.appxmanifest (Optionnelle)

Cette étape est complètement optionnelle et spécifique à mon besoin d’ajouter une extension pour Cortana. Par ailleurs vous pouvez y définir le numéro de version de votre application (attribut Version de la balise <Identity>). Vous pouvez passer directement à l’étape suivante.

Etape 3 : Générer votre package en utilisant MsBuild

Ouvrez une console en ligne Visual Studio, c’est-à-dire une console paramétrée avec les variables d’environnements nécessaire à l’utilisation de MsBuild. Pour cela, rendez-vous dans le répertoire suivant :

C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools

Ensuite ouvrez le batch file VsDevCmd.bat puis lancez la commande suivante :

MSBuild .\MonAppli.csproj /p:Configuration=Release;AppxBundle=Always;AppxBundlePlatforms="x86|x64"

/p:BuildAppxUploadPackageForUap=true

Cette commande aura pour effet :

• de compiler votre projet en mode Release
• de générer un package de type bundle
• de cibler les plateformes x86 et x64 (noter la présence du caractère ‘|’ permettant de lister différentes plateformes cibles dans une même commande)

Au final vous obtiendrez un fichier MonAppli_1.0.0.0_x86_x64_bundle.appxupload que vous pourrez directement charger sur l’interface de publication Dev Center.

Conclusion

En résumé, cet article a exposé deux approches pour générer un package sans utiliser le designer de package intégré à Visual Studio :

• La première méthode pour faire du side-loading de package sans utiliser le designer de Visual Studio
• La seconde méthode pour générer un package de production, bien utile dès qu’on souhaite scripter la procédure de build d’une application Windows store

Références

Packager une application Windows 10 Universelle

Comment créer un certificat de signature de package

Créer un package avec MakeAppx

• L’utilisation de directives de compilation
• La création de plugins

Pré-requis

• Unity 4.6 ou supérieure
• PC sous Windows 8.1
• Visual Studio 2013 Community Edition (gratuit)
• Visual Studio 2013 Tool for Unity (optionnel)
• Un téléphone sous Windows Phone 8.1 (optionnel car on peut utiliser l’émulateur WP8.1)

Dans la suite de cet article, nous exporterons notre application Unity vers la plateforme “Universal 8.1”

Directives de compilation

La force d’Unity est de pouvoir cibler différentes plateformes avec un code unique bâti sur un framework unifié. Néanmoins il existe des situations où le code doit être adapté aux spécificités des plateformes. Pour palier ce problème, Unity fournit aux développeurs des directives de compilation prédéfinies :

Parmi ces directives, voici celles que nous allons utiliser :

• NETFX_CORE : à utiliser dès lors qu’on souhaite appeler une API Windows Runtime depuis un script Unity. A noter que le code inclus dans un tel bloc est ignoré par l’éditeur Unity : en plus de l’utilisation des APIs WinRT, c’est un moyen pratique pour utiliser des spécificités du framework .NET 4.5
• UNITY_METRO : à utiliser dès lors qu’on souhaite utiliser une API Windows Runtime commune à Windows 8.1 et Windows Phone 8.1
• UNITY_METRO_8_1 : à utiliser dès lors qu’on souhaite utiliser une API Windows Runtime spécifique à Windows 8.1 (et non supportée par Windows Phone 8.1) ou implémenter un comportement spécifique à Windows comme par exemple l’accès à la Charm barre.
• UNITY_WP_8_1 : à utiliser dès lors qu’on souhaite utiliser une API Windows Runtime spécifique à Windows Phone 8.1 (et non supportée par Windows 8.1) ou implémenter un comportement spécifique à Windows Phone comme par exemple la gestion du bouton “Retour”

Remarque : contrairement à NETFX_CORE, les directives UNITY_METRO, UNITY_METRO_8_1 et UNITY_WP_8_1 sont actives dans l’éditeur Unity dès que vous sélectionner “Windows store” comme plateforme cible dans la boite de dialogue d’exportation.

A titre d’illustration, je vous propose donc d’implémenter un code d’exemple ultra simple : mon application Unity va afficher un Canvas avec un bouton ; lorsqu’on cliquera sur le bouton, l’application ouvrira une boite de dialogue native de la plateforme Windows avec un message texte. Bien que très basique d’un point de vue fonctionnelle, cet exemple va couvrir un certain nombre d’aspects clés pour comprendre la manière dont un script Unity peut interagir avec l’OS.

La première étape consiste donc à créer un projet Unity (en y important le plugin Visual Studio Tools for Unity) :

• une scène principale dénommée “Main”
• Un script c# dénommé MessageBox.cs et attaché à la caméra principale. J’y ai défini une méthode dénommée OnMessageBoxClick pour gérer le clic bouton
• Un canvas contenant un bouton dont le gestionnaire de clics est initialisé avec la méthode OnMessageBoxClick

Parlons maintenant du script C# associé :

1. Configuré sous Visual Studio avant exportation :

Comme vous pouvez le constater, tout ce qui est encadré par la directive NETFX_CORE est ignoré par l’éditeur Unity (code grisé). Le gestionnaire de clic ne fait qu’afficher une trace dans la console Unity.

2. Configuré sous Visual Studio après exportation “Universal 8.1” :

Cette fois le code encadré par la directive NETFX_CORE est bien actif et pour cause : dans votre projet exporté sous Visual Studio, lorsque vous sélectionnez dans l’explorateur de solutions le projet “MessageBox.Windows” ou “MessageBox.Windows Phone” et affichez les propriétés du projet (onglet Build), vous verrez parmi les directives de compilation actives la directive NETFX_CORE :

Il est temps de disséquer le code : la classe WinRT pour afficher une boite de dialogue native est MessageDialog. Un de ces constructeurs est ici appelé avec en paramètre le message texte passé sous forme de chaine de caractères. Puis la méthode ShowAsync est appelée selon le pattern Await/Async. Ce qui est notable (et qui ne vous aura sans doute pas échappé) c’est le fait que ce bloc de code est inclus dans une lambda expression asynchrone, elle-même passée en paramètre d’un appel à la méthode CoreApplication.MainView.CoreWindow.Dispatcher.RunAsync : cela signifie que l’affichage de la boite de dialogue est délégué au thread graphique (UI) de la fenêtre principale de l’application ; c’est une obligation imposée par le modèle de threading des applications WinRT dès lors qu’on interagit avec l’interface graphique. Logiquement vous pourriez croire que le script Unity s’exécute déjà dans ce thread graphique et que cette délégation est inutile … et bien non, détrompez vous : le script Unity s’exécute dans un background thread (encore appelé worker thread). D’ailleurs Unity a défini des méthodes spécifiques Windows pour gérer ce changement de contexte dans la classe UnityEngine.WSA.Application :

Je pourrais donc réécrire mon code ainsi :

Cela fonctionnerait tout aussi bien ; c’est à vous de choisir en fonction de vos préférences. L’avantage de la méthode InvokeOnUIThread est qu’elle peut être appelée directement depuis un script Unity en dehors de tout bloc NETFX_CORE. Vous aurez également remarqué que l’exemple ci-dessous n’utilise qu’une seule directive NETFX_CORE. Dans quel cas de figure utiliser UNITY_METRO_8_1 ou UNITY_WP_8_1 ? La réponse est double :

Réponse 1 : 90% des APIs pour Windows et Windows Phone sont communes.

Pour utiliser les 10% restants (parties bleue et rose), il faudra donc utiliser ces directives. Je peux vous donner un exemple concret : imaginez que vous souhaitiez rediriger votre utilisateur vers l’application Store native afin de l’inciter à noter votre application. Bien que l’API soit identique pour Windows et Windows Phone, le format de l’URI utilisé en paramètre d’entrée est différent entre les deux store (“package family name” pour windows et “application ID” pour windows phone) :

Bien sûr avec l’arrivée de Windows 10, ce code deviendra obsolète. En attendant, cela reste une implémentation efficace.

Réponse 2 : pour gérer le bouton “Retour” présent sur Windows Phone mais absent sur Windows. En général, lorsque l’utilisateur active la touche “Retour”, soit il le fait lorsqu’il navigue dans des menus (dans ce cas il faut afficher le menu précédent ou quitter le jeu), soit il l’actionne en plein jeu (dans ce cas, il faut mettre le jeu en pause). Sous Unity, le bouton “Retour” est mappé sur la touche “ESC”. Par conséquent voici un exemple de code basique gérant la touche retour uniquement pour Windows Phone :

Les Plugins

Utiliser des directives de compilations c’est bien mais cela peut rendre le code difficilement maintenable ou lisible. Une alternative possible est de définir une librairie (DLL) contenant tous les appels dépendants de la plateforme. Dans cette seconde partie de l’article, je vous propose donc de définir une telle librairie ou plutôt deux librairies :

• Une librairie dénommée “MyPlugin.dll” dans laquelle je vais définir la méthode permettant d’afficher une boite de dialogue native (au sens natif à la plateforme Windows)
• Une seconde librairie ayant le même nom “MyPlugin.dll” et contenant la même interface mais avec une implémentation vide (on parle alors de “Stub” ou coquille vide). Pourquoi ? Tout simplement pour permettre à votre jeu de s’exécuter dans le player de l’éditeur Unity. Du coup l’appel aux APIs plateformes ne se fera que dans un contexte d’exécution plateforme.

Création du plugin

Nous allons donc créer un plugin sous forme de DLL universelle ciblant Windows 8.1 et Windows Phone 8.1.

Pour commencer je vais créer un nouveau projet sous VS2013  : dénommé “MyPlugin” de type Visual C# –> Store App –> Universal App –> Class Library (Portable for Universal Apps) :

1. Je choisis la catégorie de template Visual C# –> Store App –> Universal App
2. Je veille à ce que la version de mon plugin soit basée sur le framework .NET 4.5.1 afin de pouvoir utiliser dans mon plugin la dernière version .NET compatible avec les plateformes Windows 8.1 / Windows Phone 8.1
3. Puis je sélectionne Class Library (Portable for Universal Apps) ce qui me permettra de créer une librairie sous forme de DLL utilisable à la fois sur Windows et sur Windows Phone
4. Je définis un nom de projet pour ma librairie : UniversalPlugin
5. Enfin je nomme ma solution MyPlugins et je valide la création en cliquant sur le bouton “OK”

Visual Studio va alors créer la structure de fichiers suivante (capture sous de l’explorateur de fichiers sous Windows ) :

Et la structure de projet logique suivante (capture de l’explorateur de solution sous Visual Studio) :

Par défaut VS2013 a crée une classe unique dénommée Class1 définie dans le fichier correspondant Class1.cs. Je vous propose d’effacer ce fichier (sélectionnez le projet “UniversalPlugin” depuis l’explorateur de solution Visual Studio et ouvrez le menu contextuel en cliquant sur le bouton droit de la souris, puis sélectionnez “Effacer”). Nous allons créer une interface qui va définir les méthodes publiques du plugins qui seront accessibles depuis vos scripts Unity : pour cela je vous invite à ré-affichez le menu contextuel du projet “UniversalPlugin” sous Visual Studio et sélectionnez “Ajouter  / Nouvel élément” :

1. Je sélectionne une interface
2. … que je nomme IUniversalPlugin.cs (par convention il est intéressant de commencer tout nom d’interface par un “i” majuscule : cela permet en un clin d’œil d’identifier les interfaces de leur implémentation.
3. Cliquer sur le bouton “Ajout / Add”

Nous allons ensuite modifier le fichier IUniversalPlugin.cs pour définir deux méthodes permettant d’afficher une boite de dialogue native :

Pensez à bien rendre cette interface publique. Reste à implémenter ces deux méthodes. Pour ce faire je vais créer une nouvelle classe dénommée UniversalPlugin dans un nouveau fichier UniversalPlugin.cs. Comment ? Très simple : dans la fenêtre d’explorateur de solution Visual Studio, sélectionnez le projet UniversalPlugin et cliquez sur le bouton droit de la souris. Dans le menu contextuel, sélectionnez “Ajouter / Classe” :

1. Par défaut, Classe est sélectionnée … ne changez rien
2. Puis nommez le fichier UniversalPlugin.cs : le fichier contiendra alors la définition (vide) de la classe UniversalPlugin

Ensuit nous allons modifier ce fichier UniversalPlugin.cs ainsi :

Première remarque : j’ai renommé l’espace de nom initial “UniversalPlugin” en “MyPlugins” de manière à distinguer l’espace de nom des classes qu’il contient. Pour cela j’ai sélectionné avec le curseur de souris l’espace de nom initial, UniversalPlugin et j’ai cliqué sur le bouton droit et choisi le menu “Refactor –> Rename” : cela permet de modifier le nom d’espace dans la globalité du projet (au niveau de la DLL et de tous les fichiers de code).

Ensuite, afin d’optimiser l’utilisation de la classe UniversalPlugin, nous utilisons le pattern classique de “Singleton” ce qui permet de ré-utiliser la même instance pour différents appels. Un appel à la méthode d’affichage d’une boite de dialogue natif se fera donc ainsi :

UniversalPlugin.IInstance.ShowMessageDialog(“Hello from WinRT”);

La méthode showMessageDialogAsyncPriv mérite quelques explications : l’affichage d’une boite de dialogue sous Windows/Windows Phone requiert l’exécution dans le contexte du thread graphique (encore appelé thread UI). Or par défaut, une application Unity s’exécute dans un thread applicatif (encore appelé worker thread). Par conséquent la méthode CoreApplication.MainView.CoreWindow.Dispatcher.RunAsync permet de demander l’exécution du code asynchrone inclus dans la lambda expression passée en second paramètre. Si vous appelez directement la méthode messageBox.ShowAsync, votre application se terminera brutalement suite à une levée d’exception système. Lorsque nous compilons le projet “UniversalPlugin”, une DLL dénommée UniversalPlugin.dll sera générée dans le répertoire MyPlugins\UniversalPlugin\bin\Debug (ou MyPlugins\UniversalPlugin\bin\Release). Comme je le mentionnais en début de paragraphe sur les plugins : la création de cette librairie est nécessaire mais pas suffisante. En effet si vous utilisez directement cette librairie depuis vos scripts Unity, ces derniers ne compileront pas du fait de l’utilisation d’API .NET WinRT (à moins d’utiliser une directive de type NETFX_CORE … mais dans ce cas on perd tout l’intérêt d’utiliser un plugin). Il faut donc définir une seconde librairie reprenant les mêmes méthodes de la première librairie mais en y implémentant des méthodes vides (classiquement appelées Stub). C’est donc ce que nous allons voir maintenant.

Depuis l’explorateur de solutions sous Visual Studio, sélectionnez la solution “MyPlugins” puis afficher le menu contextuel (souris bouton droit) et choisissez le menu “Ajouter / Nouveau Projet” :

1. Je choisis la catégorie de template Visual C# –> Windows Desktop
2. Je veille à ce que la version de mon plugin soit basée sur le framework .NET 3.5 (et non .NET 4.5.1) car Unity s’appuie sur Mono (dont implémentation Open Source de .NET est équivalent à la version 3.5)
3. Puis je sélectionne Class Library (Portable for Universal Apps) ce qui me permettra de créer une librairie sous forme de DLL utilisable à la fois sur Windows et sur Windows Phone
4. Je définis un nom de projet pour ma librairie Stub : UniversalPlugin.Stub
5. Enfin je conserve le chemin de destination par défaut (qui correspond à mon répertoire de travail) et je valide la création en cliquant sur le bouton “OK”

Visual Studio va alors créer la structure de fichiers suivante (capture sous de l’explorateur de fichiers sous Windows ) :

Et la structure de projet logique suivante (capture de l’explorateur de solution sous Visual Studio) :

Dorénavant nous avons deux projets dans notre solution MyPlugins :

• UniversalPlugin
• UniversalPlugin.Stub

Si vous ouvrez le fichier Class1.cs créé par défaut, vous verrez que la classe appartient à l’espace de nom (namespace en anglais) UniversalPlugin.Stub : c’est un problème car l’objectif du stub est de rendre les choses transparentes pour Unity lorsque vous exécuterez votre code depuis l’éditeur. Par conséquent il faut modifier cet espace de nom pour qu’il soit identique à l’espace de nom de la première librairie à savoir MyPlugins. Pour cela, sélectionnez le projet “UniversalPlugin.Stub” depuis Visual Studio, cliquez sur le bouton droit de souris et cliquez sur le menu “Propriétés” :

• Renommer le nom de l’assembly en UniversalPlugin afin que le fichier DLL du stub soit identique au nom de fichier DLL de la première librairie
• Renommer le nom d’espace par défaut en MyPlugins
• Sauvegarder les propriétés du projet (combinaison de touches CTRL + S)

Je vous propose ensuite d’effacer le fichier Class1.cs (sélectionnez le projet “UniversalPlugin.Stub” depuis l’explorateur de solution Visual Studio et ouvrez le menu contextuel en cliquant sur le bouton droit de la souris, puis sélectionnez “Effacer”). Maintenant nous allons ajouter une classe (ou plutôt un lien symbolique)  du projet UniversalPlugin (donc déjà existante) dans le projet UniversalPlugin.Stub : il s’agit de l’interface IUniversalPlugin ; pour cela sélectionnez le projet UniversalPlugin.Stub, puis afficher le menu contextuel et choisissez “Ajouter / Elément existant” :

1. Modifiez le répertoire sélectionné par défaut (UniversalPlugin.Stub) afin de parcourir le répertoire UniversalPlugin
2. Sélectionnez le fichier d’interface IUniversalPlugin.cs
3. Cliquez sur le bouton “Ajouter comme lien” de manière à créer une référence à ce fichier dans votre projet courant UniversalPlugin.Stub

Notez la petite flèche sur l’icone du fichier IUniversalPlugin.cs de votre projet UniversalPlugin.Stub :

Nous avons créé un lien symbolique qui permet de simplifier la maintenance de l’interface du plugin : si nous voulons ajouter une nouvelle méthode, inutile de modifier deux fichiers avec le risque d’erreur que cela peut induire. Reste maintenant à définir la partie Stub, ce qui est très simple : sélectionnez le projet UniversalPlugin.Stub, puis afficher le menu contextuel et choisissez “Ajouter / Elément existant” :

1. Modifiez le répertoire sélectionné par défaut (UniversalPlugin.Stub) afin de parcourir le répertoire UniversalPlugin
2. Sélectionnez le fichier d’interface UniversalPlugin.cs (sans le “i” majuscule cette fois)
3. Cliquez sur le bouton “Ajouter” de manière à créer une copie de ce fichier dans votre projet courant UniversalPlugin.Stub

Modifier votre fichier UniversalPlugin.cs fraichement dupliqué :

Comme vous le constatez, j’ai vidé le contenu des méthodes ShowMessageDialog et j’ai effacé la méthode showMessageDialogAsyncPriv.Compilez maintenant votre projet UniversalPlugin.Stub et vous obtiendrez la fameuse seconde librairie portant le même nom que la première “UniversalPlugin.dll”

Utilisation du plugin

Maintenant je vous propose de reprendre l’application Unity utilisée dans la première partie de cet article. Avant d’ouvrir le projet sous Unity il est important de déployer les fichiers DLL (plugin et stub). Dans un premier nous allons les déployer à la main via l’explorateur de fichier. Ultérieurement je vous montrerai comment créer un fichier de déploiement (fichier d’extension .unitypackage) ou package qu’il sera alors possible d’importer depuis Unity. Voici la structure classique de fichier de notre projet Unity initial dénommé MessageBox :

Dans le répertoire “Assets” je vais créer un sous-répertoire dénommé “Plugins” : ATTENTION l’orthographe de ce répertoire est importante ; si vous oubliez le “s’” à la fin, l’éditeur ne saura pas localisez vos DLLs et vous ne pourrez pas exporter votre jeu. Une fois ce répertoire Plugins créé, vous allez :

1. y copier la librairie Stub de votre plugin
2. y créer un répertoire dénommé “Metro” et copier dans ce nouveau répertoire la librairie de votre plugin

Maintenant nous pouvons ouvrir le projet Unity et éditer le fichier script Unity dénommé MessageBox.cs ainsi :

Notez deux choses :

1. L’inclusion de l’espace de nom “MyPlugins”
2. La modification du gestionnaire de clic OnMessageBoxClick avec l’appel à notre plugin.

Si maintenant vous exécutez votre application depuis l’éditeur Unity et que vous cliquez sur le bouton MessageBox, rien ne se passe et c’est normal puisque la méthode ShowMessageDialog appelée est celle du stub dont l’implémentation est vide. Pour finir je vous invite à exporter votre jeu en application universelle 8.1. Si l’exportation réussie, Unity va ouvrir l’explorateur de fichier contenant votre projet Visual Studio :

Ouvrez le fichier MessageBox.sln avec Visual Studio 2013 puis sélectionnez le projet MessageBox.Windows (Windows 8.1) et cliquer sur le bouton “Local Machine’'” après vous êtes assurés que l’architecture processeur soit bien “x86” :

A l’exécution, cliquez sur l’unique bouton “Display MessageBox” du Canvas Unity :

Et voilà ….

Note : vous pouvez également tester l’application en version Windows Phone 8.1 car notre plugin est universel.

Déploiement du plugin

Comme vous l’avez constaté, le déploiement manuel de votre plugin est un peu fastidieux et on a vite fait de s’emmêler les pinceaux entre la DLL du plugin et sa version Stub portant le même nom. Pour palier se problème, nous allons créer un petit script (batch file) tout simple :

Pour le tester :

1. Copiez le fichier deploy.bat ci-dessous dans le répertoire de votre solution Visual Studio utilisée pour créer votre plugin. Dans mon cas il s’agit du répertoire suivant : C:\work\dev\wp\unity\MyPlugins
2. Ouvrez une invite de commande et placez-vous dans ce même répertoire puis exécutez la commande suivante :

deploy C:\work\dev\unity\MessageBox

Vous obtenez alors la sortie suivante :

Notez que mon fichier batch déploie uniquement les fichiers DLLs en mode release.

Distribution du plugin

Sachez que vous pouvez distribuer votre plugin sur l’asset store de Unity en version gratuite ou payante. Pour distribuer votre plugin via l’asset store de Unity ou autre site web, il vous faudra packager votre plugin dans un fichier d’extension “.unitypackage”, ce qui permettra aux utilisateurs de l’importer directement depuis Unity. Pour cela il faut utiliser l’exécutable Unity en mode scripté et créer au moins un projet Unity utilisant votre plugin (dans notre cas il s’agit du projet MessageBox). Voici la commande à saisir :

• l’option –batchmode permet d’utiliser Unity sans ouvrir l’éditeur
• l’option –projectPatch indique le répertoire du projet Unity (ici notre projet test MessageBox)
• l’option –exportPackage indique le répertoire contenant notre plugin
• Et à la fin nous indiquons le nom du package personnalisé, MyPlugins.unitypackage, qui sera généré à la racine du répertoire MessageBox

Une fois le package généré, d’autres développeurs pourront l’utiliser via Unity en sélectionnant le menu Assets / Import Assets / Custom Package. S’ouvrira alors la fenêtre Unity suivante :

Conclusion

Voilà … l’utilisation des APIs Windows/Windows Phone 8.1 depuis vos scripts Unity n’ont plus de secrets pour vous ou presque. Vous pouvez téléchargez librement les exemples de codes détaillées dans ce article ici

Aussi je vais vous montrer dans cet article comment utiliser Visual Studio pour développer votre code Unity. Je pars sur le principe que vous possédez :

• Un PC tournant sous Windows 7/8/8.1
• Une version récente (2013 ou plus) de Visual Studio (Community & Express, Pro, Premium ou Ultimate)
• Unity (version 4.x ou 5.x)

Sachez également que la version gratuite (Community & Express) de Visual Studio est compatible avec Unity : aucune excuse pour ne pas essayer.

L’utilisation de Visual Studio avec Unity nécessite l’installation d’un plugin initialement développé par la société SyntaxTree et qui a fait l’objet d’un rachat il y a bientôt un an par Microsoft.

Installation

Ce plugin est accessible en libre téléchargement depuis le site officiel https://unityvs.com/

Cliquez sur “Visual Studio 2013 Tools for Unity” comme indiqué ci-dessous :

Vous arriverez alors sur une page intermédiaire permettant de démarrer le téléchargement du fichier Visual Studio 2013 Tools for Unity.msi :

Une fois téléchargé, lancez l’installation du plugin en double-cliquant le fichier msi (assurez vous d’avoir fermé Unity au préalable). Le répertoire d’installation proposé par défaut est le suivant : C:\Program Files (x86)\Microsoft Visual Studio Tools for Unity\2013 . Vous pouvez bien sûr choisir un autre répertoire.

Configuration

L’étape suivante consiste à créer un nouveau projet sous Unity puis à importer le plugin via le menu Import Package / Visual Studio 2013 Tools comme indiqué sur la capture ci-dessous :

Note : si vous utilisez Unity 5.x, le sous menu “Visual Studio 2013 Tools” n’est pas présent. Pas de panique : il faut simplement sélectionner le sous menu Custom Package … et localisez le fichier Visual Studio 2013 Tools.unitypackage disponible dans le répertoire d’installation du plugin ( C:\Program Files (x86)\Microsoft Visual Studio Tools for Unity\2013 dans mon cas).

S’affiche alors la boite de dialogue suivante :

Laissez tout sélectionné par défaut et cliquez sur le bouton Import. Une fois importé, deux changements significatifs apparaissent dans l’éditeur Unity :

• Un nouveau menu dénommé Visual Studio Tools permettant de générer le projet Visual Studio ainsi que de paramétrer le plugin
• Un nouveau sous-répertoire dénommé UnityVS dans le répertoire de base Assets : il contient toute la plomberie pour faire le bridge entre l’éditeur Unity et Visual Studio (synchro, déboguage etc)

Note : si vous vous rendez dans le menu Edit / Préférences et que vous sélectionnez l’onglet External Tools, vous noterez que l’éditeur par défaut MonoDevelop a été remplacé par UnityVS comme indiqué ci-dessous :

Votre environnement est maintenant prêt.

Utilisation

Dorénavant vous pouvez créer vos scripts C# depuis Unity. Lorsque vous double-cliquez sur un script Unity, cela ouvre automatiquement le projet Visual Studio sur le script sélectionné. Notez par ailleurs qu’il y a une synchronisation automatique entre l’éditeur Unity et Visual Studio : ajoutez un nouveau script sous Unity et retrouvez-le automatiquement sous le projet Visual Studio correspondant sans avoir besoin de relancer Visual Studio.

IntelliSense

Vous retrouvez bien sûr les fonctions d’aide contextuelle/auto-completion IntelliSense adaptée aux APIs Unity :

Debug

L’étape suivante consiste à déboguer vos scripts depuis Visual Studio tout en exécutant votre scène depuis Unity. Voici la procédure :

• Ouvrez votre projet sous Visual Studio et positionnez un point d’arrêt (dans mon exemple, je positionne un point d’arrêt dans la méthode start() de mon unique script Main.cs rattaché à la caméra principale).
• Connectez Visual Studio à l’instance d’Unity contenant votre scène à déboguer : pour cela localisez dans la partie inférieure droite de Visual Studio, une petite icône représentant une prise. S’ouvre alors une boite de dialogue listant les instances ouvertes d’Unity  et leur projet associé :

Sélectionnez votre instance et validez le bouton OK.

• Puis,  toujours dans Visual Studio, cliquez sur le bouton Attach to Unity : Visual Studio lance alors le mode Debug et attend.

• Retournez dans Unity et lancez le player sur la scène correspondante. Dans mon exemple, Visual Studio va breaker dès le démarrage :

Aide en ligne

Autre fonctionnalité intéressante : accéder à la documentation en ligne des APIs Unity depuis Visual Studio, et ce, de manière contextuelle. Pour cela rien de plus simple : SyntaxTree a mappé l’appel de l’aide en ligne sur le raccourci clavier CTRL+H. Par exemple si je positionne mon curseur sur la classe MonoBehavior dans mon script Main.cs et que je tape ce raccourci clavier, j’obtiens la documentation de la classe MonoBehavior :

Si vous souhaitez mapper la documentation en ligne sur un autre raccourci clavier, aucun problème : sélectionnez le menu Tools / Options puis cliquez sur l’élément Keyboard ; dans le champ “Show commands containing”, saisissez le mot unity et sélectionnez la commande Help.UnityAPIReference :

Vous pouvez alors sélectionner un autre raccourci clavier dans la liste Shortcuts for selected command.

Conclusion

Voilà j’espère que cet article vous aura donné un bon aperçu de l’utilisation de Visual Studio pour coder et déboguer vos scripts Unity. Pour aller plus loin je vous invite à consulter la documentation en ligne où vous apprendrez par exemple à déboguer des DLLs externes.

Si vous lisez cet article dans le but d’apprendre comment exporter son projet Unity sur Windows 8.1 / Windows Phone 8.1, vous êtes au bon endroit. Afin de rendre cette session d’apprentissage plus efficace, je vous recommande de manipuler en parallèle : cela permet de mémoriser plus facilement les différentes étapes.

Pré requis logiciels

Il est nécessaire d’utiliser la configuration logicielle minimale suivante :

• Windows 8.1 Pro. Bien qu’il soit possible d’utiliser une version non professionnelle de Windows 8.1, il est préférable d’utiliser une version Pro afin de bénéficier d’Hyper-V, la technologie Microsoft de virtualisation cliente, nécessaire pour l’utilisation de l’émulateur Windows Phone. Si vous disposez d’un téléphone Windows Phone 8.1 ou si vous ciblez uniquement la plateforme Windows 8.1, une version non professionnelle fera l’affaire. A noter que si vous êtes sur MAC, il est possible  de virtualiser un environnement de développement Windows 8.1 via des outils de virtualisation tels que Bootcamp, Parallels ou encore VMware.
• Visual Studio 2013. L’outil de développement intégré qui permet notamment de générer et packager vos applications Windows et Windows Phone au format exigé pour une publication sur le store de Microsoft. Les versions Express et Community peuvent être téléchargées et installées gratuitement depuis ce lien. A noter que l’installation de cet outil intègre également les SDKs Windows Phone et Windows.
• Unity. Afin de pouvoir exporter vos projets pour les plateformes Windows 8.1 / Windows Phone 8.1, il est nécessaire d’installer une version supérieure à la version 4.3. A l’heure où je rédige cet article, la dernière version téléchargeable est la version 5.0

Unity et l’exportation

L’éditeur d’Unity permet d’exporter votre projet sur différentes platformes Microsoft. Lorsque vous êtes dans l’éditeur Unity, sélectionnez dans le menu “File” le sous menu dénommé “Build Settings” (ou tapez la combinaison clavier CTRL + SHIFT + B si vous êtes du genre keyboard fanatic):

S’ouvre alors une boite de dialogue listant toutes les plateformes d’exportation supportées :

Lors du tout premier lancement, la liste “Scenes In Build” est vide et la plateforme d’exportation par défaut est “PC, Mac & Linux Standalone”. La première étape consiste à ajouter des scènes dans notre binaire. Si vous avez déjà crée un projet, vous disposez forcément d’au moins une scène (fichier d’extension “.unity”). Je vous invite donc à cliquer sur le bouton “Add Current” afin de sélectionner un ou plusieurs fichiers “.unity”. Ensuite il convient de sélectionner une plateforme. Dans notre cas, nous allons sélectionner la plateforme “Windows Store” et cliquer sur le bouton “Switch Platform”. Peut-être pensez-vous intérieurement :

• Question : “Oui mais pourquoi ne pas sélectionner PC ?”
• Réponse : tout simplement parce qu’un binaire ciblant la plateforme PC, même s’il peut s’exécuter sur Windows 8.1, ne pourra pas être distribué sur Windows Store : en effet à ce jour seules les applications modernes peuvent être publiées sur le Windows Store

• Question : “Et Windows Phone 8 ? Si je choisis cette option, je pourrai exécuter mon application sur Windows Phone 8.1, non ?
• Réponse : Oui c’est vrai MAIS votre application sera identifiée comme une application Windows Phone Silverlight et non comme une application universelle WinRT. Du coup il vous faudra gérer deux exports en parallèle, l’un pour Windows et l’autre pour Windows Phone. Par ailleurs comme Windows 10 fait la part belle aux développements d’applications universelles (UAP), vos maintenances d’applications futurs n’en seront que simplifiées si vous faîtes ce choix dès aujourd’hui . 

Nous obtenons alors la boite de dialogue suivante :

Remarques :

• J’ai choisi comme type “XAML C# Solutions”. J’aurai pu choisir “XAML C++ Solutions”. C’est une affaire de goût mais pas que ! En effet l’avantage du C# est que je peux débuguer mes scripts unity C# depuis Visual Studio. C’est bien pratique.
• Ensuite j’ai sélectionné le SDK dénommé “Universal 8.1” afin de générer une unique solution Visual Studio permettant d’adresser à la fois Windows 8.1 et Windows Phone 8.1. D’autres choix sont possibles :
  • 8.0 pour adresser uniquement Windows 8.0
  • 8.1 pour adresser uniquement Windows 8.1
  • Phone 8.1 pour adresser uniquement Windows Phone 8.1 (RT)
• Enfin j’ai coché “Unity C# Projects” afin de pouvoir débuguer sous Visual Studio

Avant d’exporter ma scène, je clique sur le bouton “Player Settings” afin de définir des métadonnées (nom d’application, icones, splashscreen etc). S’affiche alors la fenêtre “Inspector” pointant sur l’onglet de plateforme “Windows Store” (icône verte) :

Je ne vais pas énumérer tous les paramètres car ils sont nombreux. Sachez néanmoins que tous les paramètres configurés ici sont modifiables dans Visual Studio après exportation. Par exemple si vous cliquez sur “Icon”, vous pourrez définir les différentes icônes (ou tuile dans le jargon des app Windows store) depuis Unity et vous les retrouverez dans le répertoire “Assets” de votre solution Visual Studio. Idem pour les autres métadonnées comme le nom de l’application, la version, les splashscreens etc.

Il est temps de cliquer sur le bouton “Build” de la fenêtre “Player Settings”. Une fois le répertoire de sortie sélectionné (personnellement j’ai l’habitude de créer un répertoire “Build” puis un répertoire reprenant le nom de la plateforme cible e.g. ./Build/Universal8.1/ ), Unity démarre la génération du projet Visual Studio :

Si vos scripts Unity contiennent des erreurs de compilation ou font référence à des plugins mal compilés, la génération échouera avec un message d’erreur associé. Si par contre la génération réussit, Unity ouvre alors l’explorateur de fichier pointant sur le projet Visual Studio fraichement crée :

Une fois sous Visual Studio

Ouvrez le projet généré (fichier d’extension “.sln”) avec Visual Studio soit en double-cliquant ce fichier depuis l’explorateur, soit en sélectionnant le menu “Ouvrir Projet” depuis Visual Studio. Une fois ouvert, intéressons-nous à la fenêtre “Explorateur de solutions” :

Ne fuyez pas !!!! Il y a beaucoup de fichiers mais en réalité seuls quelques uns vont retenir notre attention.  Tout d’abord, il faut repérer le projet actif … facile son nom est en caractères gras : “New Unity Project.Windows (Windows 8.1)”. Visual Studio est sympa : il vous indique le nom de la plateforme active ciblée (ici Windows 8.1). “Quoi ?” allez-vous me dire ; “Je pensais qu’en exportant en “Universal 8.1” j’obtiendrais une unique solution Visual Studio ?” Pas tout à fait mais presque : vous obtenez bien une unique solution Visual Studio contenant plusieurs projets dont les principaux sont :

• New Unity Project.Windows (Windows 8.1)
• New Unity Project.WindowsPhone (Windows Phone 8.1)

Pour compiler/exécuter/packager la version Windows ou la version Windows Phone, il vous faudra activer l’un de ces deux projets, le projet Windows étant le projet activé par défaut. Ensuite vous pouvez accéder/éditer/débuguer vos scripts unity (fichier main.cs dans mon exemple ci-dessus) qui sont accessibles dans le répertoire “Assets” des deux projets Assembly-CSharp-metro-vs2013 (Windows 8.1) et Assembly-CSharp-windows-phone-8.1 (Windows Phone 8.1). A noter que ces scripts sont des liens pointant vers les fichiers physiques du projet unity : ils n’ont pas été dupliqués ce qui est une approche plutôt intelligente car cela permet de travailler de manière synchrone sur les deux éditeurs en parallèle (bien sûr, dès qu’on modifie une scène unity il est nécessaire de ré-exporter vers Visual Studio, mais cela n’écrase pas les scripts unity).

Pour l’exécution sur Windows 8.1, pensez à sélectionner “x86” comme type de plateforme cible avant de lancer une exécution, sinon vous aurez une erreur (ARM est en effet positionné par défaut) :

Pour l’exécution sur Windows Phone 8.1, vous avez le choix entre l’exécution sur émulateur (avec différentes résolutions) ou sur téléphone réel connecté en USB :

Important : pour tester votre application sur un téléphone réel vous devez absolument débloquer votre téléphone afin de le basculer en mode développeur. Pour cela il est nécessaire de :

• Créer un compte Microsoft (équivalent d’un compte iTunes ou Gmail) : c’est facile et gratuit
• Créer un compte développeur Microsoft : les frais d’inscription sont uniques pour les 2 stores de $19 (14€) pour 1 individu, $99 (75€) pour une entreprise, gratuit pour les étudiants via le programme DreamSpark. Un compte permet de débloquer jusqu’à 3 téléphones
• Débloquer son téléphone via l’utilitaire “Windows Phone Developer Registration” inclus dans le sdk

A savoir

Unity a défini des directives de compilation qui vous permettront de différencier des comportements de code selon que vous cibliez Windows 8.1 ou Windows Phone 8.1. Pourquoi ? Par exemple pour détecter les touches de clavier sous Windows ou encore tester la touche “Retour” uniquement disponible sous Windows Phone 8.1. Ces deux directives sont les suivantes :

• UNITY_WP_8_1 : Windows phone 8.1 only
• UNITY_METRO_8_1 : Windows 8.1 only

Voici un exemple de code tout simple permettant d’afficher un menu pause lorsque l’utilisateur appuie sur le bouton “Retour”.

La gestion du bouton “Retour” est mappé sur la touche clavier “ESC”. Ce code sera ignoré pour la compilation ciblant Windows 8.1

Conclusion

L’export d’un projet Unity sur les plateformes Windows et Windows Store est simple à mettre en œuvre. Vous avez déjà des jeux Unity ciblant iOS et Android ? Alors n’hésitez pas à faire le test :-) Dans le prochain article je détaillerai l’utilisation du plugin UnityVS permettant d’utiliser l’IDE Visual Studio en lieu et place de l’éditeur par défaut MonoDevelop.