Jak uzyskać ścieżkę złożeń, w którym znajduje się kod?

Czy to pomaga?

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

To takie proste:

var dir = AppDomain.CurrentDomain.BaseDirectory;

Taka sama jak odpowiedź Jana, ale nieco mniej rozbudowana metoda.

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

Teraz możesz zrobić:

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

Lub jeśli wolisz:

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

Jedynym rozwiązaniem, które działało dla mnie przy użyciu CodeBase i akcji sieciowych UNC było:

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

Działa również z normalnymi Uri.

To powinno działać, chyba że skład jest skopiowany cieniem :

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

Podejrzewam, że prawdziwym problemem jest to, że twój test runner kopiuje Twój zespół w inne miejsce. Nie ma sposobu, aby w czasie wykonywania powiedzieć, skąd assembly został skopiowany, ale prawdopodobnie możesz przełączyć przełącznik, aby powiedzieć runner test, aby uruchomić assembly z miejsca, w którym jest, a nie skopiować go do katalogu shadow.

Taki przełącznik może być oczywiście inny dla każdego biegacza testowego.

Czy rozważałeś osadzenie danych XML jako zasobów wewnątrz testu Zgromadzenie?

A co z tym:

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

AppDomain.CurrentDomain.BaseDirectory

Działa z interfejsem graficznym MbUnit.

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

Oto VB.NET port kodu Johna Sibly ' ego. Visual Basic nie rozróżnia wielkości liter, więc kilka jego nazw zmiennych kolidowało z nazwami typów.

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

Używam Assembly.Kod zamiast Lokalizacji:

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

Przez te wszystkie lata nikt o tym nie wspominał. Sztuczka, której nauczyłem się z niesamowitego ApprovalTests project. Sztuczka polega na tym, że używasz informacji o debugowaniu w złożeniu, aby znaleźć oryginalny katalog.

Nie będzie to działać w trybie RELEASE, ani z włączonymi optymalizacjami, ani na komputerze innym niż ten, na którym został skompilowany.

Ale dzięki temu uzyskasz ścieżki, które są względem lokalizacji pliku kodu źródłowego, który nazywasz od

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

Bieżący katalog, w którym istniejesz.

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

Jeśli skopiujeszplik xml z build powinieneś go znaleźć.

Lub

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

// The location of the Assembly
assembly.Location;

Z tego co wiem, większość innych odpowiedzi ma kilka problemów.

Poprawnym sposobem, aby to zrobić dla dyskowego (w przeciwieństwie do webowego), nie-GACed assembly jest Użycie aktualnie wykonującego assembly właściwości CodeBase.

Zwraca adres URL (file://). Zamiast bawić się manipulacją strunami lub UnescapeDataString, można to przekształcić przy minimalnym zamieszaniu, wykorzystując właściwość LocalPath Uri.

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

Co ty na to?..

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

Następnie po prostu siekać to, czego nie trzeba

Możesz uzyskać ścieżkę binową przez AppDomain.CurrentDomain.RelativeSearchPath

Wszystkie proponowane odpowiedzi działają, gdy programista może zmienić kod, aby zawierał wymagany fragment, ale jeśli chcesz to zrobić bez zmiany kodu, możesz użyć Process Explorer.

Wyświetli listę wszystkich uruchomionych bibliotek DLL w systemie, może być konieczne określenie id procesu uruchomionej aplikacji, ale zwykle nie jest to zbyt trudne.

Napisałem pełny opis jak to zrobić dla dll inside II - http://nodogmablog.bryanhogan.net/2016/09/locating-and-checking-an-executing-dll-on-a-running-web-server/

W aplikacji windows form można po prostu użyć Application.StartupPath

Ale w bibliotekach DLL i aplikacjach konsolowych kod jest znacznie trudniejszy do zapamiętania...

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

To właśnie wymyśliłem. pomiędzy projektami sieciowymi, testami jednostkowymi (nunit i ReSharper Test runner) ; okazało się, że to działa dla mnie.

Szukałem kodu do wykrycia, w jakiej konfiguracji znajduje się build, Debug/Release/CustomName. Niestety, #if DEBUG. więc jeśli ktoś może to poprawić !

Zapraszam do edycji i poprawy.

Pobieranie folderu aplikacji . Przydatne dla web roots, unittests, aby uzyskać folder plików testowych.

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

Getting bin folder : Przydatne do wykonywania złożeń przy użyciu reflection. Jeśli pliki są tam kopiowane ze względu na właściwości budowania.

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

To powinno zadziałać:

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

Używam tego do wdrożenia bibliotek plików DLL wraz z jakimś plikiem konfiguracyjnym(jest to użycie log4net z pliku DLL).

Uważam, że moje rozwiązanie jest odpowiednie do odzyskania lokalizacji.

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

Miałem to samo zachowanie w NUnit w przeszłości. Domyślnie NUnit kopiuje twój zestaw do katalogu temp. Możesz zmienić to zachowanie w Ustawieniach NUnit:

Może TestDriven.NET i MbUnit GUI mają te same ustawienia.

Używam tego, aby uzyskać ścieżkę do katalogu Bin:

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

Otrzymujesz ten wynik:

"c:\users\ricooley\documents\visual studio 2010 \ Projects\Windows_Test_Project\Windows_Test_Project \ bin"

Aplikacja internetowa?

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