Как получить путь к сборке, в которой находится код?

Есть ли способ получить путь к сборке, в которой находится текущий код? Я не хочу путь к вызывающей сборке, только тот, который содержит код.

В основном мой модульный тест должен прочитать некоторые тестовые файлы XML, которые расположены относительно DLL. Я хочу, чтобы путь всегда разрешался правильно, независимо от того, запускается ли dll-тестирование из TestDriven.NET, через графический интерфейс MbUnit или что-то еще.

Изменить : Люди, кажется, неправильно понимают, что я спрашиваю.

Моя тестовая библиотека находится в скажем

C: \ Projects \ MyApplication \ daotests \ Bin \ Debug \ daotests.dll

и я хотел бы получить этот путь:

C: \ Projects \ MyApplication \ daotests \ Bin \ Debug \

Три предложения пока что подводят меня, когда я запускаю из MbUnit Gui:

• Environment.CurrentDirectory дает c: \ Program Files \ MbUnit

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

• System.Reflection.Assembly.GetExecutingAssembly().Location дает так же, как и предыдущий.

Я определил следующее свойство, так как мы часто используем его в модульном тестировании.

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.Locationсвойство иногда дает некоторые забавные результаты при использовании NUnit (где сборки запускаются из временной папки), поэтому я предпочитаю использовать, CodeBaseкоторый дает вам путь в формате URI, затем UriBuild.UnescapeDataStringудаляет File://в начале и GetDirectoryNameменяет его на обычный формат Windows ,

Это помогает?

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

Это так просто, как это:

var dir = AppDomain.CurrentDomain.BaseDirectory;

То же самое, что и ответ Джона, но чуть менее подробный метод расширения.

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

Теперь вы можете сделать:

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

или если вы предпочитаете:

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

Единственное решение, которое работало для меня при использовании общих ресурсов CodeBase и UNC Network, было:

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

Это также работает с обычными URI тоже.

Это должно работать, если сборка не скопирована тенями :

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

Что насчет этого:

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

Я подозреваю, что реальная проблема заключается в том, что ваш тестовый бегун копирует вашу сборку в другое место. Во время выполнения нет никакого способа определить, откуда была скопирована сборка, но вы, вероятно, можете щелкнуть переключателем, чтобы сообщить исполнителю теста о том, что нужно запустить сборку, а не копировать ее в теневой каталог.

Конечно, такое переключение может быть разным для каждого участника теста.

Рассматривали ли вы встраивание своих XML-данных в качестве ресурсов в тестовую сборку?

AppDomain.CurrentDomain.BaseDirectory

работает с интерфейсом MbUnit.

Я считаю, что это будет работать для любого вида приложений:

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

Насколько я могу судить, у большинства других ответов есть несколько проблем.

Правильный способ сделать это для дисковой (в отличие от веб-сборки ) сборки без GAC - использовать текущую исполняемую сборку.CodeBase свойство .

Это возвращает URL ( file://). Вместо того, чтобы возиться с манипуляциями со строками или UnescapeDataString, это можно преобразовать с минимальной суетой, используя LocalPathсвойство Uri.

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

Как насчет этого ...

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

Тогда просто взломай то, что тебе не нужно

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

Вот порт VB.NET кода Джона Сибли. Visual Basic не чувствителен к регистру, поэтому пара его имен переменных сталкивалась с именами типов.

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

За все эти годы никто не упоминал об этом. Уловка, которую я узнал от удивительного проекта ApprovalTests . Хитрость заключается в том, что вы используете отладочную информацию в сборке, чтобы найти исходный каталог.

Это не будет работать в режиме RELEASE, ни с включенными оптимизациями, ни на компьютере, отличном от того, на котором он был скомпилирован.

Но это даст вам пути относительно места расположения файла исходного кода, из которого вы вызываете его

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

Текущий каталог, в котором вы находитесь.

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

Если вы копируете файл .xml со сборкой, вы должны найти его.

или

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

// The location of the Assembly
assembly.Location;

Я использовал Assembly.CodeBase вместо 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("/", "\\");

Это работает, но я больше не уверен, что это на 100% правильно. Страница по адресу http://blogs.msdn.com/suzcook/archive/2003/06/26/assembly-codebase-vs-assembly-location.aspx сказано:

«CodeBase - это URL-адрес места, где был найден файл, а Location - путь, по которому он был фактически загружен. Например, если сборка была загружена из Интернета, ее CodeBase может начинаться с« http: // » , но его Location может начинаться с "C: \". Если файл был скопирован теневым, Location будет путь к копии файла в каталоге теневого копирования. Также полезно знать, что CodeBase не гарантируется будет установлен для сборок в GAC. Однако расположение всегда будет устанавливаться для сборок, загруженных с диска ».

Вы можете использовать CodeBase вместо Location.

Вы можете получить путь к корзине с помощью AppDomain.CurrentDomain.RelativeSearchPath.

Все предложенные ответы работают, когда разработчик может изменить код для включения необходимого фрагмента, но если вы хотите сделать это без изменения кода, вы можете использовать Process Explorer.

В нем будут перечислены все выполняющиеся библиотеки в системе. Возможно, вам потребуется определить идентификатор процесса вашего работающего приложения, но обычно это не так уж сложно.

Я написал полное описание того, как сделать это для DLL внутри II - http://nodogmablog.bryanhogan.net/2016/09/locating-and-checking-an-executing-dll-on-a-running-web -server /

в приложении Windows Form вы можете просто использовать Application.StartupPath

но для DLL и консольных приложений запоминать код гораздо сложнее ...

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

Вы получите неправильный каталог, если путь содержит символ «#». Поэтому я использую модификацию ответа Джона Сибли, которая представляет собой комбинацию UriBuilder.Path и 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);
     }
}

Это то, что я придумал. Между веб-проектами юнит-тесты (nunit и resharper test runner) ; Я обнаружил, что это работает для меня.

Я искал код, чтобы определить, в какой конфигурации находится сборка Debug/Release/CustomName. Увы, #if DEBUG. Так что, если кто-то может улучшить это !

Не стесняйтесь редактировать и улучшать.

Получение папки приложения . Полезно для веб-корней, юнит-тестов, чтобы получить папку с тестовыми файлами.

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 : полезно для выполнения сборок с использованием отражения. Если файлы копируются туда из-за свойств сборки.

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

Это должно работать:

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

Я использую это для развертывания библиотек файлов DLL вместе с некоторым файлом конфигурации (это использовать log4net из файла DLL).

Я нахожу свое решение адекватным для поиска местоположения.

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

Я получил такое же поведение NUnitв прошлом. По умолчанию NUnitкопирует вашу сборку во временный каталог. Вы можете изменить это поведение в NUnitнастройках:

Возможно TestDriven.NETи MbUnitGUI имеют одинаковые настройки.

Я использую это, чтобы получить путь к Bin Directory:

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

Вы получаете этот результат:

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

Веб приложение?

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