Wie erhalte ich den Pfad der Assembly, in der sich der Code befindet?

Gibt es eine Möglichkeit, den Pfad für die Assembly abzurufen, in der sich der aktuelle Code befindet? Ich möchte nicht den Pfad der aufrufenden Assembly, sondern nur den, der den Code enthält.

Grundsätzlich muss mein Unit-Test einige XML-Testdateien lesen, die sich relativ zur DLL befinden. Ich möchte, dass der Pfad immer korrekt aufgelöst wird, unabhängig davon, ob die Test-DLL von TestDriven.NET, der MbUnit-GUI oder etwas anderem ausgeführt wird.

Bearbeiten : Die Leute scheinen falsch zu verstehen, was ich frage.

Meine Testbibliothek befindet sich beispielsweise in

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

und ich möchte diesen Weg bekommen:

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

Die drei Vorschläge, die ich bisher gemacht habe, scheitern, wenn ich von der MbUnit Gui renne:

• Environment.CurrentDirectory gibt c: \ Programme \ MbUnit

• System.Reflection.Assembly.GetAssembly(typeof(DaoTests)).Location gibt C: \ Dokumente und Einstellungen \ george \ Lokale Einstellungen \ Temp \ .... \ DaoTests.dll

• System.Reflection.Assembly.GetExecutingAssembly().Location gibt das gleiche wie das vorherige.

Ich habe die folgende Eigenschaft definiert, da wir diese häufig in Unit-Tests verwenden.

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);
    }
}

Die Assembly.LocationEigenschaft liefert manchmal einige lustige Ergebnisse, wenn Sie NUnit verwenden (wo Assemblys aus einem temporären Ordner ausgeführt werden). Daher bevorzuge ich die Verwendung, CodeBasedie Ihnen den Pfad im URI-Format gibt, dann UriBuild.UnescapeDataStringden File://am Anfang entfernt und GetDirectoryNamein das normale Windows-Format ändert .

Hilft das?

//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 );

So einfach ist das:

var dir = AppDomain.CurrentDomain.BaseDirectory;

Wie Johns Antwort, jedoch eine etwas weniger ausführliche Erweiterungsmethode.

public static string GetDirectoryPath(this Assembly assembly)
{
    string filePath = new Uri(assembly.CodeBase).LocalPath;
    return Path.GetDirectoryName(filePath);            
}

Jetzt können Sie tun:

var localDir = Assembly.GetExecutingAssembly().GetDirectoryPath();

oder wenn Sie es vorziehen:

var localDir = typeof(DaoTests).Assembly.GetDirectoryPath();

Die einzige Lösung, die bei der Verwendung von CodeBase- und UNC-Netzwerkfreigaben für mich funktioniert hat, war:

System.IO.Path.GetDirectoryName(new System.Uri(System.Reflection.Assembly.GetExecutingAssembly().CodeBase).LocalPath);

Es funktioniert auch mit normalen URIs.

Dies sollte funktionieren, es sei denn, die Assembly ist schattenkopiert :

string path = System.Reflection.Assembly.GetExecutingAssembly().Location

Was ist damit:

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

Ich vermute, dass das eigentliche Problem hier darin besteht, dass Ihr Testläufer Ihre Baugruppe an einen anderen Ort kopiert. Zur Laufzeit gibt es keine Möglichkeit festzustellen, woher die Assembly kopiert wurde, aber Sie können wahrscheinlich einen Schalter umlegen, um dem Testläufer mitzuteilen, dass die Assembly von ihrem Standort aus ausgeführt und nicht in ein Schattenverzeichnis kopiert werden soll.

Ein solcher Schalter ist natürlich wahrscheinlich für jeden Testläufer unterschiedlich.

Haben Sie darüber nachgedacht, Ihre XML-Daten als Ressourcen in Ihre Testassembly einzubetten?

AppDomain.CurrentDomain.BaseDirectory

funktioniert mit MbUnit GUI.

Ich glaube, das würde für jede Art von Anwendung funktionieren:

AppDomain.CurrentDomain.RelativeSearchPath ?? AppDomain.CurrentDomain.BaseDirectory

Soweit ich das beurteilen kann, haben die meisten anderen Antworten einige Probleme.

Der richtige Weg, dies für eine festplattenbasierte (im Gegensatz zu webbasierten), nicht GACed-Assembly zu tun, besteht darin, die CodeBaseEigenschaft der aktuell ausgeführten Assembly zu verwenden .

Dies gibt eine URL ( file://) zurück. Anstatt mit der Manipulation von Strings herumzuspielen oder UnescapeDataStringkann dies mit minimalem Aufwand konvertiert werden, indem die LocalPathEigenschaft von genutzt wird Uri.

var codeBaseUrl = Assembly.GetExecutingAssembly().CodeBase;
var filePathToCodeBase = new Uri(codeBaseUrl).LocalPath;
var directoryPath = Path.GetDirectoryName(filePathToCodeBase);

Wie wäre es damit ...

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

Dann hacken Sie einfach ab, was Sie nicht brauchen

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

Hier ist ein VB.NET-Port von John Siblys Code. Visual Basic unterscheidet nicht zwischen Groß- und Kleinschreibung, daher kollidierten einige seiner Variablennamen mit Typnamen.

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

In all den Jahren hat niemand diesen tatsächlich erwähnt. Ein Trick, den ich aus dem großartigen ApprovalTests-Projekt gelernt habe . Der Trick besteht darin, dass Sie die Debugging-Informationen in der Assembly verwenden, um das ursprüngliche Verzeichnis zu finden.

Dies funktioniert weder im RELEASE-Modus noch bei aktivierten Optimierungen oder auf einem anderen Computer als dem, auf dem er kompiliert wurde.

Dadurch erhalten Sie jedoch Pfade, die sich auf den Speicherort der Quellcodedatei beziehen , aus der Sie sie aufrufen

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;
    }
}

