Comment puis-je obtenir le chemin d'accès de l'assemblée le code est-il?

Est-il un moyen d'obtenir le chemin d'accès pour l'assemblée, dans laquelle le code actuel réside? Je ne veux pas le chemin de la convocation de l'assemblée, juste l'un contenant le code.

Fondamentalement, mon test unitaire doit lire du xml fichiers de test qui sont situés par rapport à la dll. Je veux que le chemin d'accès à toujours résoudre correctement, peu importe si le test dll est exécuté à partir d'TestDriven.NET le MbUnit GUI ou quelque chose d'autre.

Modifier: les Gens semblent être de l'incompréhension de ce que je vous demande.

Ma bibliothèque de test est situé à dire

C:\projects\myapplication\daotests\bin\Debug\daotests.dll

et je voudrais le mettre sur ce chemin:

C:\projects\myapplication\daotests\bin\Debug\

Les trois suggestions jusqu'à présent à me manquer quand je le lance à partir de la MbUnit Gui:

Environment.CurrentDirectory
donne c:\Program Files\MbUnit
System.Reflection.Assembly.GetAssembly(typeof(DaoTests)).Location
donne C:\Documents et
Settings\george\Local
Settings\Temp\ ....\DaoTests.dll
System.Reflection.Assembly.GetExecutingAssembly().Location
donne le même que le précédent.

