mayho33
Goto Top

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):
[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:
error

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

Content-ID: 587343

Url: https://administrator.de/contentid/587343

Ausgedruckt am: 23.11.2024 um 22:11 Uhr

143611
143611 13.07.2020 um 19:49:56 Uhr
Goto Top
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
mayho33
mayho33 14.07.2020 um 14:25:27 Uhr
Goto Top
Zitat von @143611:

Moin,

die ISE bringt - AFAIK - einen eigenen Powershell-Host mit.

Das ist aber nichts neues. Das hat die ISE seit Entstehen schon so an sich, oder irre ich mich?

Dies sollte sich mit Get-Host in der ISE und der normalen PS-Konsole verifizieren lassen;

OK! Aber sollte sich ein CmdLet das man in der ISE importiert nicht im selben Kontext befinden?

Danke für den Tipp, aber das löst leider mein Problem nicht.

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...

Das könnte ich noch ausprobieren, aber ich darf meine Kollegen nicht überfordern. Die werden sonst mürrisch und steigen gleich wieder auf Batch um. :P

Grüße!
143611
Lösung 143611 14.07.2020 um 14:50:26 Uhr
Goto Top
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
mayho33
mayho33 14.07.2020 aktualisiert um 15:26:10 Uhr
Goto Top
Zitat von @143611:

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'...


Der Hinweis war trotzdem nicht schlecht. in der PS-Console bekomme ich eine andere Fehlermeldung.

"Der Objektverweise wurde nicht auf eine Objektinstanz festgelegt"

Das lustige daran ist eben, dass ich nichts verändert habe. Hauptsächlich statische Klassen und Methoden. Und das eine CmdLet das den Fehler wirft ließt nur die im Script gesetzen "env:Variablen aus.

MS wird immer suspekter!!
mayho33
mayho33 20.07.2020 um 00:44:42 Uhr
Goto Top
Ich verstehe MS nicht. Die ISE spinnt definitiv. In VS Code funkt alles, in der PS Console funkt alles, via CMD funkt alles und VS C# sowieso.

Ich frage mich nur wie die ganzen anderen C# CmdLet die MS so eingebaut hat, kein Problem haben können.

Nach einer Prüfung mit ILSpy konnte ich keine signifikanten Unterschiede erkennen, außer natürlich die funktionellen, weil ich ja was anderes mache.

VS Code ist schon ganz nett, aber zum Entwickeln schon tlw. sehr umständlich in der Bedienung.
Was mich am meisten stört ist, dass im Terminal kein Intellisence funktioniert.

Danke auf jeden Fall @143611. Ich muss wohl damit leben.

Grüße!