Comment trouver le chemin de l'application dans une application console ?
En Formulaires Windows je peux utiliser Application.StartupPath
pour trouver le chemin actuel, mais cela ne semble pas être disponible dans une application console.
Comment trouver le chemin de l'application dans une application console ?
En Formulaires Windows je peux utiliser Application.StartupPath
pour trouver le chemin actuel, mais cela ne semble pas être disponible dans une application console.
System.Reflection.Assembly.GetExecutingAssembly()
. Location
1
Combinez cela avec System.IO.Path.GetDirectoryName
si tout ce que vous voulez est le répertoire.
1 Conformément au commentaire de M. Mindor :
System.Reflection.Assembly.GetExecutingAssembly().Location
renvoie l'emplacement actuel de l'assemblage en cours d'exécution, qui peut être ou non l'emplacement de l'assemblage lorsqu'il n'est pas en cours d'exécution. Dans le cas de la copie cachée d'assemblages, vous obtiendrez un chemin dans un répertoire temporaire.System.Reflection.Assembly.GetExecutingAssembly().CodeBase
renvoie le chemin "permanent" de l'assemblage.
Pour info, lorsque j'exécute cette opération à partir d'une application Web IIS, j'obtiens ce résultat... C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary Fichiers ASP.NET \root\a897dd66\ec73ff95\assembly\dl3\ff65202d\e9a4e8db_ 5d84cc01
System.Reflection.Assembly.GetExecutingAssembly().Location renvoie l'emplacement de l'assemblage en cours d'exécution. actuellement qui peut être ou non l'endroit où se trouve l'assemblage lorsqu'il n'est pas en cours d'exécution. Dans le cas de la copie cachée d'assemblages, vous obtiendrez un chemin d'accès dans un répertoire temporaire. System.Reflection.Assembly.GetExecutingAssembly().CodeBase renvoie le chemin ' permanent ' de l'assemblage.
Personnellement, je pourrais penser que la réflexion est inutile pour ce genre de choses alors que nous avons Environment.GetCommandLineArgs. Mais peut-être ai-je tort et devrais-je aller faire les tests.
Vous avez deux options pour trouver le répertoire de l'application, celle que vous choisirez dépendra de votre objectif.
// to get the location the assembly is executing from
//(not necessarily where the it normally resides on disk)
// in the case of the using shadow copies, for instance in NUnit tests,
// this will be in a temp directory.
string path = System.Reflection.Assembly.GetExecutingAssembly().Location;
//To get the location the assembly normally resides on disk or the install directory
string path = System.Reflection.Assembly.GetExecutingAssembly().CodeBase;
//once you have the path you get the directory with:
var directory = System.IO.Path.GetDirectoryName(path);
Je voulais juste dire qu'il est évident qu'il y a beaucoup plus que 2 options vu le nombre d'autres choix affichés...
Si ce que vous essayez de faire avec ce chemin ne supporte pas le format URI, utilisez var localDirectory = new Uri(directory).LocalPath;
C'est tout simplement faux. Et si l'exécutable n'était pas du tout un assemblage .NET ? La bonne réponse est de vérifier l'environnement et d'inspecter la ligne de commande.
C'est probablement un peu tard mais cela vaut la peine d'être mentionné :
Environment.GetCommandLineArgs()[0];
Ou plus correctement pour obtenir juste le chemin du répertoire :
System.IO.Path.GetDirectoryName(Environment.GetCommandLineArgs()[0]);
Edit :
De nombreuses personnes ont fait remarquer que GetCommandLineArgs
n'est pas garanti de retourner le nom du programme. Voir Par convention, le premier mot de la ligne de commande est le nom du programme. . L'article précise que "Bien que très peu de programmes Windows utilisent cette bizarrerie (je n'en connais aucun moi-même)". Il est donc possible d'usurper GetCommandLineArgs
mais nous parlons ici d'une application console. Les applications en console sont généralement rapides et sales. Cela correspond donc à ma philosophie KISS.
Modifier Il semble, d'après les commentaires, que la plupart des autres solutions ne fonctionnent pas lorsque vous utilisez un système de test unitaire. C'est logique puisque l'élément exécutable n'est pas votre application mais le système de test. Je ne l'ai pas vérifié - je peux donc me tromper complètement. Si c'est le cas, je supprimerai cette modification.
Et peut être ceci : path = Environment.GetCommandLineArgs()[0].Substring(0, iniFilePath.LastIndexOf(" \\ ") + 1) ;
@fabspro - J'ai modifié le message pour montrer l'étape supplémentaire consistant à supprimer le nom de l'application et à ne laisser que le chemin du répertoire.
Ce n'est pas un bon conseil. args[0] n'est pas garanti comme étant le chemin de l'exe. Il pourrait simplement s'agir du nom de l'exe, ou de tout autre élément choisi par le créateur du processus. N'utilisez pas ceci !
Pour toute personne intéressée par les applications web asp.net. Voici mes résultats de 3 méthodes différentes
protected void Application_Start(object sender, EventArgs e)
{
string p1 = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);
string p2 = System.Web.Hosting.HostingEnvironment.ApplicationPhysicalPath;
string p3 = this.Server.MapPath("");
Console.WriteLine("p1 = " + p1);
Console.WriteLine("p2 = " + p2);
Console.WriteLine("p3 = " + p3);
}
résultat
p1 = C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\a897dd66\ec73ff95\assembly\dl3\ff65202d\29daade3_5e84cc01
p2 = C:\inetpub\SBSPortal_staging\
p3 = C:\inetpub\SBSPortal_staging
l'application est physiquement exécutée à partir de " C:\inetpub\SBSPortal_staging "La première solution n'est donc pas adaptée aux applications web.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
7 votes
Avez-vous installé .NET Framework sur la machine cible (Client, Développement) ? Si votre réponse est vraie ; Alors, vous pouvez ajouter une référence à System.Windows.Forms.dll et utiliser Application.StartupPath ! C'est le meilleur moyen si vous voulez éviter les exceptions futures !
0 votes
AppDomain.BaseDirectory est le répertoire de l'application. Soyez conscient que l'application peut se comporter différemment dans l'environnement VS et l'environnement Win. Mais AppDomain devrait être le même que application.path mais j'espère que ce n'est pas seulement pour IIS.