Bénéficier d’une diffusion par le Store sans avoir à tout reprogrammer en UWP ça serait cool non ? Et bien c’est possible et je vais vous le prouver !
Desktop Application Converter (DAC)
Anciennement “projet Centennial” dont j’avais parlé il y a un peu plus d’un an dans ce billet Projet Centennial : Win32/.NET dans le Store. Je renvoie le lecteur intéressé car les bases y étaient présentées.
Hier il s’agissait comme d’accoutumée sur Dot.Blog de vous offrir une vision sur le long terme pour prendre de bonnes décisions. Aujourd’hui, et comme presque aussi souvent, il s’agit de vous montrer que ce que j’annonçais alors est devenu la réalité d’aujourd’hui et que bien avisés ceux qui auront suivi mes conseils !
Car le projet Centennial n’est plus un projet, une simple idée séduisante, mais bien une énorme machine à fabriquer des applis pour le Windows Store à partir de tout et n’importe quoi du moment que ça tourne sur un PC !
Bien entendu en partant d’une application WPF vous ne pourrez pas faire tourner l’appli Windows Store résultante sur une tablette Windows 10 S mais qui s’intéresse au revival de la Surface 1 en WinRT ? De même votre appli certifiée Windows Store ne tournera pas non plus sur un Windows Phone. Mais cela n’existe plus, le dommage est donc assez minime… D’ailleurs pour la mobilité vous connaissez mon autre conseil : Xamarin, j’en parlais des années avant que cela ne devienne un produit Microsoft et je reste sur cette voie qui permet d’ailleurs de générer de l’UWP sans se fatiguer.
UWP c’est très bien mais il est vrai que son universalité sans Windows Phone n’en fait qu’un doublon de WPF. Et quand on a un bon logiciel en WPF il n’y a aucune raison de se lancer dans une refonte en UWP aujourd’hui. On peut en revanche regretter de ne pas avoir l’exposition d’une app UWP… Mais justement même cette différence là n’existe plus !
Et il existe bel et bien de nombreux avantages à convertir une application Windows classique en App Windows Store :
- L’accès au Store pour faire connaître et distribuer votre application
- La possibilité d’être rémunérer sans passer par des tiers plus ou moins fiables
- Le sérieux que cela donne à votre application, certifiée sans virus par Microsoft et pour décider un utilisateur potentiel rassurer c’est essentiel
- Bénéficier du système de mise à jour automatisé des applis du Store, encore un service qui touchera l’utilisateur
- Une installation ultra simplifiée
- Une désinstallation d’un simple clic sans risque de laisser des morceaux partout
Etc, la liste est en fait assez longue d’autant que ce choix ne vous interdit pas de continuer à distribuer votre application par d’autres moyens, le Store ne demandant pas l’exclusivité…
En quelques clics…
Oui bon là j’ai un peu survendu le zinzin. Mea culpa.
Mais en suivant mes instructions ça ne devrait pas être si long que ça.
Le processus décrit dans le billet en référence plus haut est assez simple, vous disposez d’une sorte de toolkit pour le convertisseur et vous pouvez l’utiliser soit entièrement manuellement soit de façon automatique.
Dans la version automatique, je vais faire court pour ne pas vous lasser et passer à un exemple, en plus du convertisseur vous devez télécharger une image système (la même version que votre Windows, forcément un Windows 10 anniversary au minimum). Ca sent la virtualisation à plein nez, et vous avez raison !
En gros, le mode automatique utilise la notion de “Conteneur”, fonctionnalité de Windows 10, qui permet de créer un espace d’exécution protégé du reste de votre machine. A l’intérieur de ce conteneur le convertisseur appelle l’installation de votre logiciel et espionne tout ce qu’il fait (fichiers copiés ici et là, registry modifiée, DLL utilisées…). Il note tout avec précision. A la fin de l’installation de votre logiciel (qui doit pouvoir s’exécuter en mode dit silencieux) le convertisseur regroupe tout le nécessaire dans une série de répertoires et génère un APPX, une appli du Windows Store !
Bien entendu il est possible grâce au mode manuel et même en automatique de personnaliser certaines choses, supprimer des fichiers inutiles, modifier le nom du logiciel et plein d’autres choses plus complexes. Notamment, puisqu’à la fin il s’agit d’une vraie appli Windows 10, il est possible de tirer profit des fonctionnalités de l’OS et plutôt qu’une simple icône dans le menu on peut créer une tuile, voire une tuile animée, le grand luxe ! En fait presque tout ce qui est possible en Windows 10 est disponible.
Le côté obscur ?
Il y en a forcément un. La magie a ses limites. Comme je le disais cela transforme une appli console ou WPF en App du Store mais uniquement pour tourner sur un PC, cela ne devient pas de l’UWP par enchantement qui conserve son intérêt propre. Mais si vous ne visez pas Windows Phone (il faut bien viser !) ni la XBox ou les Hololens il faut dire que ce cela ne sera pas vraiment gênant. Après tout, ce qui compte pour un soft PC c’est de tourner sur des PC… Et on parle bien ici de cela : un soft conçu pour le PC est transformé pour tourner dans le même contexte mais avec les avantages du Store. Et c’est déjà beaucoup !
Moralité si vous désirez créer un logiciel cross-plateforme, suivez mes conseils en utilisant Xamarin et en générant au passage une appli UWP qui elle va directement sur le Store.
Mais si vous décidez de créer, ou possédez déjà, une belle application WPF ou même Windows Forms ou un utilitaire console et que vous n’avez pas envie de tout reprogrammer en Xamarin ou en UWP, alors le DAC est fait pour vous ! En deux coups de cuillère à pot vous pourrez diffuser votre soft sur le Windows Store, gagner de l’argent avec, le mettre à jour facilement, et tous les avantages qui vont avec ce mode de distribution (sans oublier la petite obole versée à Microsoft qu’il faut donc considérer comme un geste charitable pour racheter votre âme noircie par tous les warez de Windows ou de Office que vous avez utilisés dans votre vie !).
Exemple et astuces !
Tout cela resterait bien abstrait si je m’arrêtais là mais ce n’est pas mon genre vous le savez, si j’en parle c’est que j’ai testé et si j’ai testé je vous en fait profiter, c’est le principe même de Dot.Blog !
Je vais partir d’une application WPF qui n’a vraiment pas du tout été pensée pour aller sur le Store pour la bonne raison qu’elle a été créée bien avant que ce dernier n’existe. Il s’agit d’un utilitaire précieux, le viewer de log de Log4Net que j’ai publié en open source sur Codeplex et qui vient de migrer sur GitHub (voir mon biller d’hier).
J’ai d’ailleurs fait un fork de la version publiée sur GitHub évoquée hier. En effet je vais laisser cette version purement Win32 en l’état, chacun aillant la possibilité de l’utiliser ou de la modifier, et je suis parti d’une copie pour fabriquer la version “Windows Store”.
Le nouveau repository pour la version utilisée dans cet article est https://github.com/odahan/LogViewerForLog4Net
la première étape a été de faire le ménage dans le code, comme par exemple virer le thème sombre, changer deux ou trois petites choses mineures, ajouter un gestionnaire pour les erreurs non gérées, etc. Bref des choses qui n’ont en réalité pas grand chose à voir avec l’exercice mais c’est l’occasion qui crée le larron ne dit-on pas…
Une fois ce joli soft WPF fonctionnel je me suis lancé dans la transformation dont voici les principales étapes :
Obtenir le DAC
Le Desktop Application Converter se présente sous la forme d’une appli console qui est distribuée gratuitement via le Windows Store (a-t-elle utilisée elle-même le DAC ? !). Pour la télécharger aller ici : https://aka.ms/Converter
Une fois installée vous devez obtenir une image système (pour le mode automatique, celui que je vous conseille). L’image doit correspondre exactement à la version de votre Windows de travail. Comptez dans les 3,5 Go à télécharger pour obtenir le fichier WIM que vous placerez où vous voudrez sur l’un de vos disques. Pour les images c’est ici que ça se passe : https://aka.ms/ConverterImages
Comme les plus curieux ne pourront pas trouver ici toute la documentation, ce n’est pas mon but, ils pourront bien entendu télécharger cette dernière ici : https://aka.ms/ConverterDocs
Installer le DAC
C’est une app distribuée par le Store donc la demander c’est l’installer… Mais le DAC n’est qu’une appli console qui va s’ajouter dans votre menu. Et si vous la lancez elle ne fera rien. D’abord il faut toujours l’exécuter en mode Admin (donc clic droit lancer en mode Administrateur). Ensuite il faut installer l’image système. Eventuellement si cela n’est pas fait il faudra activer le mode conteneur de Windows 10. Mais le DAC semble s’en charger si ce n’est pas fait (avec un redémarrage à prévoir).
Je vous passe les détails complets de ces manipulations que vous trouverez facilement sur le Web, en général tout le monde sait bien recopier la doc, c’est après que ça devient plus sioux…
Les trois modes du DAC
Selon le cas qui se présente on peut exécuter le DAC dans trois modes différents :
- Le mode exécutable
- le mode MSI
- le Setup
Si vous devez convertir un simple exécutable, comme c’est le cas dans cet exemple, vous utiliserez le premier mode. Si votre application dispose d’une installation MSI, le second et si elle dispose d’un Setup.exe le troisième. La différence se trouve dans la commande à utiliser mais le principe est le même.
La façon dont le DAC explore votre application dépend bien entendu du mode et il s’adapte à toutes ces situations automatiquement pour peu qu’on l’invoque correctement.
Convertir LogViewer for Log4Net
Sous Visual Studio j’ai fait le ménage dans le projet, je l’ai testé, et j’ai généré un exécutable en mode Release. Dans le répertoire de ce nom (sous \Bin\Release donc) se trouvent ainsi tous les fichiers nécessaires à son fonctionnement, dont l’exe, mais pas seulement.
Cela ressemble à cela :
Il n’y a pas de Setup ou de MSI pour cette application. Si on souhaite la déployer il faut copier tous les fichiers de l’arborescence. On peut simplifier en créant un zip par exemple mais ce n’est pas très “friendly”.
L’application utilise elle-même Log4Net pour logger son activité. Elle utilise les effets Microsoft.Expression pour WPF, les interactions etc, des choses bien sympathiques mais qui réclament le déploiement des DLL correspondantes.
On voit qu’un setup intégré serait malgré tout un plus pour une simple application de ce type. Et qu’un désinstalleur efficace n’oubliant rien le serait aussi… Et comme il faut prévoir des évolutions à distribuer, une mise à jour automatiser de type Windows Store serait le must…
Et c’est possible !
Nous avons le DAC, l’image système qui matche la version de notre Windows et le soft en mode Release qu’on désire convertir. Il ne manque rien. Sauf quelques manips…
Pour info on suppose que la machine est ok, donc sous Windows 10 anniversay minimum, avec un processeur 64 bits disposant du Hardware Assisted Virtualization et du SLAT (Second Level Address Translation) le tout saupoudré d’un SDK Windows 10 à jour. Visual Studio n’est pas utile (sauf pour créer le soft WPF mais pas pour l’opération de conversion en elle-même).
Rappelons aussi que toutes les manips se font en mode admin, même le DAC doit être lancé en pensant à faire clic droit / mode Admin.
La conversion par le DAC
Une fois lancé en mode admin le DAC se présente donc comme une simple console Windows avec ligne de commande interactive.
Pour convertir LogViewer et comme je ne dispose pas d’un setup ou d’un MSI, je vais utiliser la variante pour exécutable. Ce qui va donner la commande suivante (je décompose les arguments mais tout s’écrit à la suite et les tirets font partie de la commande) :
DesktopAppConverter.exe
-Intaller D:\LogViewer\Bin\Release
-AppExecutable LogViewer.exe
-Destination D:\MyLogViewer
-PackageName MyLogViewer
-Publisher “CN=DotBlog”
-Version 3.0.0.0
-MakeAppx
-Verbose
Dans la vraie vie (pas les tests) le nom du package et celui de l’éditeur doivent correspondre à ceux réservés dans le Windows Store. Ici tout se fera en local sur ma machine sans aller jusqu’à la validation pour le Store qui fonctionne exactement comme pour une application UWP normale.
Vous trouverez dans la documentation la signification exacte de tous les arguments je ne vais pas m’étendre ici sur ce sujet. On comprend qu’il faut indiquer le répertoire où se trouve le soft à convertir, son nom d’exécutable, le répertoire de destination etc.
A la sortie de ce processus assez court le DAC a créé une nouvelle arborescence :
Oubliez pour l’instant les trois derniers fichiers, je vais y venir bientôt. Le reste est donc produit par le DAC. On trouve un appx, c’est notre logiciel converti et packagé prêt à être distribué par le Windows Store !
Signature
C’est là que les ennuis commencent pour la démo alors que dans la réalité cette étape ne serait pas à réaliser, c’est un comble !
En effet, lors de la procédure de validation, Microsoft signe les logiciels du Store. C’est une opération que le développeur n’a pas à faire.
Or, Windows 10 étant bien protégé, si vous double-cliquez sur l’Appx, vous obtiendrez un message vous indiquant que le paquet n’est pas signé et que l’OS ne veut pas l’installer.
Donc pour nos tests il faut bien signer le paquet. Mais avec quoi ?
Si vous disposez d’un certificat d’entreprise, si vous êtes un fana de sécurité informatique tout cela vous semblera une rigolade. Si comme moi la plomberie informatique vous donne des pustules (aussi noble soit cette spécialisation je ne dis pas) c’est là que vous avez envie de passer à autre chose et de fuir lâchement devant l’épreuve qui s’annonce. Mais ma détestation de tous ces trucs alambiqués en ligne de commande dont les docs sont imbuvables n’égale pas ma détermination, je ne renonce jamais devant l’obstacle même si je sais que ça va me taper sur les nerfs 
Et là encore çà n’a pas loupé. Mais bon, un travail pas fini c’est un travail pas commencé, alors il faut finir.
D’abord il nous faut un certificat. Comme je ne vais pas aller en acheter un pour la démo, il faut en fabriquer un “pour de faux”.
On ouvre une console Visual Studio (pas VS, la console de développement). On s’assure de le faire en mode Admin on ne sait jamais…
Cliquez sur l’image pour jouir de toute la splendeur ésotérique de cette commande pensée certainement par des âmes torturées… Ne me demandez pas la signification de tous ces chiffres j’ai compris sur l’instant en suivant une doc mais j’ai déjà oublié ! Il y a une histoire de validité du certificat dans le temps et le fait de pouvoir s’en servir pour signer des logiciels mais bon, il faut être de grands malades pour inventer des trucs pareils au lieu d’options écrites avec de vrais mots.
Bref ici j’ai créé deux fichiers, TestKey.pvk et TestKey.cer.
C’est super mais ça ne sert à rien… Il faut un PFX pour signer.
Donc créons un PFX à partir de ces fichiers (pourquoi pas un utilitaire pour créer des pfx de test en une opération ?). Ce qui donne :
Idem, cliquez pour voir l’image en 100%.
Les zones brouillées sont des mots de passe. Le premier est celui qui est demandé lorsqu’on exécute la commande précédente, c’est la protection du certificat.
Le second est le mot de passe du PFX lui-même (pourquoi faire simple quand on peut faire compliqué).
Et grâce à cela le fichier TestKey.pfx vient d’être créé ! Les trois fichiers générés sont ceux qui se trouvent dans la capture plus haut et que je vous avais demandé d’oublier un instant.
Trois fichiers, des lignes de commande que même un mauvais film sur les hackers n’oserait pas inventer (“tu rigoles robert, personne n’y croira c’est trop gros !”), et toujours pas de signature !
Je veux signer !
On se calme, on y arrive. Ce coup-ci on sort SignTool du placard, c’est lui qui sait le faire.
Toujours pareil, cliquez pour avoir une image en 100%. Et toujours la même chose, la zone brouillée est le mot de passe, celui du PFX (pas celui du certificat, ruse !).
La cible est bien l’Appx généré par le DAC.
Attention à la feinte, précisez l’algorithme Sha 256, sinon ? Rien, ça fonctionne. Enfin jusqu’au lancement de l’Appx qui donne un message d’erreur très dur à décrypter (normal c’est pour les pros de la sécurité) qui explique vaguement qu’il y a un problème d’algorithme. Je suppose que le mode par défaut de SignTool ne convient pas aux Appx.
Je me dois de le répéter : Tout ce cirque ne doit être fait que pour les tests, en vrai c’est le Store Microsoft qui se charge de signer les softs !
Un petit détail encore…
Si vous tentez de lancer l’Appx maintenant ça coincera encore.
C’est bien gentil de vouloir signer des packages en créant des certificats mais vous vous prenez pour qui hein ? Vous n’êtes pas une autorité racine… Donc votre certificat à deux eurocents il ne passe pas. Windows le sait.
Clic droit sur l’Appx fraichement signé, propriétés, patati patata, pour en arriver à l’onglet de sécurité où se trouvent les signatures numériques. Là il faudra demander à voir les détails du certificat et à l’installer ! Faites le sur la machine local (et non l’utilisateur local), ne laissez pas l’utilitaire décider de l’emplacement et choisissez un magasin d’autorité racine pour avoir la paix.
Si c’est pas un truc de psychopathe ça… et encore je ne n’ai pas mis les deux derniers dialogues (choix de l’emplacement et du magasin) !
Bon, notre certificat en carton est maintenant reconnu comme un grand chef sioux, on va pouvoir tester enfin le résultat du DAC !
Une nouvelle App pour le Store !
On double clic l’Appx :
C’est beau hein ? Le logo du soft a même été récupéré pour illustrer l’installation. C’est là que la personnalisation de l’Appx est utile, pour changer les images et en mettre de plus jolies. On clic sur “installer” et en quelques secondes tout est en place.
Il n’y a plus qu’à l’exécuter directement ou bien, ce qui sera ensuite la seule façon de le faire, en passant par le menu de Windows :
Incroyable non ?
Et pour désinstaller, un simple clic droit comme toute application du Store. Et il ne restera plus rien, pas de DLL, pas d’entrées de registry, rien du tout.
Conclusion
Si on fait abstraction de la signature pour les tests, la conversion d’une application WPF en App pour le Windows Store s’effectue très rapidement et ça marche plutôt très bien. On peut toujours créer des softs WPF pour Windows, encore plus même car on sait maintenant qu’ils peuvent devenir des Apps pour le Store comme une application UWP mais sans remettre en question l’existant tout en bénéficiant de tous les avantages de ce mode de distribution.
Microsoft a perdu beaucoup de temps à vouloir imposer WinRT puis les apps Windows 10. Ils auraient du commencer par le DAC, et là tout le monde aurait été.. d’acc !
Stay Tuned !