Discussion :

[MadCat34]

Bonjour,

Je souhaiterais savoir s'il était possible de creer un executable contenant X scripts powershell (en gros, pour cacher les scripts qui devront etre executé chez des clients)

En gros, une interface graphique avec X boutons (chaque boutons executerait un script.

Possible avec Visual Studio par exemple ?

[Flamby38]

Oui si tu connais un peu le langage .NET et visual studio c'est relativement simple à faire, puisque tu peux appeler des commandes système de la manière suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
System.Diagnostics.Process.Start("notepad.exe",options)

Il faudrait donc que tu fasses une forme avec des boutons et que sur le clic d'un bouton tu lances cette commande process.start.
Je pense que la commande a executer serait du style powershell.exe lenomdetonscript.

[Laurent Dardenne]

Salut,

(en gros, pour cacher les scripts qui devront etre executé chez des clients)

Tu veux masquer le code ou le crypter (pas de reverse possible) ?

Je pense que la commande a executer serait du style powershell.exe lenomdetonscript.

C'est une solution, mais quitte à faire un exécutable autant utiliser le framework Powershell (dotnet), car Powershell (PS) c'est un shell avec des gros morceaux de pouvoir dedans, mais c'est aussi un framework permettant d'intégrer son moteur au sein d'une appli dotnet et surtout d'interfacer des applications ( Exchange 2010, SqlServer 2008, VS 2010 ( qui intégre qq commandes il me semble, à confirmer), ...).
Ainsi, dans ton cas, ton application devient une "console" spécialisée/propriétaire.

Il est peut être possible, à vérifier, de trapper ton code via une configuration du/des profiles de PS. Bien que l'usage du paramètre de PS -noProfile régle ce problème, mais peut en amener d'autres. Bref c'est très simple, mais pas tant que ça (Je parle de PS pas de la réponse de Flamby38).

Un avantage, peut être minime dans ton cas, est la persistance des données entre les différents scripts. Puisque chaque exécution de PS crée puis détruit un contexte dédiée et autonome, aucune donnée ne peut être partagée.
Un autre, l'accés aux runspaces permettrait de lancer + scripts en // (version Deluxe)

Ceci dit il ne s'agit de rendre compliqué qq chose de simple, à toi de voir l'approche qui te convient.

[MadCat34]

En fait, je ne veux pas que les scripts soient visibles chez le client.
J'avais pensé intégrer les scripts comme ressources d'un projet VS (juste une interface avec 2-3 boutons pour exécuter les scripts)

Cette solution me convient plus ou moins...Il faut d'abord extraire le script...

[Laurent Dardenne]

Cette solution me convient plus ou moins...Il faut d'abord extraire le script...

D'où le hosting...
Un prg de démo.

Reste à savoir si tes scripts sont vraiment autonomes ou s'ils doivent utiliser des cmdlets tiers installés sur les postes.