C'est votre solution: var dir = domaine d'application.CurrentDomain.BaseDirectory;
Cela devrait être la solution retenue. Domaine d'application.CurrentDomain.BaseDirectory est la bonne approche.
Voir: finding-my-main-executables-path-using-assembly-vs-appdomain
Je suis venu ici à la recherche d'une solution pour un package nuget pour lire un fichier JSON à partir de son paquet de répertoire. Il semble que quand un package nuget est exécutée, le "domaine d'application.CurrentDomain.BaseDirectory" les points à l'exécution de projets de répertoire, et non pas le package nuget répertoire. Aucune de ces semblent cibler le package nuget répertoire correctement.
non, ce ne serait pas parce que ce n'est pas ce que cette question était d'environ (en fait, quand il a été demandé, nuget n'existait pas) - n'hésitez pas à commencer une nouvelle question et une table de ping-moi là, mais je peux vous dire dès maintenant que son impossible dans la plupart des cas. Pour la plupart des projets de la nuget répertoire est packages à côté de la sln fichier. MAIS quand vous rassembler et de diffuser des choses il n'existe pas de fichier sln et pas de répertoire packages. Lors de la compilation, les choses qui sont nécessaires (mais pas tout) est copié dans le répertoire bin. Votre meilleur pari est d'utiliser un postbuild script pour copier le fichier que vous voulez.
Pour ceux qui lisent ces commentaires croire AppDomain.CurrentDomain.BaseDirectory est la bonne solution, reportez-vous à ce commentaire qui propose une meilleure solution.

InformationsquelleAutor George Mauer | 2008-09-09

.net c#reflection

1003

J'ai défini la propriété suivante que nous utilisons souvent dans des tests unitaires.
```
public static string AssemblyDirectory
{
    get
    {
        string codeBase = Assembly.GetExecutingAssembly().CodeBase;
        UriBuilder uri = new UriBuilder(codeBase);
        string path = Uri.UnescapeDataString(uri.Path);
        return Path.GetDirectoryName(path);
    }
}
```
La Assembly.Location bien, parfois, vous donne de drôles de résultats lors de l'utilisation de NUnit (où assemblées exécuter à partir d'un dossier temporaire), donc je préfère utiliser CodeBase qui vous donne le chemin d'accès en format URI, puis UriBuild.UnescapeDataString supprime la File:// au début, et GetDirectoryName changements à la normale de windows, format.
- Ce du a un problème je suis venu à travers, si votre nom de répertoire est: c:\My%20Directory ensuite, l'Uri.UnescapeDataString sera de retour: c:\My Répertoire de Ce Fichier.Existe("c:\My Directory\MyFile.txt") retournera false que le bon chemin est en fait "c:\My%20Directory\MyFile.txt" je suis tombé sur ce que notre SVN chemins se sont séparés par des espaces, et quand nous les vérifier il encode les espaces.
- merde, ça ne marche pas encore pour moi :0( Maintenant, au lieu de me donner la MSBuild chemin, je reçois le chemin de TeamCity C:\TeamCity\buildAgent\temp\buildTmp\SYSTEM_SVR1 2010-08-24 17_34_23\, mais encore une autre façon d'obtenir un chemin d'accès 🙂
- Sibly: retourne le chemin d'accès de l'assembly en cours d'exécution - pas de l'assemblée (comme dans une .dll) qui est chargé par l'appel de l'exécutable. J'ai besoin de l' .dll pour être en mesure de définir un répertoire de travail. +1 mais pour une réponse utile et un bon point de départ.
- Soyez prudent lorsque vous utilisez ce pour sélectionner le Fichier.Existent() cette méthode renvoie false sur le chemin d'accès UNC. Utiliser @Keith répondre à la place.
- Ne sais pas qui pourrait mettre statique avant le public. Bon à savoir et je pense que je préfère pour des raisons de lisibilité
- Pour les personnes qui ont besoin de savoir, l'Assemblage est dans le Système.La réflexion, et le Chemin est dans le Système.IO. 🙂
- Remarque: cela ne fonctionne pas avec des emplacements réseau (par exemple, \\REMOT_EPC\Dossier)
- Notez que la deuxième ligne sera le déclencheur d'CA2234. Passer à new Uri(le code) à l'UriBuilder constructeur de fixer l'avertissement.
- La version de Visual Studio utilisez-vous qui déclenche l'erreur? Juste essayé de VS2012 et il semble OK
- En 2012, bien qu'via msbuild sur la ligne de commande. Si vous regardez les règles qui sont activées, est 2234-elle vérifiée? Je ne sais pas si c'est l'un de ceux par défaut pour le Minimum Recommandé.
- Aussi cela ne fonctionnera pas si le répertoire a des signes dièse '#' en elle. Nombre de signes sont autorisés dans le répertoire et les noms de fichiers dans Windows.
- CodeBase est un gâchis. Voici mon point de vue sur ça: stackoverflow.com/a/28319367/321013
- Je me suis appuyé sur cette méthode depuis des années, mais il n'a pas à moi aujourd'hui lorsque le chemin d'accès au répertoire en question contenait un '#'.
- Cela fonctionne de la même et semble plus courte: string chemin = new Uri(Assemblée.GetExecutingAssembly().La base de code).LocalPath; Chemin de retour.GetDirectoryName(chemin);
- Ne fonctionne pas lorsque l'assemblée est un service windows.
- Ce n'est pas testable... Tous vos tests unitaires qui permettra de tester ce code va échouer! voir @Jalal répondre
- Nous avons utilisé la base de Code pour une longue période, et ont maintenant mis à niveau .Net45. Le comportement de la base de Code a changé si ce n'est plus renvoie le répertoire. Ne pas utiliser .La base de code si vous utilisez des versions plus récentes de DotNet! Nous sommes maintenant en utilisant AppDomain.CurrentDomain.BaseDirectory qui fonctionne correctement pour n'importe quelle version de DotNet
InformationsquelleAutor John Sibly
313

Cela vous aide?
```
//get the full location of the assembly with DaoTests in it
string fullPath = System.Reflection.Assembly.GetAssembly(typeof(DaoTests)).Location;

//get the folder that's in
string theDirectory = Path.GetDirectoryName( fullPath );
```
- voir mon edit, il ne le fait pas, est-ce quelque chose d'étrange à propos de la façon dont MbUnit fait des choses?
- Comment venir? fullPath serait "C:\projects\myapplication\daotests\bin\Debug\daotests.dll" le répertoire serait "C:\projects\myapplication\daotests\bin\Debug" N'est-ce pas ce que vous voulez?
- Ah, non, je vous. MSTest fait la même chose - tout ce qui est copié dans un nouveau répertoire temp de tous les temps.
- Définir les fichiers xml pour être contenu, copié avec la dll, ou des ressources, lire à partir de la dll.
- Ou tout simplement typeof(DaoTests).Assembly
- Je serais personnellement d'aller avec une méthode comme ceci: public static string GetAssemblyDirectory<T>(){return System.IO.Path.GetDirectoryName(typeof(T).Assembly.Location);}
- pourquoi utiliser un générique lorsque le type de retour est toujours string et l'entrée toujours Type? Vous pourriez faire: public static string GetAssemblyDirectory(this Type input){return System.IO.Path.GetDirectoryName(input.Assembly.Location);} de cette façon, vous n'avez pas besoin de connaître le type explicitement: unknown.GetType().GetAssemblyDirectory();
- Je suis tout simplement en remplacement de l'entrée paramater avec un paramètre de type donc je ne vais pas à appeler typeof, comme vous le faites dans votre exemple. Comme pour ne pas avoir besoin de taper explicitement je n'ai pas eu besoin de ça pour l'instant, c'est pourquoi je n'ai pas de surcharge qui prend un Système.Type d'entrée (encore).
- Hé les gars, utilisez Assembly.GetExecutingAssembly(). "obtient l'assembly qui contient le code qui est actuellement en cours d'exécution" (à partir de la description de la méthode). - Je l'utiliser dans mon AddIn "EntitiesToDTOs". Voir AssemblyHelper.cs pour l'exemple réel.
- Eu un problème avec le post de @John Silby, comme il n'a pas l'air comme il travaille pour les chemins d'accès UNC... par exemple \\Serveur\Dossier\Fichier.ext. Celui-ci fait le tour. +1
- regardez de nouveau la question, ce n'est pas ce qui est voulu ici, et il est déjà mentionné comme une non-solution de travail.
- Yep, j'ai examiné la question et vous avez raison, me semble que je n'avais pas remarqué que quand j'ai vu la question la première fois. Mon mal, merci!
InformationsquelleAutor Keith
306

C'est aussi simple que cela:
```
var dir = AppDomain.CurrentDomain.BaseDirectory;
```
- Cela devrait être la solution retenue. Domaine d'application.CurrentDomain.BaseDirectory est la bonne approche.
- merci d'avoir mon attention sur ce - pas sûr si c'était disponible au moment où j'ai posé la question, mais il est maintenant.
- Non, c'est faux. Renvoie le chemin d'accès du POINT d'ENTRÉE d'ORIGINE de ne pas le code en cours d'exécution. Si vous avez chargé une assemblée manuellement à partir d'un chemin d'accès différent, ou si il a été chargé à partir du GAC, il sera de retour le mauvais résultat. Cette réponse est correcte: stackoverflow.com/a/283917/243557 plus Rapide encore est Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location).
- En fait cela ne fonctionne pas dans les applications web, mais comme ce que j'ai trouvé la suite de l'augmentation devrait fonctionner pour tout type d'application: AppDomain.CurrentDomain.RelativeSearchPath ?? AppDomain.CurrentDomain.BaseDirectory
- Pour Ilya Chernomordik. Pour les applications web que j'utilise: Système.Web.De l'hébergement.HostingEnvironment.ApplicationPhysicalPath
- C'est excellent pour les tests unitaires si vous voulez juste pour obtenir l'original bin chemin d'accès de votre test de montage (par exemple, pour atteindre auxiliaire de fichiers de données dans les sous-dossiers). Le test de l'assemblée est le point d'entrée de votre code.
- Je crois que votre solution couvre la plupart des scénarios, et ce, quel que soit le scénario que j'ai rencontrés, à la différence de toute autre réponse. Il mérite plus de visibilité. Vous pourriez certainement poster comme une réponse distincte.
- Avez posté une réponse qui semble fonctionner pour tout type de demande: stackoverflow.com/a/58051383/1671558l comme @Timo a suggéré
InformationsquelleAutor Jalal El-Shaer
66

Même que Jean de réponse, mais un peu moins détaillé de la méthode d'extension.
```
public static string GetDirectoryPath(this Assembly assembly)
{
    string filePath = new Uri(assembly.CodeBase).LocalPath;
    return Path.GetDirectoryName(filePath);            
}
```
Maintenant vous pouvez le faire:
```
var localDir = Assembly.GetExecutingAssembly().GetDirectoryPath();
```
ou si vous préférez:
```
var localDir = typeof(DaoTests).Assembly.GetDirectoryPath();
```
- Avez-vous signifié assembly au lieu de Assembly.GetExecutingAssembly() ?
- En tant que Mec points, vous avez passé en argument et pas réussi à l'utiliser.
- Cette réponse est tout simplement faux de la question à portée de main. Une version modifiée de cette réponse pourrait vous donner le chemin d'une assemblée. Cependant, ici, nous recherchons spécifiquement pour l'exécution de l'assemblée, et ainsi passer dans une assemblée n'a pas de sens. Une méthode d'extension est le bon outil pour le travail.
InformationsquelleAutor Sneal
46

La seule solution qui a fonctionné pour moi lors de l'utilisation de la base de Code et de Réseau UNC actions a été:
```
System.IO.Path.GetDirectoryName(new System.Uri(System.Reflection.Assembly.GetExecutingAssembly().CodeBase).LocalPath);
```
Il travaille également avec la normale Uri trop.
- Ce doit être la accepté de répondre. C'est vraiment gênant que la valeur par défaut de la base de code ne gère pas UNC actions correctes.
- Cela vient s'écraser vers le bas lorsque le dossier contient des espaces, et dieu sait ce que les autres personnages...
- J'ai été en utilisant cette beaucoup et ont trouvé un scénario où il échoue: si cette ligne de code fait partie d'un package NuGet qui est ensuite utilisé par une application! On peut soutenir que les scénario trop en remplaçant GetExecutingAssembly() par GetCallingAssembly().
- avez-vous vérifié si ce changement a des effets secondaires? Si oui, veuillez modifier la réponse à inclure le correctif.
- Malheureusement, je dois signaler qu'il n'a travaillé que celui de la couche profonde, c'est à dire qu'il échoue si le package NuGet a été appelé par un autre package NuGet! Je suis maintenant en utilisant ce (à partir d'un commentaire sur cette page par Chernomordik): AppDomain.CurrentDomain.RelativeSearchPath ?? AppDomain.CurrentDomain.BaseDirectory. La première partie est pour les applications web, et la seconde pour les autres applications.
InformationsquelleAutor Ignacio Soler Garcia
32

Cela devrait fonctionner, à moins que l'assemblée est ombre copié:
```
string path = System.Reflection.Assembly.GetExecutingAssembly().Location
```
InformationsquelleAutor jodonnell

Quoi à ce sujet:

System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);

InformationsquelleAutor huseyint

11

Je soupçonne que le vrai problème ici est que votre test runner est la copie de votre assemblée à un autre emplacement. Il n'y a aucun moyen au moment de l'exécution de dire où l'assemblée a été copié à partir, mais vous pouvez probablement appuyer sur un bouton pour dire le lanceur de test pour exécuter l'assemblée de l'endroit où il est et de ne pas les copier vers un répertoire de l'ombre.

Un tel commutateur est susceptible d'être différent pour chaque test runner, bien sûr.

Avez-vous envisagé l'intégration de vos données XML en tant que ressources à l'intérieur de votre test de montage?
- +1 pour souligner le problème avec l'ombre de la copie. Cependant, il est en effet possible de déterminer le lieu d'origine de la Assembly.CodeBase.
InformationsquelleAutor Curt Hagenlocher
11
```
AppDomain.CurrentDomain.BaseDirectory
```
fonctionne avec MbUnit GUI.
- Cela a très bien fonctionné pour l'écriture d'un fichier par rapport à la racine du répertoire dans un asp.net web app
- J'ai trouvé que cela fonctionne le mieux en général. Choisissez si vous n'êtes pas sûr.
InformationsquelleAutor user368021
7

Aussi loin que je peux dire, la plupart des autres réponses ont quelques problèmes.

La manière correcte de le faire pour un basé sur le disque (par opposition à l'basé sur le web), non-GACed assemblée est à utiliser en cours d'exécution de l'assemblée CodeBase propriété.

Cela renvoie une URL (file://). Au lieu de déconner avec le la manipulation de la chaîne ou UnescapeDataString, cela peut être converti avec un minimum de tracas en tirant parti de la LocalPath propriété de Uri.
```
var codeBaseUrl = Assembly.GetExecutingAssembly().CodeBase;
var filePathToCodeBase = new Uri(codeBaseUrl).LocalPath;
var directoryPath = Path.GetDirectoryName(filePathToCodeBase);
```
- Ne fonctionne pas si le chemin contient des # (EscapedCodeBase fonctionne, mais EscapedCodeBase ne fonctionne pas si le chemin d'accès contient par exemple %20 verbatim (qui est un permis à séquence de caractères dans un chemin d'accès Windows)
- Si nous voulons avoir ce code dans un package NuGet, on peut résoudre ce scénario par le remplacement de GetExecutingAssembly() par GetCallingAssembly().
InformationsquelleAutor spender

var assembly = System.Reflection.Assembly.GetExecutingAssembly();
var assemblyPath = assembly.GetFiles()[0].Name;
var assemblyDir = System.IO.Path.GetDirectoryName(assemblyPath);

InformationsquelleAutor Mark Cidade

Ici est un VB.NET port de John Sibly du code. Visual Basic n'est pas sensible à la casse, un couple de ses noms de variables ont été en collision avec les noms de type de.

Public Shared ReadOnly Property AssemblyDirectory() As String
    Get
        Dim codeBase As String = Assembly.GetExecutingAssembly().CodeBase
        Dim uriBuilder As New UriBuilder(codeBase)
        Dim assemblyPath As String = Uri.UnescapeDataString(uriBuilder.Path)
        Return Path.GetDirectoryName(assemblyPath)
    End Get
End Property

InformationsquelleAutor Mike Schall

Comment à ce sujet ...

string ThisdllDirectory = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);

Puis il suffit de pirater ce que vous n'avez pas besoin

InformationsquelleAutor David C Fuchs

Dans toutes ces années, personne n'a réellement mentionné celui-ci. Un truc que j'ai appris à partir de l'impressionnant ApprovalTests projet. Le truc, c'est que vous utilisez les informations de débogage dans l'assemblée pour trouver le répertoire d'origine.

Cela ne fonctionnera pas en mode RELEASE, ni avec les optimisations activées, ni sur un ordinateur différent de celui sur lequel il a été compilé.

Mais cela vous obtiendrez des chemins qui sont par rapport à l'emplacement du fichier de code source, vous appelez ça de

public static class PathUtilities
{
    public static string GetAdjacentFile(string relativePath)
    {
        return GetDirectoryForCaller(1) + relativePath;
    }
    public static string GetDirectoryForCaller()
    {
        return GetDirectoryForCaller(1);
    }


    public static string GetDirectoryForCaller(int callerStackDepth)
    {
        var stackFrame = new StackTrace(true).GetFrame(callerStackDepth + 1);
        return GetDirectoryForStackFrame(stackFrame);
    }

    public static string GetDirectoryForStackFrame(StackFrame stackFrame)
    {
        return new FileInfo(stackFrame.GetFileName()).Directory.FullName + Path.DirectorySeparatorChar;
    }
}

InformationsquelleAutor George Mauer

5

Le répertoire courant où vous existez.
```
Environment.CurrentDirectory;  //This is the current directory of your application
```
Si vous copiez la .fichier xml de construire avec vous devriez le trouver.

ou
```
System.Reflection.Assembly assembly = System.Reflection.Assembly.GetAssembly(typeof(SomeObject));

//The location of the Assembly
assembly.Location;
```
- cela va être problématique si l'assemblée a été ombre copié.
- +1520! Environment.CurrentDirectory fonctionne si vous êtes l'aide de la réflexion dans la tâche MSBuild classe, où l'assembly en cours d'exécution réside dans le GAC et votre code est quelque part d'autre.
- En général CurrentDirectory ne pas vous dire quels sont les fichiers exécutables de résidence. Ce n'est pas ce qu'il est utilisé pour. C'est souvent le même emplacement les exécutables sont dans, de sorte que beaucoup de programmeurs ne comprends pas la différence. Puis ils finissent par créer un problème pour certaines des utilisateurs finaux que prévu de la demande de comprendre la bonne utilisation de CurrentDirectory.
InformationsquelleAutor David Basarab
5

J'ai été en utilisant de l'Assemblée.Base de code au lieu de la location:
```
Assembly a;
a = Assembly.GetAssembly(typeof(DaoTests));
string s = a.CodeBase.ToUpper(); //file:///c:/path/name.dll
Assert.AreEqual(true, s.StartsWith("FILE://"), "CodeBase is " + s);
s = s.Substring(7, s.LastIndexOf('/') - 7); //7 = "file://"
while (s.StartsWith("/")) {
    s = s.Substring(1, s.Length - 1);
}
s = s.Replace("/", "\\");
```
Elle fonctionne, mais je ne suis plus sûr qu'il est correct à 100%. La page à http://blogs.msdn.com/suzcook/archive/2003/06/26/assembly-codebase-vs-assembly-location.aspx dit:

"Le Code de base d'une URL à l'endroit où le fichier a été trouvé, alors que l'Emplacement est le chemin où il avait été chargé. Par exemple, si l'assemblée a été téléchargé à partir d'internet, de ses CodeBase peut commencer par "http://", mais son Emplacement peut commencer par "C:\". Si le fichier a été l'ombre-copié, l'Emplacement de la voie à la copie du fichier dans le cliché dir.
Il est également bon de savoir que le Code n'est pas garanti à définir pour les assemblées dans le GAC. Emplacement sera toujours ensemble pour les assemblées chargé à partir du disque, cependant."

Vous peut souhaitez utiliser la base de Code au lieu d'Emplacement.
- Donc, beaucoup de code pour la conversion d'une URI dans un chemin. Assurez-vous qu'il pourrait être amélioré. Regardez Mike Schall ou SoMoS de réponse. Vous ne devriez pas essayer de convertir les Uri sur le niveau de corde, mais au lieu d'utiliser les objets adéquats. OK, il est aussi maladroit que de l'Assemblée.Le code renvoie une chaîne de caractères au lieu d'un plus adapté objet, comme URI ou FileInfo.
InformationsquelleAutor dan gibson
5

Je crois que ce serait travailler pour tout type d'application:
```
AppDomain.CurrentDomain.RelativeSearchPath ?? AppDomain.CurrentDomain.BaseDirectory
```
- Mes expériences montrent que c'est le plus infaillible de réponse, couvrant non seulement le web et les applications de console, mais aussi des appels à partir de tests unitaires et les packages NuGet (imbriquée à n'importe quel niveau de récursivité).
InformationsquelleAutor Ilya Chernomordik
2

Vous pouvez obtenir le bac chemin par
Domaine d'application.CurrentDomain.RelativeSearchPath

InformationsquelleAutor sumitup
2

Toutes les propositions de réponses de travail lorsque le développeur peut modifier le code pour inclure le nécessaire extrait de code, mais si vous vouliez le faire, sans modification du code que vous pourriez utiliser Process Explorer.

Il fournira la liste de tous les exécuter dll sur le système, vous devez déterminer l'id de processus de votre application en cours d'exécution, mais qui n'est généralement pas trop difficile.

J'ai écrit une description complète de la façon dont ce faire, pour une dll à l'intérieur II - http://nodogmablog.bryanhogan.net/2016/09/locating-and-checking-an-executing-dll-on-a-running-web-server/
- Notez que, tout d'abord, le code de l'article est assez IIS et sur le deuxième, il vous donne (je crois) tous les actuellement chargé dll, pas ce qui est en cours d'exécution à tout moment.
- L'exemple donné est lié à iis, mais les mêmes étapes s'appliquent si la dll est en cours d'exécution dans un processus extérieur à iis. C'est juste une question d'identifier l'id de processus. Je vais mettre à jour l'article de noter que. Merci pour la suggestion.
InformationsquelleAutor Bryan

dans un formulaire windows app, vous pouvez simplement utiliser Application.StartupPath

mais pour les Dll et console apps le code est beaucoup plus difficile à retenir...

string slash = Path.DirectorySeparatorChar.ToString();
string root = Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);

