Vérifier si un fichier exécutable existe dans le path de Windows
Si je lance un processus avec ShellExecute
(ou dans .net avec System.Diagnostics.Process.Start()
) le nom de fichier du processus de démarrage n'a pas besoin d'être un chemin d'accès complet.
Si je veux démarrer le bloc-notes, je peux utiliser
Process.Start("notepad.exe");
au lieu de
Process.Start(@"c:\windows\system32\notepad.exe");
car le répertoire c:\windows\system32
fait partie de la variable d'environnement PATH.
comment puis-je vérifier si un fichier existe sur le CHEMIN sans l'exécution du processus et sans l'analyse de la variable de CHEMIN d'accès?
System.IO.File.Exists("notepad.exe"); //returns false
(new System.IO.FileInfo("notepad.exe")).Exists; //returns false
mais j'ai besoin de quelque chose comme ceci:
System.IO.File.ExistsOnPath("notepad.exe"); //should return true
et
System.IO.File.GetFullPath("notepad.exe"); //(like unix which cmd) should return
//c:\windows\system32\notepad.exe
Est-il un prédéfini classe pour faire cette tâche à la disposition de la BCL?
- Si une classe prédéfinie serait pratique (ou est pratique, si elle existe) n'est-il pas plus qu'une ligne pour obtenir le chemin d'accès, puis vérifier exists()? Vous auriez pu écrire plus rapidement que de poser la question. Raison spéciale/besoin? Vous vous demandez juste.
- Yepp, devrait être très facile. Mais ma conviction est que, si une tâche peut être fait avec la bibliothèque existante de probramming langue, je préfère cette façon au cours de réinventer le weel encore et encore. Si il n'y a pas qch disponible, je le fais de mon propre chef.
Vous devez vous connecter pour publier un commentaire.
Je pense qu'il n'y a rien construit, mais vous pourriez faire quelque chose comme cela avec Système.IO.Fichier.Existe:
GetFullPath
comme méthode d'extension pourstring
? Ça serait bizarre pour moi... peut-être pourrait avoir du sens pourFileInfo
...Path.PathSeparator
au lieu de coder en dur le point virgule.C'est risqué, il ya beaucoup plus à lui que juste à rechercher les répertoires dans le CHEMIN d'accès. Essayez ceci:
L'exécutable est stocké dans c:\Program Files\Windows NT\Accessoires sur ma machine, ce répertoire est pas sur le chemin.
La HKCR\Applications et des HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths clés jouent également un rôle dans la recherche des fichiers exécutables. Je suis assez sûr il y a d'autres mines terrestres de ce genre partout, répertoire de la virtualisation dans les versions 64 bits de Windows pourraient vous passionner par exemple.
De le rendre plus fiable, je pense que vous devez pinvoke AssocQueryString(). Pas sûr, n'a jamais eu le besoin. La meilleure approche est certainement de ne pas avoir à se poser la question.
Ok, un meilleur moyen je pense...
Il utilise le où commande, qui est disponible au moins sur Windows 7/Server 2003:
Accepté de répondre à des états qu'il n'y a rien à construire, mais ce n'est pas vrai.
Il y a une norme WinAPI PathFindOnPath pour ce faire, il est disponible depuis Windows 2000.
J'ai essayé Dunc du "où" et ça fonctionne, mais c'est lent et les ressources lourd et il y a la légère danger d'avoir un processus orphelin.
J'aime Eugène de Mala conseil sur PathFindOnPath, donc j'ai étoffé que comme une réponse complète. C'est ce que je suis à l'aide de nos outils maison.
Je suis au bout de la même chose et je pense que la meilleure option que j'ai en ce moment est l'utilisation de appel des indigènes de la fonction CreateProcess pour créer un processus de suspension et de regarder pour la réussite; la terminaison du processus par la suite. La terminaison d'un processus interrompu ne doit subir aucune ressource saignement [citation nécessaire :)]
Je risque de ne pas être en mesure de trouver le chemin qui en fait pris l'habitude, mais pour une simple exigence que ExistsOnPath() il convient de faire - jusqu'à il y a une meilleure solution.