Appeler PowerShell script PS1 à partir d'un autre PS1 script à l'intérieur de Powershell ISE

Question

Je veux l'exécution d'un appel pour un myScript1.ps1 script à l'intérieur d'un second myScript2.ps1 script à l'intérieur de Powershell ISE.

Le code suivant dans MyScript2.ps1, fonctionne bien depuis l'administration Powershell, mais ne fonctionne pas dans PowerShell ISE :

#Call myScript1 from myScript2
invoke-expression -Command .\myScript1.ps1

J'obtiens l'erreur suivante lorsque j'exécute MyScript2.ps1 à partir de PowerShell ISE :

Le terme ". \myScript1.ps1 ' n'est pas reconnu comme le nom d'un cmdlet, d'une fonction, d'un fichier script ou d'un programme exploitable. Vérifiez l'orthographe du nom, ou si un chemin d'accès a été inclus, vérifiez que le chemin d'accès est correct et réessayez.

Answer 1

Pour exécuter facilement un fichier script dans le même dossier (ou sous-dossier de) que l'appelant, vous pouvez utiliser ceci :

# Get full path to the script:
$ScriptRoute = [System.IO.Path]::GetFullPath([System.IO.Path]::Combine($PSScriptRoot, "Scriptname.ps1"))

# Execute script at location:
&"$ScriptRoute"

Answer 2

Vous avez peut-être déjà trouvé la réponse à cette question, mais voici ce que je fais.

Je place généralement cette ligne au début de mon installation scripts :

if(!$PSScriptRoot){ $PSScriptRoot = Split-Path $MyInvocation.MyCommand.Path -Parent } #In case if $PSScriptRoot is empty (version of powershell V.2).  

Ensuite, je peux utiliser la variable $PSScriptRoot comme emplacement du script(chemin) actuel, comme dans l'exemple ci-dessous :

if(!$PSScriptRoot){ $PSScriptRoot = Split-Path $MyInvocation.MyCommand.Path -Parent } #In case if $PSScriptRoot is empty (version of powershell V.2).  

Try {
If (Test-Path 'C:\Program Files (x86)') {
    $ChromeInstallArgs= "/i", "$PSScriptRoot\googlechromestandaloneenterprise64_v.57.0.2987.110.msi", "/q", "/norestart", "/L*v `"C:\Windows\Logs\Google_Chrome_57.0.2987.110_Install_x64.log`""
    Start-Process -FilePath msiexec -ArgumentList $ChromeInstallArgs -Wait -ErrorAction Stop
    $Result= [System.Environment]::ExitCode
} Else {
    $ChromeInstallArgs= "/i", "$PSScriptRoot\googlechromestandaloneenterprise_v.57.0.2987.110.msi", "/q", "/norestart", "/L*v `"C:\Windows\Logs\Google_Chrome_57.0.2987.110_Install_x86.log`""
    Start-Process -FilePath msiexec -ArgumentList $ChromeInstallArgs -Wait -ErrorAction Stop
    $Result= [System.Environment]::ExitCode
    }

} ### End Try block

Catch  {
    $Result = [System.Environment]::Exitcode
    [System.Environment]::Exit($Result)
   }
[System.Environment]::Exit($Result)

Dans votre cas, vous pouvez remplacer

Démarrer le processus... ligne avec

Expression d'invocation $PSScriptRoot \ScriptName.ps1

Vous pouvez en savoir plus sur les variables automatiques $MYINVOCATION et $PSScriptRoot sur le site de Microsoft : https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.core/about/about_automatic_variables

Answer 3

Je soumets mon exemple pour considération. Voici comment j'appelle du code depuis un contrôleur script dans les outils que je fabrique. Les script qui font le travail doivent aussi accepter des paramètres, donc cet exemple montre comment les passer. Il suppose que le script appelé est dans le même répertoire que le contrôleur script (script faisant l'appel).

[CmdletBinding()]
param (
[Parameter(Mandatory = $true)]
[string[]]
$Computername,

[Parameter(Mandatory = $true)]
[DateTime]
$StartTime,

[Parameter(Mandatory = $true)]
[DateTime]
$EndTime
)

$ZAEventLogDataSplat = @{
    "Computername" = $Computername
    "StartTime"    = $StartTime
    "EndTime"      = $EndTime
}

& "$PSScriptRoot\Get-ZAEventLogData.ps1" @ZAEventLogDataSplat

Ce qui précède est un contrôleur script qui accepte 3 paramètres. Ceux-ci sont définis dans le bloc param. Le contrôleur script appelle ensuite le script nommé Get-ZAEventLogData.ps1. A titre d'exemple, ce script accepte également les 3 mêmes paramètres. Lorsque le contrôleur script appelle le script qui fait le travail, il doit l'appeler et passer les paramètres. L'image ci-dessus montre comment je le fais par splatting.

Answer 4

J'ai eu un problème similaire et je l'ai résolu de cette façon.

Mon répertoire de travail est un dossier général script et plusieurs dossiers particuliers script dans le même Root, j'ai besoin d'appeler le dossier particulier script (qui appelle le script général avec le paramètre du problème particulier). Le répertoire de travail est donc le suivant

\Nico\Scripts\Script1.ps1
             \Script2.ps1
      \Problem1\Solution1.ps1
               \ParameterForSolution1.config
      \Problem2\Solution2.ps1
               \ParameterForSolution2.config

Solutions1 et Solutions2 appellent le PS1 dans le dossier scripts en chargeant le paramètre stocké dans ParameterForSolution. Donc dans powershell ISE j'exécute cette commande

.\Nico\Problem1\Solution1.PS1

Et le code dans Solution1.PS1 est :

# This is the path where my script is running
$path = split-path -parent $MyInvocation.MyCommand.Definition

# Change to root dir
cd "$path\..\.."

$script = ".\Script\Script1.PS1"

$parametro = "Problem1\ParameterForSolution1.config"
# Another set of parameter Script1.PS1 can receive for debuggin porpuose
$parametro +=' -verbose'

Invoke-Expression "$script $parametro"

Answer 5

J'ai eu un problème avec ça. Je n'ai pas utilisé d'astuces $MyInvocation pour le réparer. Si vous ouvrez l'ISE en cliquant droit sur un fichier script et en sélectionnant edit puis ouvrir le deuxième script à partir de l'ISE, vous pouvez invoquer l'un à partir de l'autre en utilisant simplement la méthode normale . \<strkeep>script<strkeep>.ps1 syntaxe. Ma supposition est que l'ISE a la notion d'un dossier courant et que l'ouvrir comme ceci définit le dossier courant au dossier contenant le scripts. Lorsque j'invoque un scripts à partir d'un autre dans une utilisation normale, j'utilise simplement . \<strkeep>script<strkeep>.ps1 Je pense que c'est une erreur de modifier le script juste pour le faire fonctionner correctement dans l'ISE...