En complément des tests des applications par le mode test "Go" en cours de développement, il est bien sûr fondamental d'effectuer des essais en situation de production sans l'environnement de développement. Ce test en réel est nécessaire pour les applications, et les installations des applications.

Cette phase nécessite donc de déployer sur un autre poste que celui de développement, physique ou virtuel, dans lequel on fera la copie et le test de l'installation de l'application, et de l'application.

Bon à savoir, grâce à la "SandBox" intégrée aux dernières mises à jour de Windows 10, une solution existe et permet tout en restant sur son poste de développement, sans autre machine, sans installer une solution de virtualisation, de tester l'application dans un environnement totalement isolé dans lequel l'application testée sera la seule installée. Cela peut être bien pratique pour un test "intermédiaire" avant de basculer sur de vrais postes clients, ou de "pré-prod", recette... Cette solution repose donc sur le bac à sable, la "SansBox" incluse dans Windows 10 à partir de sa version 1903. Pour résumer les possibilités de cette "SandBox" :

• un nouveau Windows est lancé à l'intérieur de la session de l'utilisateur,
• ce Windows est vierge de toute installation,
• il est sans lien avec l'hôte, sans aucun accès à ses périphériques, disques et donc applications installés,
• Il suffit donc de copier dans cette SandBox l'installation ou l'application à tester, pour l'exécuter,
• la fermeture du bac à sable supprime l'intégralité de ce qui a pu être créer ou installé dans cette session temporaire de Windows.

On peut affiner le processus en combinant deux possibilités :

• une de WINDEV : l'exécution d'un script personnalisé donné dans les actions après génération de la configuration qui permet de créer l'exécutable,
• une de Windows "SandBox" : le bac à sable peut être lancé de façon personnalisée avec :
  • un accès à un dossier donné de du poste de développement,
  • le lancement d'une commande à l'ouverture de Windows "bac à sable".

On peut donc en même temps que la création de l'exécutable, avoir un fichier de paramètre d'un bac à sable qui lance directement l'exécutable généré, dans un Windows vierge !

Le mode opératoire complet est le suivant :

• clic droit sur la configuration de projet qui permet de créer l'exécutable puis "Description",
• dans le volet "Général" bouton "Action après génération",
• donner le script suivant :
  
  

  • set "DossierWSB={$RepObjetGenere}"

  • set "FichierWSB={$NomObjetGenere}"

  • set "ExtWSB=.WSB"

  • call set "FichierWSB=%DossierWSB%\%FichierWSB%%ExtWSB%"
    
    

  • set "DossierEXE=C:\Users\WDAGUtilityAccount\Desktop"

  • set "FichierEXE={$NomConfig}\{$NomObjetGenere}"

    call set "EXE=%DossierEXE%\%FichierEXE%"
    
    

  • ECHO ^<Configuration^> >"%FichierWSB%"

  • ECHO ^<MappedFolders^> >>"%FichierWSB%"

  • ECHO ^<MappedFolder^> >>"%FichierWSB%"

  • ECHO ^<HostFolder^>{$RepObjetGenere}^</HostFolder^> >>"%FichierWSB%"

  • ECHO ^<ReadOnly^>true^</ReadOnly^> >>"%FichierWSB%"

  • ECHO ^</MappedFolder^> >>"%FichierWSB%"

  • ECHO ^</MappedFolders^> >>"%FichierWSB%"

  • ECHO ^<LogonCommand^> >>"%FichierWSB%"

  • ECHO ^<Command^>"%EXE%"^</Command^> >>"%FichierWSB%"

  • ECHO ^</LogonCommand^> >>"%FichierWSB%"

  • ECHO ^</Configuration^> >>"%FichierWSB%"

• valider :

A la prochaine création de l'exécutable, dans son dossier de génération un nouveau fichier sera créé avec le nom de l'exécutable, et l'extension .WSB. L'extension est automatiquement reconnue par windows. Il suffit de faire un double clic dessus afin de lancer l'exécutable, dans une "SandBox". On peut éventuellement automatiser le lancement du bac à sable, il suffit en toute dernière ligne du script d'ajouter : "%FichierWSB%"

A noter que le script proposé ici nécessite de ne pas cocher dans les options de la description du projet "Générer toutes les configurations dans le répertoire Exe..." :

A savoir concernant le bac à sable "SandBox" :

• lorsque l'application s'exécute dans la "SandBox", elle est déconnectée du domaine et a un utilisateur nommé WDAGUtilityAccount,
• la page suivante documente les possibilités du fichier WSB,
• l'utilitaire WDDebug(64).exe pour tester l'application sur un poste utilisateur peut être copié dans la "SandBox" afin de permettre le débogage de l'application lancée,
• l'application dans la "SandBox" peut accéder à une base HFSQL client/serveur du réseau du poste de développement...