[gelöst] Shell vs. WSH

[rainergaiss]

Ich bin gerade dabei, eine alte 2.60-Version auf 2009 R2 SQL upzugraden. Die alte Version hatte mehrere Shell-Aufrufe um eine erzeugte Datei zu zippen um sie zu archivieren.

Nun hat sich der Shell-Aufruf im Laufe der Zeit immer mal wieder geändert, und in absehbarer Zeit wird es ihn gar nicht mehr geben, so dass ich bei der Gelegenheit auf WSH umstellen möchte. Lösungen gibt es ja hier und in mibuso einige. Weiß jemand, ob es Kompatibilitätsprobleme zwischen den einzelnen Client-Betriebssystemen geben wird oder kann? Im Augenblick läuft die Testversion auf einem 2008-Server, das Echtsystem wird aber unter XP, teilweise mit Terminalserver laufen. Ein sofortiger Update auf ein neues OS ist nicht sinnvoll, da die alten und neuen Clients zunächst einmal auf denselben Rechnern installiert werden und das alte NAV (technisch 3.70) nicht mit Win 7 läuft.

Zuletzt geändert von rainergaiss am 13. Juli 2012 10:19, insgesamt 1-mal geändert.

Der WSH sollte sich überall gleich verhalten.
Allerdings bin ich nicht sicher ob er die richtige Wahl ist für 2009.
Ich gehe mal davon aus, dass durch das upgrade einer alten Version bedingt, nur der CC verwendet wird.
Wenn aber später einmal Pages hinzukommen oder ein weiteres Update auf 2013 angedacht wird, muss hier eine "modernere" Variante her.
Meine Gedanken gehen in diesem Fall in Richtung .NET-Komponenten.

Mir sind keine Inkompatibilitäten zwischen den einzelnen Betriebssystemen bekannt. Wir haben auch verschiedene Betriebssysteme im Einsatz (XP, 7, 2003, 2008R2).

Man sollte unbedint beachten in welchen Datei-Verzeichnissen man speichern und arbeiten will. Beispielsweise mag Win7 es nicht wenn Programme Dateien in das Programmverzeichnis schreiben wollen, selbst wenn es nur temporär ist. Ggf sollte man auch daran denken, dass die Standard-Verzeichnisse ("Programme", "Benutzer", ....) je nach Win-Version (XP, Win 7 32-bit, Win 7 64-bit, ...) unterschiedlich heißen.

Volker

Man sollte unbedint beachten in welchen Datei-Verzeichnissen man speichern und arbeiten will. Beispielsweise mag Win7 es nicht wenn Programme Dateien in das Programmverzeichnis schreiben wollen, selbst wenn es nur temporär ist. Ggf sollte man auch daran denken, dass die Standard-Verzeichnisse ("Programme", "Benutzer", ....) je nach Win-Version (XP, Win 7 32-bit, Win 7 64-bit, ...) unterschiedlich heißen.

Volker

Im Allgemeinen sollte man mit den Systemvariablen arbeiten wenn man vorhat Dateien auf Platte temporär abzulegen.

Im Allgemeinen sollte man mit den Systemvariablen arbeiten wenn man vorhat Dateien auf Platte temporär abzulegen.

Da stimm ich voll zu, aber bei XP/2003 war das noch nicht so dramatisch und wenn ich Zip lese, dann gibt es da in der Regel zwangsläufig irgendwo temporäre Dateien.

Volker

Alles könnte gut sein ...

Das WSHExec funktioniert, nur leider nicht das Kommando, das ich absetzen will. Ich will ja die von NAV erzeugte Datei zippen und rufe dafür die PKZIP.EXE auf. Das Problem ist, dass es dieses Programm nicht mehr in 64 Bit gibt. Ich brauche also eine Lösung, die in 32 und 64 Bit funktioniert, entweder als Kommandozeilentool oder als Automation Server. Hat jemand Ideen?

Eigentlich dachte ich erst es über ein kleines Programm und Automation zu lösen, aber http://dotnetzip.codeplex.com/ bietet auch Möglichkeiten für Scripting. Sollte funktionieren. Einfach mal das komplette Paket runterladen und in den Beispielen nachsehen, was in disem Fall am besten passt.

Volker

Also als zipper würde ich dir 7-Zip empfehlen, den gibt es für 32 und 64-bit, als Kommandozeile, kost nix und komprimiert im 7z- Modus ultra gut.

Gruß, Fiddi

Also als zipper würde ich dir 7-Zip empfehlen ...

Würde ich auch

Danke! Das war die Lösung. 7-zip kannte ich ja schon länger aber noch nicht als Kommandozeilentool. Klappt auch hervorragend mit wSH.