Das aktuelle Verzeichnis, in dem Sie existieren.

Environment.CurrentDirectory;  // This is the current directory of your application

Wenn Sie die XML-Datei mit Build kopieren, sollten Sie sie finden.

oder

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

// The location of the Assembly
assembly.Location;

Ich habe Assembly.CodeBase anstelle von Location verwendet:

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("/", "\\");

Es hat funktioniert, aber ich bin nicht mehr sicher, ob es 100% korrekt ist. Auf der Seite unter http://blogs.msdn.com/suzcook/archive/2003/06/26/assembly-codebase-vs-assembly-location.aspx heißt es:

"Die CodeBase ist eine URL zu dem Ort, an dem die Datei gefunden wurde, während der Speicherort der Pfad ist, in den sie tatsächlich geladen wurde. Wenn die Assembly beispielsweise aus dem Internet heruntergeladen wurde, beginnt ihre CodeBase möglicherweise mit" http: // ". , aber sein Speicherort kann mit "C: \" beginnen. Wenn die Datei im Schatten kopiert wurde, ist der Speicherort der Pfad zur Kopie der Datei im Schattenkopierverzeichnis. Es ist auch gut zu wissen, dass die CodeBase nicht garantiert ist Wird für Assemblys im GAC festgelegt. Der Speicherort wird jedoch immer für Assemblys festgelegt, die von der Festplatte geladen werden. "

Möglicherweise möchten Sie CodeBase anstelle von Location verwenden.

Sie können den Bin-Pfad über AppDomain.CurrentDomain.RelativeSearchPath abrufen

Alle vorgeschlagenen Antworten funktionieren, wenn der Entwickler den Code so ändern kann, dass er das erforderliche Snippet enthält. Wenn Sie dies jedoch tun möchten, ohne Code zu ändern, können Sie den Prozess-Explorer verwenden.

Es werden alle ausführenden DLLs auf dem System aufgelistet. Möglicherweise müssen Sie die Prozess-ID Ihrer laufenden Anwendung ermitteln. Dies ist jedoch normalerweise nicht allzu schwierig.

Ich habe eine vollständige Beschreibung geschrieben, wie dies für eine DLL in II funktioniert - http://nodogmablog.bryanhogan.net/2016/09/locating-and-checking-an-executing-dll-on-a-running-web -Server/

In einer Windows Form App können Sie einfach verwenden Application.StartupPath

Für DLLs und Konsolen-Apps ist der Code jedoch viel schwerer zu merken ...

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

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

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

Sie erhalten ein falsches Verzeichnis, wenn ein Pfad das Symbol '#' enthält. Daher verwende ich eine Modifikation der Antwort von John Sibly, nämlich die Kombination UriBuilder.Path und 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);
     }
}

Das habe ich mir ausgedacht. Zwischen Webprojekten Unit-Tests (Nunit und Resharper Test Runner) ; Ich fand das funktionierte für mich.

Ich habe nach Code gesucht, um festzustellen, in welcher Konfiguration sich der Build befindet Debug/Release/CustomName. Leider die #if DEBUG. Also wenn jemand das verbessern kann !

Fühlen Sie sich frei zu bearbeiten und zu verbessern.

App-Ordner abrufen . Nützlich für Web-Roots, Unittests, um den Ordner mit Testdateien abzurufen.

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;
    }
}

Bin-Ordner abrufen : Nützlich zum Ausführen von Assemblys mithilfe von Reflection. Wenn Dateien aufgrund von Build-Eigenschaften dorthin kopiert werden.

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;
    }
}

Das sollte funktionieren:

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");

Ich verwende dies, um DLL-Dateibibliotheken zusammen mit einigen Konfigurationsdateien bereitzustellen (dies dient zur Verwendung von log4net aus der DLL-Datei heraus).

Ich finde meine Lösung ausreichend, um den Standort abzurufen.

var executingAssembly = new FileInfo((Assembly.GetExecutingAssembly().Location)).Directory.FullName;

Ich habe das gleiche Verhalten NUnitin der Vergangenheit. Standardmäßig NUnitkopiert Ihre Assembly in das temporäre Verzeichnis. Sie können dieses Verhalten in den NUnitEinstellungen ändern :

Vielleicht TestDriven.NETund MbUnitGUI haben die gleichen Einstellungen.

Ich benutze dies, um den Pfad zum Bin-Verzeichnis zu erhalten:

var i = Environment.CurrentDirectory.LastIndexOf(@"\");
var path = Environment.CurrentDirectory.Substring(0,i); 

Sie erhalten dieses Ergebnis:

"c: \ Benutzer \ Ricooley \ Dokumente \ Visual Studio 2010 \ Projekte \ Windows_Test_Project \ Windows_Test_Project \ bin"

Internetanwendung?

Server.MapPath("~/MyDir/MyFile.ext")