mscholtes/ps2exeModule pour compiler des scripts PowerShell en exécutables
Surcharge du grand script d'Ingo Karstein avec support GUI. La sortie et l'entrée GUI sont activées avec un seul interrupteur, de véritables exécutables Windows sont générés. Compile uniquement les scripts compatibles Powershell 5.x. Avec une interface graphique frontale optionnelle Win-PS2EXE.
Version du module.
Vous trouverez la version basée sur le script ici (https://github.com/MScholtes/TechNet-Gallery).
Auteur : Markus Scholtes
Version : 1.0.18
Date : 2026-06-06
PS C:\> Install-Module ps2exe
ou téléchargez depuis ici : https://www.powershellgallery.com/packages/ps2exe/.
Invoke-ps2exe .\source.ps1 .\target.exe
ou
ps2exe .\source.ps1 .\target.exe
compile « source.ps1 » dans l'exécutable target.exe (si « .\target.exe » est omis, la sortie est écrite dans « .\source.exe »).
ou lancez Win-PS2EXE pour une interface graphique avec
Win-PS2EXE
ps2exe [-inputFile] '<file_name>' [[-outputFile] '<file_name>']
[-prepareDebug] [-x86|-x64] [-lcid <id>] [-STA|-MTA] [-noConsole] [-conHost] [-UNICODEEncoding]
[-credentialGUI] [-iconFile '<filename>'] [-$embedFiles <hashtable>] [-title '<title>'] [-description '<description>']
[-company '<company>'] [-product '<product>'] [-copyright '<copyright>'] [-trademark '<trademark>']
[-version '<version>'] [-configFile] [-noOutput] [-noError] [-noVisualStyles] [-exitOnCancel]
[-DPIAware] [-requireAdmin] [-supportOS] [-virtualize] [-longPaths]
inputFile = Powershell script that you want to convert to executable (file has to be UTF8 or UTF16 encoded)
outputFile = destination executable file name or folder, defaults to inputFile with extension '.exe'
prepareDebug = create helpful information for debugging
x86 or x64 = compile for 32-bit or 64-bit runtime only
lcid = location ID for the compiled executable. Current user culture if not specified
STA or MTA = 'Single Thread Apartment' or 'Multi Thread Apartment' mode
noConsole = the resulting executable will be a Windows Forms app without a console window
conHost = force start with conhost as console instead of Windows Terminal (disables redirections)
UNICODEEncoding = encode output as UNICODE in console mode
credentialGUI = use GUI for prompting credentials in console mode
iconFile = icon file name for the compiled executable
embedFiles = files to embed given as hash, will be extracted to key of hash, source file names must be unique
(e.g. -embedFiles @{'Targetfilepath'='Sourcefilepath'} )
title = title information (displayed in details tab of Windows Explorer's properties dialog)
description = description information (not displayed, but embedded in executable)
company = company information (not displayed, but embedded in executable)
product = product information (displayed in details tab of Windows Explorer's properties dialog)
copyright = copyright information (displayed in details tab of Windows Explorer's properties dialog)
trademark = trademark information (displayed in details tab of Windows Explorer's properties dialog)
version = version information (displayed in details tab of Windows Explorer's properties dialog)
configFile = write config file (<outputfile>.exe.config)
noOutput = the resulting executable will generate no standard output (includes verbose and information channel)
noError = the resulting executable will generate no error output (includes warning and debug channel)
noVisualStyles = disable visual styles for a generated windows GUI application (only with -noConsole)
exitOnCancel = exits program when Cancel or "X" is selected in a Read-Host input box (only with -noConsole)
DPIAware = if display scaling is activated, GUI controls will be scaled if possible (only with -noConsole)
requireAdmin = if UAC is enabled, compiled executable run only in elevated context (UAC dialog appears if required)
supportOS = use functions of newest Windows versions (execute [Environment]::OSVersion to see the difference)
virtualize = application virtualization is activated (forcing x86 runtime)
longPaths = enable long paths ( > 260 characters) if enabled on OS (works only with Windows 10)
Un exécutable généré a les paramètres réservés suivants :
-? [<MODIFIER>] Powershell help text of the script inside the executable. The optional parameter combination
"-? -detailed", "-? -examples" or "-? -full" can be used to get the appropriate help text.
-debug Forces the executable to be debugged. It calls "System.Diagnostics.Debugger.Launch()".
-extract:<FILENAME> Extracts the powerShell script inside the executable and saves it as FILENAME.
The script will not be executed.
-wait At the end of the script execution it writes "Hit any key to exit..." and waits for a key to be pressed.
-end All following options will be passed to the script inside the executable.
All preceding options are used by the executable itself and will not be passed to the script.
PS2EXE peut être utilisé avec Powershell Core. Pour ce faire, installez simplement le module PS2EXE dans Powershell Core comme décrit ci-dessus. Mais comme .Net Core n'est pas livré avec un compilateur, le compilateur de .Net Framework est utilisé (.Net Framework et Powershell 5.1 sont inclus dans Windows).
Pour cette raison, PS2EXE ne peut compiler que des scripts compatibles Powershell 5.1 et génère des binaires .Net 4.x, mais peut toujours être utilisé directement sur chaque système d'exploitation Windows pris en charge sans dépendances.
Avec le paramètre -embedFiles suivi d'une table de hachage avec des chemins vers des fichiers, ces fichiers seront intégrés dans l'exécutable compilé. Au démarrage de l'exécutable, ces fichiers seront écrits sur le disque aux chemins spécifiés, par ex. -embedFiles @{'Targetfilepath1'='Sourcefilepath1';'Targetfilepath2'='Sourcefilepath2'}. Les noms de fichiers source doivent être uniques. Les chemins absolus et relatifs sont autorisés. Pour les chemins cibles, un chemin relatif commençant par '.\' est interprété comme relatif à l'exécutable, sans le préfixe '.\' comme relatif au chemin actuel au moment de l'exécution. Les répertoires sont créés automatiquement au démarrage si nécessaire. Dans le chemin cible, les variables d'environnement en notation cmd.exe comme %TEMP% ou %APPDATA% sont développées au moment de l'exécution. Un échec lors de la création d'un des fichiers intégrés arrêtera immédiatement l'exécution de l'exécutable compilé.
Les commandes d'entrée/sortie de base ont dû être réécrites en C# pour PS2EXE. Ne sont pas implémentés : Write-Progress en mode console (trop de travail) et Start-Transcript/Stop-Transcript (aucune implémentation de référence appropriée par Microsoft).
Par défaut, dans Powershell, les sorties des commandlets sont formatées ligne par ligne (sous forme de tableau de chaînes). Lorsque votre commande génère 10 lignes de sortie et que vous utilisez la sortie GUI, 10 boîtes de message apparaîtront, chacune attendant un OK. Pour éviter cela, redirigez votre commande vers la commande Out-String. Cela convertira la sortie en un tableau de chaînes avec 10 lignes, et toute la sortie sera affichée dans une seule boîte de message (par exemple : dir C:\ | Out-String).
PS2EXE peut créer des fichiers de configuration portant le nom de l'exécutable généré + « .config ». Dans la plupart des cas, ces fichiers de configuration ne sont pas nécessaires ; ce sont des manifestes qui indiquent quelle version du .Net Framework doit être utilisée. Comme vous utiliserez généralement la version actuelle du .Net Framework, essayez d'exécuter votre exécutable sans le fichier de configuration.
Les scripts compilés traitent les paramètres comme le script original. Une restriction vient de l'environnement Windows : pour tous les exécutables, tous les paramètres ont le type STRING. S'il n'y a pas de conversion implicite pour votre type de paramètre, vous devez convertir explicitement dans votre script. Vous pouvez même rediriger le contenu vers l'exécutable avec la même restriction (toutes les valeurs redirigées ont le type STRING).
Ne stockez jamais de mots de passe dans votre script compilé ! On peut simplement décompiler le script avec le paramètre -extract. Par exemple
Output.exe -extract:C:\Output.ps1
décompilera le script stocké dans Output.exe. Et remarquez : le script (intentionnellement) est stocké en texte clair dans l'exécutable !
Puisque PS2EXE convertit un script en exécutable, les variables liées au script ne sont plus disponibles. La variable $MyInvocation est définie à d'autres valeurs que dans un script.
En particulier, la variable $PSScriptRoot est vide - vous pouvez utiliser $ScriptRoot comme remplacement.
Vous pouvez obtenir $PSScriptRoot indépendamment de la compilation avec la ligne de code suivante :
if (!$PSScriptRoot) { $PSScriptRoot = $ScriptRoot }
Lorsqu'une fenêtre externe est ouverte dans un script avec le mode -noConsole (par exemple pour Get-Credential ou pour une commande nécessitant un shell cmd.exe), la fenêtre suivante s'ouvre en arrière-plan.
La raison en est qu'à la fermeture de la fenêtre externe, Windows tente d'activer la fenêtre parente. Comme le script compilé n'a pas de fenêtre, la fenêtre parente du script compilé est activée à la place, normalement la fenêtre de l'Explorateur ou de Powershell.
Pour contourner ce problème, $Host.UI.RawUI.FlushInputBuffer() ouvre une fenêtre invisible qui peut être activée. L'appel suivant de $Host.UI.RawUI.FlushInputBuffer() ferme cette fenêtre (et ainsi de suite).
L'exemple suivant n'ouvrira plus de fenêtre en arrière-plan comme le ferait un simple appel de « ipconfig | Out-String » :
$Host.UI.RawUI.FlushInputBuffer()
ipconfig | Out-String
$Host.UI.RawUI.FlushInputBuffer()