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

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

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

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

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

Если вы скопируете файл .xml с помощью build, вы должны его найти.

или же

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

// The location of the Assembly
assembly.Location;

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

//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 assembly = System.Reflection.Assembly.GetExecutingAssembly();
var assemblyPath = assembly.GetFiles()[0].Name;
var assemblyDir = System.IO.Path.GetDirectoryName(assemblyPath);

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

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

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

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

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

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

Я использовал 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.

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

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.

Вот порт 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

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

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

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

var dir = AppDomain.CurrentDomain.BaseDirectory;

AppDomain.CurrentDomain.BaseDirectory

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

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

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"

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

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

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

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

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

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

Я искал код, чтобы определить, в какой конфигурации находится сборка, 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;
    }
}

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

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

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

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

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

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

Я считаю, что мое решение подходит для определения местоположения.

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

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

Возможно, у TestDriven.NET и MbUnit GUI одинаковые настройки.

За все эти годы об этом никто не упомянул. Трюк, который я узнал из классного Проект 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;
    }
}

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

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

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

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

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

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

Я написал полное описание, как это сделать для 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"

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

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

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

Начиная с .net framework 4.6 / .net core 1.0, теперь существует AppContext.BaseDirectory, который должен давать тот же результат, что и AppDomain.CurrentDomain.BaseDirectory, за исключением того, что домены приложений не были частью стандартного API 1.x .net core 1.x /.net.

AppContext.BaseDirectory

Для ASP.Net это не работает. Я нашел более подходящее решение на Почему AppDomain.CurrentDomain.BaseDirectory не содержит «bin» в приложении asp.net?. Он работает как для приложения Win, так и для веб-приложения ASP.Net.

public string ApplicationPath
    {
        get
        {
            if (String.IsNullOrEmpty(AppDomain.CurrentDomain.RelativeSearchPath))
            {
                return AppDomain.CurrentDomain.BaseDirectory; //exe folder for WinForms, Consoles, Windows Services
            }
            else
            {
                return AppDomain.CurrentDomain.RelativeSearchPath; //bin folder for Web Apps 
            }
        }
    }