Il a toujours été possible de faire apparaitre des applications Windows “classique” dans le listing du Store Windows. Cependant, vous étiez simplement redirigé vers le site de l’éditeur. Microsoft a annoncé pendant la //Build 2015 un projet nommé Centennial qui va permettre de déployer des applications Windows en passant par le Store.

Disclaimer : Le contenu présenté ici est encore en cours de spécification par Microsoft et je n’ai pas pu essayer ces outils.

Pourquoi ce projet ?

Il existe des centaines de milliers, si ce n’est des millions d’applications Windows “classiques” (aussi appelée CWA ou application “desktop”) et Microsoft ne veut pas se priver de cet écosystème dans la bataille du nombre d’applications dans le Store.

Un des objectifs du Store Windows est de rassurer l’utilisateur au travers d’une installation maitrisée : je sais ce que je vais installer, je sais que mon PC ne vas pas être infecté par un malware, je sais qu’il n’accèdera pas à mes données personnelles = je suis en confiance en tant qu’utilisateur.

Le problème d’une application CWA est qu’il n’existe pas de modèle d’exécution ou d’installation : chacun fait un peu à sa sauce et il n’y a tout simplement pas de définition de ce qu’est une app. Il est donc difficile de le faire passer par le processus normalisé du Store. Il fallait donc ré-écrire l’application sous la forme d’une Universal app (comme l’a fait VLC par exemple).

Centennial (ou projet C de son petit nom) a pour vocation de résoudre cette problématique et apporte ces avantages :

• Permettre l’acquisition de votre app en un seul click via le Store.
• Permet de bénéficier du système de mise à jour automatique.
• Permet de rassurer vos utilisateurs vis à vis de votre application.
• Permet d’utiliser des fonctionnalités des Universal apps:  live tiles, etc.

Comment le mettre en place ?

Concrètement, Projet C prends en entrée un MSI d’installation et étudie via un outil quelles parties du système vont être impactées lors de l’installation. Cet outil va alors générer un package (appx) avec un fichier manifest spécifique à ce type d’application CWA.

Il vous faut alors tester votre application pour vous assurer qu’elle fonctionne et … la publier sur le Store !

L’application une fois installée sera au même endroit qu’une application Windows Store (dans le dossier “Windows Apps”). Sous le capot, il s’agit de la même technologie qu’APP V utilisée en entreprise.

Comment cela fonctionne ?

Le système va déjà faire un peu de magie pour faire fonctionner votre application :

• Assemblies tierces : le système de fichiers visible par votre application sera en fait une vue “mergée” de ce qu’il existe réellement : les DLLs provenant de l’OS sont disponibles au même niveau que celles de votre application. Ces dernières sont placées au moment de l’installation dans un dossier spécifique par application et évite ainsi que plusieurs applications utilisent une même dépendance (avec la gestion des versions et le fameux problème des “DLL Hell”). 
• Base de registre : il est possible d’écrire/lire la base de registre mais cela ne sera qu’une ruche spécifique à votre application. Il est ainsi impossible de lire les valeurs écrites par d’autres applications.
• Données de votre application : lorsque vous souhaiterez accéder au dossier de données de l’application, cela sera redirigé vers l’isolated storage de l’application UAP générée.

Aussi, comme toute application Universelle, un bac à sable d’exécution sera créé pour exécuter l’application. Dans celui-ci il sera possible d’exécuter n’importe quel code du Windows Runtime. Cependant, si votre application doit exécuter du code en tant que l’utilisateur (en mode "Full Trust”, en dehors du bac à sable donc), il sera possible de le faire dans un “process dédié” et communiquer avec votre application. Ce process “spécial” ne pourra cependant pas utiliser les APIs WinRT et devra communiquer avec le “bac à sable”’.

Quelles sont les limitations ?

Voici une liste des limitations connues pour le moment :

• Il est impossible de faire fonctionner l’application en mode “administrateur”
• Pas de communications inter-applications autres que celles déjà présentées ici ou là.
• Uniquement disponible sur le grand “Windows” desktop
• Pas possible de modifier la base de registre “système” ou d’une autre application.
• Il faut avoir un MSI de votre application.

La philosophie de migration imaginée par Microsoft

L’idée derrière cela est de permettre à une application classique d’utiliser toutes les fonctionnalités du Windows Runtime et de pouvoir petit à petit la transformer en application Universelle. L’objectif est bien sûr de pouvoir déployer sur toutes les plateformes Windows (Windows Mobile, Hololens, Xbox, IOT, etc.) et non plus uniquement Windows “classique”.

Les tâches à réaliser serait les suivantes :

• Migrer l’interface utilisateur de l’application en XAML,
• Faire évoluer les appels à des APIs “non présentes dans le SDK WinRT” : souvent l’équivalent est disponible d’une autre manière.
• Enlever le code exécuté en mode utilisateur/administrateur.

C’est par exemple ce que fait Microsoft avec le menu démarrer de Windows 10.

Conclusion

Microsoft nous promet un outil vraiment prometteur qui permettra aussi d’assurer une migration facile vers l’Universal App Platform en profitant des avantages du Store d’un point de vue déploiement. Une seule question subsiste : quand aura t’on cet outil ?