root += slash;
string settingsIni = root + "settings.ini"

InformationsquelleAutor Shane J

string path = Path.GetDirectoryName(typeof(DaoTests).Module.FullyQualifiedName);

InformationsquelleAutor Jesse C. Slicer

Vous obtiendrez de mauvaises répertoire si un chemin d'accès contient le '#' symbole.
J'utilise donc une modification de la John Sibly réponse est la combinaison UriBuilder.Chemin d'accès et UriBuilder.Fragment:

public static string AssemblyDirectory
{
    get
    {
        string codeBase = Assembly.GetExecutingAssembly().CodeBase;
        UriBuilder uri = new UriBuilder(codeBase);
        //modification of the John Sibly answer    
        string path = Uri.UnescapeDataString(uri.Path.Replace("/", "\\") + 
          uri.Fragment.Replace("/", "\\"));
        return Path.GetDirectoryName(path);
     }
}

InformationsquelleAutor Fedor Shihantsov

C'est ce que je suis venu avec. Entre les projets web, tests unitaires (nunit et resharper test runner); j'ai trouvé que cela a fonctionné pour moi.

J'ai été à la recherche pour le code de détecter la configuration de la construction est en, Debug/Release/CustomName. Hélas, le #if DEBUG. Donc si quelqu'un peut améliorer que!

