Version imprimable
Bonjour et si ce n'est pas trop tard bonnes fêtes à tous.
À l'aide de Shell, je voudrais savoir si il possible de lancer l'exécution d'un programme (.exe) si celui-ci est situé sur un autre serveur/machine distante.
exemple :
Où dans cet exemple on pourrait avoir sFullPathEXE="\\Server1\Chemin\MyExec.exe".Code:
2
3cmdLine = sFullPathEXE & sFullPathInput & sFullPathOutput & sParameters res = Shell(cmdLine, vbMinimizedNoFocus)
Merci pour vos réponses.
Bonjour:
que donne le résultat du test?
Bonjour,
Je n'ai pas de réseau sur place pour le tester.
cependant, mon client me dit que cela ne fonctionne pas.
Bonjour,
ton exe fait il objet d'une installaton (setup) ou d'un framork (.net).
Utilise t elle des dll,des ocx ou le VBRun de vb6. Tous ces cas de figures obligent une installation sur la machine!
Salut,
peux-tu t'assurer que chaque élément de ta ligne de commande est bien séparé des autres par une espace =)
Bonjour.
Je remercie tous ceux qui s'intéressent à ma question.
@rdurupt :
Non, l'utilitaire ne nécessite pas d'intallation machine. Il s'agit du shareware "Pdftools.exe" en ligne de commande.
@jpcheck :
Je suppose qu'en locale la syntaxe est parfaitement réalisée puisque pour le moment mon appli a parfaitement fonctionné en local.
Concernant l'utilisation avec des serveurs; je ne peux pas être certain que les chemins aient été parfaitement paramétrés par mon client.
Je pense que le réseau est constitué de pc +/- récents certains fonctionnant peut-être encore sous XP.
Les véritables questions sont :
- Est-ce que la commande Shell est capable de lancer un exécutable situé sur un autre ordinateur d'un réseau ?
- Est-ce que "Pdftools" est capable de prendre des fichiers d'entrée et de sortie situés sur d'autres ordinateurs d'un réseau ?
Cordialement.
OK,
les sources de problèmes sont généralement au niveau du ou des dossiers passés :
- les espaces
- les accents
Vérifie qu'aucun de ces caractères n'est utilisé.
Le mieux restant bien sûr de te déplacer toi-même pour constater la chaîne de caractères de ta ligne de commande, quitte à utiliser un soft genre teamviewer ^^
attention au espace dans une commende DOS si c'est le cas encadre la commende avec ["] chr(34)Code:cmdLine = sFullPathEXE & sFullPathInput & sFullPathOutput & " " & chr(34) & sParameters & chr(34)
de plus le gratuit ne dit pas pas d'install!
Refais ke test en tappant la commande dans une fenêtre DOS!
Némarer executé cmd
@rdurupt :
Cela a été fait !
(Mes espaces et mes """ sont contenus dans les variables textes et le tout fonctionne bien depuis des mois, MAIS en local.)
j’imagine mais on n'est sur un réseau, il faut vérifier si la syntaxe local s’applique au réseau; si le chemin de l'application est valide voir si les droits sont accordé; si il y a des espaces; vérifier que tu peux accéder au répertoire avec l'explorateur WINDOWS;Citation:
Envoyé par JOHN14
si tu n'exécute pas dans une fenêtre DOS, avec la bonne syntaxe la commande shell ne fonctionnera pas car elle fait la même chose elle ouvre un DOS!
Actuellement, je ne peux pas le vérifier à nouveau.
Mais il y plusieurs mois j'ai fait faire à mon client des tests avec CMD.
Il semble que cela ne fonctionne pas.
Il semble que d'autres commande DOS ne fonctionnent pas non plus sur les réseaux. Je pense à "XCOPY" par exemple.
L'idée qu'il y a derrière pour contourner ce problème serait peut-être de lancer le CMD local avec quelque chose du genre :
Est-ce que "Shell" est capable de lancer un exécutable situé sur un autre ordinateur d'un réseau ?Code:Shell "\\Server1\[...]\cmd.exe/c" &" " &"\\Server1\Chemin\MyExec.exe MyParameters"
la commande shell fonctionne quelque soit la version.
ceci dit il es possible, en fonction du Windows que la commande que tu exécute se face en 32 ou 64 bite Exemple pour VBCRIPT (Cscript.exe):
Code:C:\WINDOWS\SysWOW64\Cscript.exe %1