Komischer BUG (the handle is invalid) mit Powershel in Verbindung mit VisualStudio (2019 Prof) C-Sharp CmdLets
Hi @ All
Ich entwickle gerade ein C#-Cmdlet das im Unternehmen die Installations-Routinen via SCCM standardisisieren soll.
Seit gestern habe ich plötzlich einen eher unlustigen Fehler ohne etwas geändert zu haben, dem ich nicht auf die Schliche komme und brauche eure Unterstützung, wie folgt:
Jeder/Jede, der/die ein Install-Script erstellt, verwendet eine PS1-Vorlage in der er/sie die notwendigen Schritte einträgt.
BSP:
Uninstall-MSI -ProductCode {1234-1234-12343212-1234-1234} -Caption "meine MSI"
Uninstall-RegistryKey -KeyFile "<SourceFolder>\meine.reg" -TargetSCope 'x64'
Install-MSI -FilePath "<SourceFolder>\meine.MSI" -TransForms "<SourceFolder>\meine.mst" -Caption "meine MSI Installation"
Dem vorangehend sind einige Parameter damit man via SCCM noch etwas steuern kann (snipped):
Damit ich die das Cmdlet testen kann habe ich in meiner Soulution folgendes hinterlegt:
Funktioniert wunderbar! Wenn ich den Debugger starte öffnet sich die Powershell-Console und ich kann den Ablauf des C#-Codes verfolgen bzw. eingreifen. Eh bekannt!
Führe ich mein Ps1 in der cmd aus geht auch alles einwandfrei.
Nun das Lustige Phänomen!:
Führe ich die Install.ps1 aber in der ISE aus und da will der Paketierer ja sein Script entwickeln bzw die notwendigen Teile wie oben beschrieben einfügen, dann bekomme ich folgenden Fehler:
Das benannte Commando "Update-Environment" ließt eigentlich nur die $env:Variablen und speichert sie für die spätere Verwendung.
Hat jemand eine Idee wo das Problem liegt?
Danke für die Unterstützung!
Mayho
Ich entwickle gerade ein C#-Cmdlet das im Unternehmen die Installations-Routinen via SCCM standardisisieren soll.
Seit gestern habe ich plötzlich einen eher unlustigen Fehler ohne etwas geändert zu haben, dem ich nicht auf die Schliche komme und brauche eure Unterstützung, wie folgt:
Jeder/Jede, der/die ein Install-Script erstellt, verwendet eine PS1-Vorlage in der er/sie die notwendigen Schritte einträgt.
BSP:
Uninstall-MSI -ProductCode {1234-1234-12343212-1234-1234} -Caption "meine MSI"
Uninstall-RegistryKey -KeyFile "<SourceFolder>\meine.reg" -TargetSCope 'x64'
Install-MSI -FilePath "<SourceFolder>\meine.MSI" -TransForms "<SourceFolder>\meine.mst" -Caption "meine MSI Installation"
Dem vorangehend sind einige Parameter damit man via SCCM noch etwas steuern kann (snipped):
[CmdletBinding()]
Param
(
[Parameter(Mandatory=$false, ValueFromPipeline=$true, ValueFromPipelineByPropertyName=$true)][switch]$Uninstall,
[Parameter(Mandatory=$false, ValueFromPipeline=$true, ValueFromPipelineByPropertyName=$true)][Int]$Restart,
[Parameter(Mandatory=$false, ValueFromPipeline=$true, ValueFromPipelineByPropertyName=$true)][string]$Priority = 'NORMAL',
[Parameter(Mandatory=$false, ValueFromPipeline=$true, ValueFromPipelineByPropertyName=$true)][switch]$Silent
)
PROCESS {
if(-not $PSScriptRoot) {
$PSScriptRoot = Split-Path $MyInvocation.MyCommand.Path -Parent
}
#region ---------------------- SET LOCAL VARIABLES HERE -------------------------------
[string]$env:SourceFolder = "$PSScriptRoot\Source"
[switch]$env:Silent = $Silent
[string]$env:Priority = $Priority
[string]$env:DisplayName = 'SAP GUI 1.3.4.675 with IXOS 10.5 and Business Explorer'
[string]$env:PackageAutor = 'UserName'
#endregion
#region -------------- IMPORTING MODULES and Set Start Values ----------------------------
try {
Import-Module "$env:SourceFolder\InstallTools.dll" -Global -Force
} catch{return 1}
Update-Environment
#endregion
#region -------------- Holt alle Functions aus dem importierten Modul --------------------
# Get-Command -Module InstallTools
#endregion
#region Examples / Hilfe zu finden in Toolset.psm1 Zeile 0 bis 73
#===============================================================================
# = = = = = = = = = = = UNINSTALL-SECTION = = = = = = = = = = = = = = = =
#===============================================================================
Uninstall-MSI -ProductCode {1234-1234-12343212-1234-1234} -Caption "meine MSI"
Uninstall-RegistryKey -KeyFile "$env:SourceFolder\meine.reg" -TargetSCope 'x64'
#===============================================================================
# = = = = = = = = = = = INSTALL-SECTION = = = = = = = = = = = = = = = = =
#===============================================================================
if(!$Uninstall) {
Install-MSI -FilePath "$env:SourceFolder\meine.MSI" -TransForms "<SourceFolder>\meine.mst" -Caption "meine MSI Installation"
...
...
}
Damit ich die das Cmdlet testen kann habe ich in meiner Soulution folgendes hinterlegt:
- Eingenschaften => Debuggen
- Externes Programm Starten: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
- BefehlszeilenArgumente: -Executionpolicy Bypass -noexit -file "<vollständiger Pfad zur\Vorlage.ps1"
Funktioniert wunderbar! Wenn ich den Debugger starte öffnet sich die Powershell-Console und ich kann den Ablauf des C#-Codes verfolgen bzw. eingreifen. Eh bekannt!
Führe ich mein Ps1 in der cmd aus geht auch alles einwandfrei.
powershell.exe -Executionpolicy Bypass -noexit -file "C:\___TestPackage\Install.ps1"
Nun das Lustige Phänomen!:
Führe ich die Install.ps1 aber in der ISE aus und da will der Paketierer ja sein Script entwickeln bzw die notwendigen Teile wie oben beschrieben einfügen, dann bekomme ich folgenden Fehler:
Das benannte Commando "Update-Environment" ließt eigentlich nur die $env:Variablen und speichert sie für die spätere Verwendung.
Hat jemand eine Idee wo das Problem liegt?
Danke für die Unterstützung!
Mayho
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 587343
Url: https://administrator.de/contentid/587343
Ausgedruckt am: 23.11.2024 um 22:11 Uhr
5 Kommentare
Neuester Kommentar
Moin,
die ISE bringt - AFAIK - einen eigenen Powershell-Host mit. Dies sollte sich mit Get-Host in der ISE und der normalen PS-Konsole verifizieren lassen;
hab' vor Jahren schon mal bemerkt, dass sich der Host teilw. erheblich im Verhalten unterscheidet und bin aus diesem Grund vom ISE nach VS Code zum Scripten gewechselt...
Viel Erfolg,
schleeke
die ISE bringt - AFAIK - einen eigenen Powershell-Host mit. Dies sollte sich mit Get-Host in der ISE und der normalen PS-Konsole verifizieren lassen;
hab' vor Jahren schon mal bemerkt, dass sich der Host teilw. erheblich im Verhalten unterscheidet und bin aus diesem Grund vom ISE nach VS Code zum Scripten gewechselt...
Viel Erfolg,
schleeke
Moin.
Jo, der Host ist schon seit Bestehen ein Anderer. Wie gesagt - ist nur 'ne Vermutung...hatte über die Jahre so viele kleine Ungereimtheiten bei der Ausführung innerhalb der ISE, die auf der Konsole nicht auftraten, dass ich's irgendwann auf die Implementierung des Hosts geschoben hab'...
Gruß,
schleeke
Jo, der Host ist schon seit Bestehen ein Anderer. Wie gesagt - ist nur 'ne Vermutung...hatte über die Jahre so viele kleine Ungereimtheiten bei der Ausführung innerhalb der ISE, die auf der Konsole nicht auftraten, dass ich's irgendwann auf die Implementierung des Hosts geschoben hab'...
Gruß,
schleeke