Selbsterstelltes VBScript führt zu Fehlermeldung: Diese App kann auf dem PC nicht ausgeführt werden
Hallo Mädels und Jungs,
habe ein kleines VBScript geschrieben, welches den Namen einer ausführbaren Datei (*.exe) um die Dateiversion ergänzen soll, wenn eine vorhanden ist.
Also aus "EssentialPIMPro.exe" soll "EssentialPIMPro.9.10.6.exe" werden.
Mit Wscript.Arguments kann eine Datei übergeben und somit ein Kontextmenüeintrag im Explorer eingerichtet werden.
Zu Testzwecken ist eine Variable mit einem existierenden Dateinamen eingebaut, wenn kein Argument übergeben wird.
Hier "F:\vs_community.exe".
Die VBS-Datei ist in"C:\Scripts" gespeichert.
Nun folgendes Phänomen: Klicke ich die VBS-Datei zum Ausführen an, wird mir brav der neue Dateiname "F:\vs_community.16.9.31105.61.exe" angezeigt.
Führe ich das Script jedoch aus dem Explorer-Kontextmenü aus, poppt eine Warnmeldung auf:
"Diese App kann auf dem PC nicht ausgeführt werden. Wenden Sie sich an den Softwareherausgeber, um eine geeignete Version für Ihren PC zu finden"
Für hilfreiche Tipps wäre ich sehr dankbar.
Gruß
Peter
habe ein kleines VBScript geschrieben, welches den Namen einer ausführbaren Datei (*.exe) um die Dateiversion ergänzen soll, wenn eine vorhanden ist.
Also aus "EssentialPIMPro.exe" soll "EssentialPIMPro.9.10.6.exe" werden.
Mit Wscript.Arguments kann eine Datei übergeben und somit ein Kontextmenüeintrag im Explorer eingerichtet werden.
Zu Testzwecken ist eine Variable mit einem existierenden Dateinamen eingebaut, wenn kein Argument übergeben wird.
Hier "F:\vs_community.exe".
Die VBS-Datei ist in"C:\Scripts" gespeichert.
Nun folgendes Phänomen: Klicke ich die VBS-Datei zum Ausführen an, wird mir brav der neue Dateiname "F:\vs_community.16.9.31105.61.exe" angezeigt.
Führe ich das Script jedoch aus dem Explorer-Kontextmenü aus, poppt eine Warnmeldung auf:
"Diese App kann auf dem PC nicht ausgeführt werden. Wenden Sie sich an den Softwareherausgeber, um eine geeignete Version für Ihren PC zu finden"
Für hilfreiche Tipps wäre ich sehr dankbar.
Gruß
Peter
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1305748975
Url: https://administrator.de/forum/selbsterstelltes-vbscript-fuehrt-zu-fehlermeldung-diese-app-kann-auf-dem-pc-nicht-ausgefuehrt-werden-1305748975.html
Ausgedruckt am: 21.12.2024 um 14:12 Uhr
9 Kommentare
Neuester Kommentar
Das Script sieht auf den ersten Blick gut aus.
Ich nehme an, dass der Aufruf aus dem Kontextmenü falsch abläuft.
Hast Du mal geprüft, was das Script als Argument bekommt und wie es das weiterverarbeitet?
Du hast keine Fehlerbehandlung drin. Es kann also sein, dass im Script dann etwas schief läuft.
Gruß
Andreas
Ich nehme an, dass der Aufruf aus dem Kontextmenü falsch abläuft.
Hast Du mal geprüft, was das Script als Argument bekommt und wie es das weiterverarbeitet?
Du hast keine Fehlerbehandlung drin. Es kann also sein, dass im Script dann etwas schief läuft.
Gruß
Andreas
Servus Peter.
Zu aller erst, die Dateiversion bekommt man zuverlässiger und ohne langwierige Schleife anhand der CLSID der Windows-Property und der Methode ExtendedProperty über Windows OS hinweg sprachunabhängig. Das kennt aber leider kaum einer.
Dann zu der Meldung die du erhältst: Die Meldung kommt wenn du in den Kontextmenüeintrag den VBS Pfad direkt einträgst, damit kann Windows hier nichts anfangen, du musst das VBS Skript dort stattdessen explizit mit dem regulären Interpreter wscript.exe oder cscript.exe starten und den Pfad des Skripts übergeben:
Und als Hinweis wie man das Auslesen der Property effektiver und auch Sprachunabhänig macht (Zeile 16)
Brauchst du stattdessen die ProductVersion statt die FileVersion (die können sich ja je nach Produkt unterscheiden) machst du das am Ende von Zeile 16 meines Skriptes einfach so
Das Äquivalent für die CLSID für "FileVersion" im Klartext ist
Ich habe in meinem Beispiel die CLSID und die propID verwendet weil das etwas effektiver ist als mit den Namen zu arbeiten.
Grüße Uwe
Zu aller erst, die Dateiversion bekommt man zuverlässiger und ohne langwierige Schleife anhand der CLSID der Windows-Property und der Methode ExtendedProperty über Windows OS hinweg sprachunabhängig. Das kennt aber leider kaum einer.
Dann zu der Meldung die du erhältst: Die Meldung kommt wenn du in den Kontextmenüeintrag den VBS Pfad direkt einträgst, damit kann Windows hier nichts anfangen, du musst das VBS Skript dort stattdessen explizit mit dem regulären Interpreter wscript.exe oder cscript.exe starten und den Pfad des Skripts übergeben:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\*\shell\RenameWithVersion\command]
@="wscript \"C:\\PfadZumScript\\rename_with_version.vbs\" \"%1\""
Dim arg, folder, fso, objShell, bname, ext, destination, fileversion
Set fso = CreateObject("Scripting.FileSystemObject")
Set objShell = CreateObject("Shell.Application")
If WScript.Arguments.Count > 0 Then
arg = WScript.Arguments(0)
Else
MsgBox "Keine Datei übergeben!",vbExclamation
WScript.Quit 1
End If
If fso.FileExists(arg) Then
folder = fso.GetParentFolderName(arg)
bname = fso.GetBaseName(arg)
ext = fso.GetExtensionName(arg)
fileversion = objShell.NameSpace(folder).ParseName(fso.GetFileName(arg)).ExtendedProperty("{0CEF7D53-FA64-11D1-A203-0000F81FEDEE} 4")
If fileversion <> "" Then
destination = folder & "\" & bname & "." & fileversion & "." & ext
fso.MoveFile arg, destination
Else
MsgBox "Version ist leer!",vbExclamation
End If
Else
MsgBox "Datei '" & arg & "' existiert nicht.", vbExclamation
WScript.Quit 1
End If
Brauchst du stattdessen die ProductVersion statt die FileVersion (die können sich ja je nach Produkt unterscheiden) machst du das am Ende von Zeile 16 meines Skriptes einfach so
.ExtendedProperty("System.Software.ProductVersion")
.ExtendedProperty("System.FileVersion")
Ich habe in meinem Beispiel die CLSID und die propID verwendet weil das etwas effektiver ist als mit den Namen zu arbeiten.
Grüße Uwe
Kannst du machen ist aber überflüssig. VBS zeigt via wscript per default keine Interpreter-Banner.
Und auch das aufblitzende Powershell-Fenster das du zwar mit
p.s. das doppelt und dreifachen Aufruf get-item solltest du besser über eine Variable ablösen das kostet nur unnötige Ressourcen wenn das System die Properties immer erst erneut abfragen muss.
Das ganze lässt sich dann auch auf folgendes Powershell-Script reduzieren:
Zu Testzwecken habe ich versucht, das gleiche Problem mit Powershell anzugehen.
Hätte das Vorteile?
Was hältst Du davon?
Sicher kannst du auch zur Powershell greifen, das ist dann jedem selbst überlassen, du musst halt die Executionpolicy beachten des jeweiligen Systems beachten z.B. über Hätte das Vorteile?
Was hältst Du davon?
-EP Bypass
im Kontextmenüeintrag.Und auch das aufblitzende Powershell-Fenster das du zwar mit
-WindowStyle hidden
etwas aber nicht ganz abstellen kannst. Für vollständige Unsichbarkeit ist dann wieder der Aufruf über ein wrapper vbs mit wscript.shell nötig.p.s. das doppelt und dreifachen Aufruf get-item solltest du besser über eine Variable ablösen das kostet nur unnötige Ressourcen wenn das System die Properties immer erst erneut abfragen muss.
Das ganze lässt sich dann auch auf folgendes Powershell-Script reduzieren:
param(
[parameter(mandatory=$true)][ValidateScript({Test-Path $_})][string]$file
)
Get-Item -LiteralPath $file | rename-item -NewName {"$($_.BaseName).$($_.VersionInfo.FileVersion)$($_.Extension)"} -verbose