PowerShell-Befehle werden nicht erkannt, wenn sie von VisualStudio 2017 aufgerufen werden
490
SimonS
Ich habe eine Funktion geschrieben, Deploy-Appdie unsere Entwickler in VisualStudio 2017 verwenden Build Events > Post-build event command line, um ihre Anwendung auf einer Netzwerkfreigabe zu veröffentlichen.
Ich habe eine andere Funktion geschrieben, die aufgerufen wird Invoke-Unlock, um Ordner und Dateien, die auf einem Remote-Server gesperrt sind, direkt von ihrem Computer zu entsperren.
Derzeit werden sie zunächst Invoke-Unlockin PowerShell manuell ausgeführt, sodass die Anwendung in der Netzwerkfreigabe entsperrt wird. Anschließend wird die App in VisualStudio bereitgestellt.
Jetzt habe ich einen Invoke-UnlockTeil davon gemacht, Deploy-Appdamit die Entwickler dies nicht mehr manuell tun müssen. Sie können es einfach mit einem solchen Schalter aufrufen Deploy-App xy -InvokeUnlock.
In verwende Invoke-Unlockich Get-SmbShareund Get-SmbOpenFile. Bei der manuellen Verwendung dieser Funktion hat alles gut funktioniert. Wenn sie jedoch in VisualStudio verwendet werden, wird folgende Fehlermeldung angezeigt:
9> Get-SmbShare : The term 'Get-SmbShare' is not recognized as the name of a cmdlet, function, script file, or operable 9> program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. 9> At \\server\install$\Powershell-Scripts\Functions\Invoke-Unlock.ps1:28 char:22 9> + $LocalPath = Get-SmbShare -CimSession $Session | ? { $_.Name ... 9> + ~~~~~~~~~~~~ 9> + CategoryInfo : ObjectNotFound: (Get-SmbShare:String) [], CommandNotFoundException 9> + FullyQualifiedErrorId : CommandNotFoundException 9> 9> Get-SmbOpenFile : The term 'Get-SmbOpenFile' is not recognized as the name of a cmdlet, function, script file, or 9> operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try 9> again. 9> At \\server\install$\Powershell-Scripts\Functions\Invoke-Unlock.ps1:32 char:9 9> + Get-SmbOpenFile -CimSession $Session | ? { $_.Path -like "$En ... 9> + ~~~~~~~~~~~~~~~ 9> + CategoryInfo : ObjectNotFound: (Get-SmbOpenFile:String) [], CommandNotFoundException 9> + FullyQualifiedErrorId : CommandNotFoundException 9>
Die SmbBefehle sind seit PowerShell 4.0 verfügbar. Alle Entwickler haben PowerShell 5.1 unter Windows 10.
Warum werden die Befehle nicht erkannt? Verwendet VisualStudio irgendwie eine andere PowerShell-Version? Hat jemand eine Idee?
Bearbeiten: Ich habe ipmo SmbShaream Anfang hinzugefügt Invoke-Unlock, um sicherzustellen, dass das Modul auch in VisualStudio geladen wurde, aber dann erhalte ich diese Fehlermeldung:
ipmo : The specified module 'SmbShare' was not loaded because no valid module file was found in any module directory.
Dies lässt mich denken, dass VisualStudio keine Standardverzeichnisse für das PowerShell-Modul verwendet.
1 Antwort auf die Frage
1
harrymc
In solchen Fällen ist das übliche Problem, dass Visual Studio 2017 eine 32-Bit-Version hat. In diesem Fall wird standardmäßig die 32-Bit-Version von PowerShell aufgerufen. Wenn Sie PowerShell unter 64-Bit-Windows manuell starten, verwenden Sie die 64-Bit-Version von PowerShell.
Dadurch wird PowerShell von innen anders ausgeführt als von Visual Studio.
Die Lösung besteht darin, speziell die 64-Bit-Version aus Visual Studio mit dieser Syntax zu aktivieren:
Weitere Informationen zum Zugriff auf 64-Bit-Tools von 32-Bit-Code finden Sie unter [Der 'Sysnative'-Ordner in 64-Bit-Windows erklärt] (http://www.samlogic.net/articles/sysnative-folder-64-bit-windows.htm) . Dies ist ein virtueller Ordner, der zum Durchlaufen einer Datei verwendet werden kann, sein "Inhalt" kann jedoch nicht aufgelistet werden.
harrymc vor 6 Jahren
0
Nun ... Ich habe keine 32-Bit-Software, um dies zu testen, aber in cmd.exe, Windows-Startmenü, cmd für visualstudio `% WINDIR% \ SysNative \ WindowsPowerShell \ v1.0 \ PowerShell.exe" gci; pause "` schlägt fehl, während% WINDIR% \ System32 \ WindowsPowerShell \ v1.0 \ PowerShell.exe "gci; pause" `funktioniert. aber ich lasse die Entwickler das testen und komme zu Ihnen zurück
SimonS vor 6 Jahren
0
Der Entwickler hat mir gerade gesagt, dass der `SysNative`-Pfad funktioniert. Vielen Dank, Harry, das war sehr hilfreich
SimonS vor 6 Jahren
0