Existe-t-il un moyen d’obtenir le chemin de l’assembly dans lequel réside le code actuel? Je ne veux pas le chemin de l’assembly appelant, juste celui contenant le code.
Fondamentalement, mon test unitaire doit lire certains fichiers de test xml situés par rapport à la DLL. Je veux que le chemin se résolve toujours correctement, que la DLL de test soit exécutée à partir de TestDriven.NET, de l’interface graphique de MbUnit ou autre chose.
Edit : Les gens semblent mal comprendre ce que je demande.
Ma bibliothèque de tests se trouve dans say
C: \ projects \ monapplication \ daotests \ bin \ Debug \ daotests.dll
et j’aimerais avoir ce chemin:
C: \ projects \ monapplication \ daotests \ bin \ Debug \
Les trois suggestions jusqu’à présent me manquent quand je cours à partir du MbUnit Gui:
Environment.CurrentDirectory
donne c: \ Program Files \ MbUnit
System.Reflection.Assembly.GetAssembly(typeof(DaoTests)).Location
donne C: \ Documents and Settings \ george \ Paramètres locaux \ Temp \ …. \ DaoTests.dll
System.Reflection.Assembly.GetExecutingAssembly().Location
donne le même que le précédent.
J’ai défini la propriété suivante comme nous l’utilisons souvent dans les tests unitaires.
public static ssortingng AssemblyDirectory { get { ssortingng codeBase = Assembly.GetExecutingAssembly().CodeBase; UriBuilder uri = new UriBuilder(codeBase); ssortingng path = Uri.UnescapeDataSsortingng(uri.Path); return Path.GetDirectoryName(path); } }
La propriété Assembly.Location
vous donne parfois des résultats amusants lors de l’utilisation de NUnit (où les assemblys s’exécutent à partir d’un dossier temporaire), donc je préfère utiliser CodeBase
qui vous donne le chemin au format URI, puis UriBuild.UnescapeDataSsortingng
supprime File://
at le début, et GetDirectoryName
change au format Windows normal.
est-ce que cela aide?
//get the full location of the assembly with DaoTests in it ssortingng fullPath = System.Reflection.Assembly.GetAssembly(typeof(DaoTests)).Location; //get the folder that's in ssortingng theDirectory = Path.GetDirectoryName( fullPath );
C’est aussi simple que cela:
var dir = AppDomain.CurrentDomain.BaseDirectory;
Identique à la réponse de John, mais une méthode d’extension légèrement moins verbeuse.
public static ssortingng GetDirectoryPath(this Assembly assembly) { ssortingng filePath = new Uri(assembly.CodeBase).LocalPath; return Path.GetDirectoryName(filePath); }
Maintenant vous pouvez faire:
var localDir = Assembly.GetExecutingAssembly().GetDirectoryPath();
ou si vous préférez:
var localDir = typeof(DaoTests).Assembly.GetDirectoryPath();
La seule solution qui a fonctionné pour moi lors de l’utilisation des partages CodeBase et UNC Network était:
System.IO.Path.GetDirectoryName(new System.Uri(System.Reflection.Assembly.GetExecutingAssembly().CodeBase).LocalPath);
Cela fonctionne aussi avec les URIs normaux.
Cela devrait fonctionner, à moins que l’assembly ne soit copié sous ombre :
ssortingng path = System.Reflection.Assembly.GetExecutingAssembly().Location
Je soupçonne que le vrai problème est que votre utilisateur teste votre assembly à un endroit différent. Au moment de l’exécution, il est impossible de savoir d’où l’assembly a été copié, mais vous pouvez probablement basculer un commutateur pour demander au programme d’exécution d’exécuter l’assemblage où il se trouve et de ne pas le copier dans un répertoire caché.
Un tel commutateur est probablement différent pour chaque utilisateur de test, bien sûr.
Avez-vous envisagé d’intégrer vos données XML en tant que ressources dans votre assemblage de test?
Et ça:
System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);
AppDomain.CurrentDomain.BaseDirectory
fonctionne avec l’interface graphique de MbUnit.
var assembly = System.Reflection.Assembly.GetExecutingAssembly(); var assemblyPath = assembly.GetFiles()[0].Name; var assemblyDir = System.IO.Path.GetDirectoryName(assemblyPath);
Voici un port VB.NET du code de John Sibly. Visual Basic n’étant pas sensible à la casse, certains de ses noms de variable entraient en collision avec des noms de type.
Public Shared ReadOnly Property AssemblyDirectory() As Ssortingng Get Dim codeBase As Ssortingng = Assembly.GetExecutingAssembly().CodeBase Dim uriBuilder As New UriBuilder(codeBase) Dim assemblyPath As Ssortingng = Uri.UnescapeDataSsortingng(uriBuilder.Path) Return Path.GetDirectoryName(assemblyPath) End Get End Property
J’ai utilisé Assembly.CodeBase au lieu de Location:
Assembly a; a = Assembly.GetAssembly(typeof(DaoTests)); ssortingng s = a.CodeBase.ToUpper(); // file:///c:/path/name.dll Assert.AreEqual(true, s.StartsWith("FILE://"), "CodeBase is " + s); s = s.Subssortingng(7, s.LastIndexOf('/') - 7); // 7 = "file://" while (s.StartsWith("/")) { s = s.Subssortingng(1, s.Length - 1); } s = s.Replace("/", "\\");
Cela a fonctionné, mais je ne suis plus sûr que ce soit 100% correct. La page à l’ adresse http://blogs.msdn.com/suzcook/archive/2003/06/26/assembly-codebase-vs-assembly-location.aspx dit:
“Le CodeBase est une URL vers l’endroit où le fichier a été trouvé, alors que Location est le chemin où il a été chargé. Par exemple, si l’assembly a été téléchargé depuis Internet, son CodeBase peut commencer par” http: // ” , mais son emplacement peut commencer par “C: \”. Si le fichier a été copié par des ombres, l’emplacement serait le chemin d’access à la copie du fichier dans le répertoire des clichés instantanés. à définir pour les assemblys dans le GAC. L’emplacement sera toujours défini pour les assemblys chargés à partir du disque. ”
Vous souhaiterez peut -être utiliser CodeBase au lieu de Location.
Pendant toutes ces années, personne n’a en fait mentionné celle-ci. Un truc que j’ai appris du projet impressionnant ApprovalTests . L’astuce consiste à utiliser les informations de débogage dans l’assembly pour rechercher le répertoire d’origine.
Cela ne fonctionnera pas en mode RELEASE, ni avec les optimisations activées, ni sur une machine différente de celle sur laquelle il a été compilé.
Mais cela vous donnera des chemins relatifs à l’emplacement du fichier de code source que vous appelez depuis
public static class PathUtilities { public static ssortingng GetAdjacentFile(ssortingng relativePath) { return GetDirectoryForCaller(1) + relativePath; } public static ssortingng GetDirectoryForCaller() { return GetDirectoryForCaller(1); } public static ssortingng GetDirectoryForCaller(int callerStackDepth) { var stackFrame = new StackTrace(true).GetFrame(callerStackDepth + 1); return GetDirectoryForStackFrame(stackFrame); } public static ssortingng GetDirectoryForStackFrame(StackFrame stackFrame) { return new FileInfo(stackFrame.GetFileName()).Directory.FullName + Path.DirectorySeparatorChar; } }
Le répertoire actuel où vous existez.
Environment.CurrentDirectory; // This is the current directory of your application
Si vous copiez le fichier .xml avec build, vous devez le trouver.
ou
System.Reflection.Assembly assembly = System.Reflection.Assembly.GetAssembly(typeof(SomeObject)); // The location of the Assembly assembly.Location;
Pour autant que je sache, la plupart des autres réponses ont quelques problèmes.
Pour ce faire, la méthode correcte consiste à utiliser la propriété CodeBase
l’assembly en cours d’ CodeBase
.
Cela renvoie une URL ( file://
). Au lieu de jouer avec la manipulation de chaînes ou UnescapeDataSsortingng
, cela peut être converti avec un minimum de LocalPath
en exploitant la propriété LocalPath
d’ Uri
.
var codeBaseUrl = Assembly.GetExecutingAssembly().CodeBase; var filePathToCodeBase = new Uri(codeBaseUrl).LocalPath; var directoryPath = Path.GetDirectoryName(filePathToCodeBase);
Que dis-tu de ça …
ssortingng ThisdllDirectory = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);
Ensuite, hack juste ce que vous n’avez pas besoin
Vous pouvez obtenir le chemin d’access bin par AppDomain.CurrentDomain.RelativeSearchPath
Toutes les réponses proposées fonctionnent lorsque le développeur peut modifier le code pour inclure l’extrait de code requirejs, mais si vous souhaitez le faire sans modifier le code, vous pouvez utiliser Process Explorer.
Il listera tous les DLL en cours d’exécution sur le système, vous devrez peut-être déterminer l’ID de processus de votre application en cours d’exécution, mais ce n’est généralement pas trop difficile.
J’ai écrit une description complète de la façon dont faire cela pour un dll dans II – http://nodogmablog.bryanhogan.net/2016/09/locating-and-checking-an-executing-dll-on-a-running-web -serveur/
dans une application Windows Form, vous pouvez simplement utiliser Application.StartupPath
mais pour les applications de DLL et de console, le code est beaucoup plus difficile à retenir …
ssortingng slash = Path.DirectorySeparatorChar.ToSsortingng(); ssortingng root = Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location); root += slash; ssortingng settingsIni = root + "settings.ini"
ssortingng path = Path.GetDirectoryName(typeof(DaoTests).Module.FullyQualifiedName);
C’est ce que j’ai trouvé. Entre les projets Web, les tests unitaires (testeur non officiel et testeur) ; J’ai trouvé que cela fonctionnait pour moi.
J’ai cherché du code pour détecter la configuration de la construction, Debug/Release/CustomName
. Hélas, le #if DEBUG
. Donc, si quelqu’un peut améliorer cela !
N’hésitez pas à modifier et à améliorer.
Obtenir le dossier de l’application . Utile pour les racines Web, les désinscriptions pour obtenir le dossier des fichiers de test.
public static ssortingng AppPath { get { DirectoryInfo appPath = new DirectoryInfo(AppDomain.CurrentDomain.BaseDirectory); while (appPath.FullName.Contains(@"\bin\", SsortingngComparison.CurrentCultureIgnoreCase) || appPath.FullName.EndsWith(@"\bin", SsortingngComparison.CurrentCultureIgnoreCase)) { appPath = appPath.Parent; } return appPath.FullName; } }
Obtenir le dossier bin : utile pour exécuter des assemblages à l’aide de la reflection. Si des fichiers y sont copiés en raison des propriétés de construction.
public static ssortingng BinPath { get { ssortingng binPath = AppDomain.CurrentDomain.BaseDirectory; if (!binPath.Contains(@"\bin\", SsortingngComparison.CurrentCultureIgnoreCase) && !binPath.EndsWith(@"\bin", SsortingngComparison.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; } }
Cela devrait fonctionner:
ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap(); Assembly asm = Assembly.GetCallingAssembly(); Ssortingng path = Path.GetDirectoryName(new Uri(asm.EscapedCodeBase).LocalPath); ssortingng strLog4NetConfigPath = System.IO.Path.Combine(path, "log4net.config");
Je l’utilise pour déployer des bibliothèques de fichiers DLL avec un fichier de configuration (pour utiliser log4net à partir du fichier DLL).
Je trouve ma solution adéquate pour la récupération de l’emplacement.
var executingAssembly = new FileInfo((Assembly.GetExecutingAssembly().Location)).Directory.FullName;
J’ai eu le même comportement dans la NUnit
dans le passé. Par défaut, NUnit
copie votre assembly dans le répertoire temp. Vous pouvez modifier ce comportement dans les parameters NUnit
:
Peut-être que TestDriven.NET
et MbUnit
GUI ont les mêmes parameters.
Je l’utilise pour obtenir le chemin du répertoire de la corbeille:
var i = Environment.CurrentDirectory.LastIndexOf(@"\"); var path = Environment.CurrentDirectory.Subssortingng(0,i);
Vous obtenez ce résultat:
“c: \ users \ ricooley \ documents \ visual studio 2010 \ Projets \ Windows_Test_Project \ Windows_Test_Project \ bin”
Application Web?
Server.MapPath("~/MyDir/MyFile.ext")