N'hésitez pas à modifier et améliorer.

Arriver dossier app. Utile pour le web racines, unittests pour obtenir le dossier de fichiers de test.

public static string AppPath
{
    get
    {
        DirectoryInfo appPath = new DirectoryInfo(AppDomain.CurrentDomain.BaseDirectory);

        while (appPath.FullName.Contains(@"\bin\", StringComparison.CurrentCultureIgnoreCase)
                || appPath.FullName.EndsWith(@"\bin", StringComparison.CurrentCultureIgnoreCase))
        {
            appPath = appPath.Parent;
        }
        return appPath.FullName;
    }
}

Arriver bin: Utile pour l'exécution des assemblages à l'aide de la réflexion. Si les fichiers sont copiés en raison de construire des propriétés.

public static string BinPath
{
    get
    {
        string binPath = AppDomain.CurrentDomain.BaseDirectory;

        if (!binPath.Contains(@"\bin\", StringComparison.CurrentCultureIgnoreCase)
            && !binPath.EndsWith(@"\bin", StringComparison.CurrentCultureIgnoreCase))
        {
            binPath = Path.Combine(binPath, "bin");
            //-- Please improve this if there is a better way
            //-- Also note that apps like webapps do not have a debug or release folder. So we would just return bin.
#if DEBUG
            if (Directory.Exists(Path.Combine(binPath, "Debug"))) 
                        binPath = Path.Combine(binPath, "Debug");
#else
            if (Directory.Exists(Path.Combine(binPath, "Release"))) 
                        binPath = Path.Combine(binPath, "Release");
#endif
        }
            return binPath;
    }
}

InformationsquelleAutor Valamas

Cela devrait fonctionner:

ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
Assembly asm = Assembly.GetCallingAssembly();
String path = Path.GetDirectoryName(new Uri(asm.EscapedCodeBase).LocalPath);

string strLog4NetConfigPath = System.IO.Path.Combine(path, "log4net.config");

Je suis en utilisant ce pour déployer le fichier DLL bibliothèques avec un fichier de configuration (c'est d'utiliser log4net de l'intérieur le fichier DLL).

Qu'est-ce que fileMap utilisé pour ici?

InformationsquelleAutor mmmmmm

0

J'ai trouver ma solution adéquate pour la recherche de l'emplacement.
```
var executingAssembly = new FileInfo((Assembly.GetExecutingAssembly().Location)).Directory.FullName;
```
- C'est déjà l'un des meilleurs réponses et est mentionné explicitement dans la question comme quelque chose qui ne fonctionne pas dans cette situation.
- Les excuses doivent de a raté! Évidemment, je n'ai pas lu soigneusement.
InformationsquelleAutor Tez Wingfield
0

J'ai eu le même comportement dans le NUnit dans le passé. Par défaut NUnit des copies de votre assemblée dans le répertoire temp. Vous pouvez modifier ce comportement dans l' NUnit paramètres:

Peut-être TestDriven.NET et MbUnit GUI ont les mêmes paramètres.

InformationsquelleAutor Andrey Bushman
-3

Je l'utilise pour obtenir le chemin d'accès vers le Répertoire Bin:
```
var i = Environment.CurrentDirectory.LastIndexOf(@"\");
var path = Environment.CurrentDirectory.Substring(0,i); 
```
Vous obtenez ce résultat:

"c:\users\ricooley\documents\visual studio
2010\Projects\Windows_Test_Project\Windows_Test_Project\bin"
- Je ne vois pas une raison pour éviter de Chemin.getDirectoryName ici
- Si vous ne voyez pas de raisons, cela ne signifie pas qu'il est de droite. Cette méthode alternative de Chemin.GetDirectoryName est dix fois plus rapide.
InformationsquelleAutor rcooley56
-3

Application Web?
```
Server.MapPath("~/MyDir/MyFile.ext")
```
- c'est une réponse, mais il peut-être semble être une réponse à la mauvaise question. À partir de la question de son assez clair que ce n'est pas une application web mais une assemblée avec les MbUnit. Cela étant dit, la réponse n'est pas encore vraiment correct en raison de Asp.Net de l'ombre à la reproduction (mais qu'il pourrait être ce que quelqu'un atterrissage sur cette question est à la recherche d').
InformationsquelleAutor user2009677

Vous devez vous connecter pour publier un commentaire.