Jak uzyskać ścieżkę do zestawu, w którym znajduje się kod?

Czy istnieje sposób na uzyskanie ścieżki do zestawu, w którym znajduje się bieżący kod? Nie chcę ścieżki do wywołującego zestawu, tylko tego zawierającego kod.

Zasadniczo mój test jednostkowy musi odczytać niektóre pliki testowe xml, które znajdują się w stosunku do biblioteki dll. Chcę, aby ścieżka zawsze była poprawnie rozwiązywana bez względu na to, czy dll testujący jest uruchamiany z TestDriven.NET, interfejsu GUI MbUnit, czy czegoś innego.

Edycja : Ludzie wydają się nie rozumieć, o co pytam.

Moja biblioteka testów znajduje się w powiedzmy

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

i chciałbym uzyskać tę ścieżkę:

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

Jak dotąd trzy sugestie mnie zawiodły, gdy uruchamiam z MbUnit Gui:

• Environment.CurrentDirectory daje c: \ Program Files \ MbUnit

• System.Reflection.Assembly.GetAssembly(typeof(DaoTests)).Location daje C: \ Documents and Settings \ george \ Local Settings \ Temp \ .... \ DaoTests.dll

• System.Reflection.Assembly.GetExecutingAssembly().Location daje to samo co poprzednie.

Zdefiniowałem następującą właściwość, ponieważ używamy jej często w testach jednostkowych.

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

Assembly.LocationNieruchomość czasami daje jakieś zabawne rezultaty przy użyciu NUnit (gdzie zespoły uruchomić z folderu tymczasowego), więc wolę używać CodeBaseco daje ścieżkę w formacie URI, a następnie UriBuild.UnescapeDataStringusuwa File://się na początku, a GetDirectoryNamezmienia go do formatu normalne okna .

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;

Taki sam jak odpowiedź Johna, ale nieco mniej rozbudowana metoda rozszerzenia.

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 podczas korzystania z CodeBase i udziałów sieciowych UNC było:

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

Działa również z normalnymi identyfikatorami URI.

Powinno to działać, chyba że zestaw jest kopiowany w tle :

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

A co z tym:

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

Podejrzewam, że prawdziwym problemem jest to, że Twój tester kopiuje zestaw w innym miejscu. W środowisku wykonawczym nie ma sposobu, aby dowiedzieć się, skąd zestaw został skopiowany, ale prawdopodobnie możesz przełączyć przełącznik, aby poinformować biegacza testowego, aby uruchomił zestaw z miejsca, w którym się znajduje, i nie kopiował go do katalogu cienia.

Oczywiście taka zmiana może być inna dla każdego uczestnika testu.

Czy rozważałeś osadzenie swoich danych XML jako zasobów w zestawie testowym?

AppDomain.CurrentDomain.BaseDirectory

współpracuje z GUI MbUnit.

Wierzę, że to zadziała dla każdego rodzaju aplikacji:

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

O ile wiem, większość innych odpowiedzi ma kilka problemów.

Prawidłowym sposobem na to w przypadku zestawu opartego na dysku (w przeciwieństwie do zestawu internetowego) bez GACed jest użycie właściwości aktualnie wykonywanego zestawu CodeBase.

Zwraca URL ( file://). Zamiast manipulować ciągami znaków lub UnescapeDataString, można to przekonwertować przy minimalnym zamieszaniu, korzystając z LocalPathwłaściwości Uri.

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

Co powiesz na to ...

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

Następnie po prostu zhakuj to, czego nie potrzebujesz

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

Oto port VB.NET kodu Johna Sably'ego. W programie Visual Basic nie rozróżniana jest wielkość 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

Przez te wszystkie lata nikt tak naprawdę nie wspomniał o tym. Sztuczka, której nauczyłem się z niesamowitego projektu ApprovalTests . Sztuczka polega na tym, że używasz informacji debugowania w zestawie, aby znaleźć oryginalny katalog.

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

Ale to da ci ścieżki, które są względne względem lokalizacji pliku kodu źródłowego, z którego go wywołujesz

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 skopiujesz plik .xml z kompilacją, powinieneś go znaleźć.

lub

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

// The location of the Assembly
assembly.Location;

Korzystałem z Assembly.CodeBase zamiast 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("/", "\\");

Działa, ale nie jestem już pewien, czy jest w 100% poprawny. Strona na stronie http://blogs.msdn.com/suzcook/archive/2003/06/26/assembly-codebase-vs-assembly-location.aspx mówi:

„CodeBase to adres URL miejsca, w którym plik został znaleziony, a Lokalizacja to ścieżka, w której rzeczywiście został załadowany. Na przykład, jeśli zestaw został pobrany z Internetu, jego CodeBase może zaczynać się od„ http: // ” , ale jego lokalizacja może zaczynać się od „C: \”. Jeśli plik został skopiowany w tle, lokalizacja byłaby ścieżką do kopii pliku w katalogu kopii w tle. Dobrze jest również wiedzieć, że CodeBase nie jest gwarantowana należy ustawić dla zestawów w GAC. Jednak lokalizacja będzie zawsze ustawiona dla zestawów ładowanych z dysku. ”

Ty może chcesz używać kodzie zamiast gości.

Ścieżkę do bin można uzyskać przez AppDomain.CurrentDomain.RelativeSearchPath

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

Spowoduje to wyświetlenie listy wszystkich wykonujących bibliotek DLL w systemie, może być konieczne określenie identyfikatora procesu uruchomionej aplikacji, ale zwykle nie jest to zbyt trudne.

Napisałem pełny opis tego, jak to zrobić dla biblioteki DLL wewnątrz II - http://nodogmablog.bryanhogan.net/2016/09/locating-and-checking-an-executing-dll-on-a-running-web -serwer/

w aplikacji systemu Windows można po prostu użyć Application.StartupPath

ale w przypadku bibliotek DLL i aplikacji 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);

Otrzymasz niepoprawny katalog, jeśli ścieżka zawiera symbol „#”. Używam więc modyfikacji odpowiedzi Johna Sible'a, która jest kombinacją UriBuilder.Path i 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);
     }
}

Właśnie to wymyśliłem. Pomiędzy projektami internetowymi, testami jednostkowymi (biegacz testowy nunit i resharper) ; Odkryłem, że to działało dla mnie.

Mam był patrząc na kod do wykrywania co konfiguracja kompilacji jest, Debug/Release/CustomName. Niestety, #if DEBUG. Więc jeśli ktoś może to poprawić !

Możesz edytować i ulepszać.

Pobieranie folderu aplikacji . Przydatny w przypadku katalogów internetowych, pozwala na uzyskanie folderu 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;
    }
}

Pobieranie folderu bin : Przydatne do wykonywania złożeń za pomocą odbicia. Jeśli pliki są tam kopiowane ze względu na właściwości kompilacji.

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 dział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 wdrażania bibliotek plików DLL wraz z niektórymi plikami konfiguracyjnymi (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;

W NUnitprzeszłości miałem takie samo zachowanie . Domyślnie NUnitkopiuje zestaw do katalogu tymczasowego. Możesz zmienić to zachowanie w NUnitustawieniach:

Może TestDriven.NETi MbUnitGUI 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); 

Otrzymasz ten wynik:

„c: \ users \ ricooley \ Document \ visual studio 2010 \ Projects \ Windows_Test_Project \ Windows_Test_Project \ bin”

Aplikacja internetowa?

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