¿Cómo obtengo la ruta del ensamblado en el que se encuentra el código?

¿Hay alguna manera de obtener la ruta para el ensamblado en el que reside el código actual? No quiero la ruta del ensamblado de llamada, solo la que contiene el código.

Básicamente, mi prueba unitaria necesita leer algunos archivos de prueba xml que se encuentran en relación con el dll. Quiero que la ruta siempre se resuelva correctamente, independientemente de si el dll de prueba se ejecuta desde TestDriven.NET, la GUI MbUnit u otra cosa.

Editar : La gente parece estar malentendiendo lo que estoy preguntando.

Mi biblioteca de prueba está ubicada en say

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

y me gustaría obtener este camino:

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

Las tres sugerencias hasta ahora me fallan cuando corro desde MbUnit Gui:

• Environment.CurrentDirectory da c: \ Archivos de programa \ MbUnit

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

• System.Reflection.Assembly.GetExecutingAssembly().Location da lo mismo que el anterior.

He definido la siguiente propiedad ya que la usamos a menudo en pruebas unitarias.

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

La Assembly.Locationpropiedad a veces le da algunos resultados divertidos cuando usa NUnit (donde los ensamblajes se ejecutan desde una carpeta temporal), por lo que prefiero usar el CodeBaseque le da la ruta en formato URI, luego UriBuild.UnescapeDataStringelimina el File://al principio y lo GetDirectoryNamecambia al formato normal de Windows .

¿Esto ayuda?

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

Es tan simple como esto:

var dir = AppDomain.CurrentDomain.BaseDirectory;

Igual que la respuesta de John, pero un método de extensión un poco menos detallado.

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

Ahora puedes hacer:

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

o si lo prefieres:

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

La única solución que me funcionó al usar CodeBase y los recursos compartidos de la red UNC fue:

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

También funciona con URI normales también.

Esto debería funcionar, a menos que el ensamblaje se copie de forma oculta :

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

¿Qué hay de esto?

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

Sospecho que el problema real aquí es que su corredor de prueba está copiando su ensamblaje en una ubicación diferente. No hay forma en el tiempo de ejecución de saber de dónde se copió el ensamblaje, pero probablemente pueda accionar un interruptor para decirle al corredor de prueba que ejecute el ensamblaje desde donde está y que no lo copie en un directorio oculto.

Es probable que dicho cambio sea diferente para cada corredor de prueba, por supuesto.

¿Ha considerado incrustar sus datos XML como recursos dentro de su ensamblaje de prueba?

AppDomain.CurrentDomain.BaseDirectory

funciona con MbUnit GUI.

Creo que esto funcionaría para cualquier tipo de aplicación:

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

Por lo que puedo decir, la mayoría de las otras respuestas tienen algunos problemas.

La forma correcta de hacer esto para un ensamblado no GACed basado en disco (en lugar de basado en web) es utilizar el ensamblado que se está ejecutando actualmenteCodeBase propiedad .

Esto devuelve una URL ( file://). En lugar de perder el tiempo con la manipulación de cadenas o UnescapeDataString, esto se puede convertir con un mínimo de alboroto aprovechando la LocalPathpropiedad de Uri.

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

Qué tal esto ...

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

Luego simplemente corta lo que no necesitas

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

Aquí hay un puerto VB.NET del código de John Sibly. Visual Basic no distingue entre mayúsculas y minúsculas, por lo que un par de sus nombres de variables colisionaron con los nombres de tipo.

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

En todos estos años, nadie ha mencionado este. Un truco que aprendí del impresionante proyecto ApprovalTests . El truco es que usa la información de depuración en el ensamblado para encontrar el directorio original.

Esto no funcionará en modo RELEASE, ni con optimizaciones habilitadas, ni en una máquina diferente de la que fue compilada.

Pero esto le dará rutas relacionadas con la ubicación del archivo de código fuente desde el que lo llama

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

El directorio actual donde existes.

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

Si copia el archivo .xml con build, debería encontrarlo.

o

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

// The location of the Assembly
assembly.Location;

He estado usando Assembly.CodeBase en lugar de 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("/", "\\");

Ha estado funcionando, pero ya no estoy seguro de que sea 100% correcto. La página en http://blogs.msdn.com/suzcook/archive/2003/06/26/assembly-codebase-vs-assembly-location.aspx dice:

"CodeBase es una URL del lugar donde se encontró el archivo, mientras que la ubicación es la ruta donde realmente se cargó. Por ejemplo, si el ensamblado se descargó de Internet, su CodeBase puede comenzar con" http: // " , pero su ubicación puede comenzar con "C: \". Si el archivo se ha copiado en la sombra, la ubicación sería la ruta a la copia del archivo en el directorio de copia de la sombra. También es bueno saber que CodeBase no está garantizado Sin embargo, la ubicación siempre se establecerá para los ensamblados cargados desde el disco. "

Es posible que desee utilizar CodeBase en lugar de Ubicación.

Puede obtener la ruta bin por AppDomain.CurrentDomain.RelativeSearchPath

Todas las respuestas propuestas funcionan cuando el desarrollador puede cambiar el código para incluir el fragmento requerido, pero si desea hacerlo sin cambiar ningún código, puede usar Process Explorer.

Enumerará todos los dlls en ejecución en el sistema, es posible que deba determinar la identificación del proceso de su aplicación en ejecución, pero eso generalmente no es demasiado difícil.

He escrito una descripción completa de cómo hacer esto para un dll dentro de II - http://nodogmablog.bryanhogan.net/2016/09/locating-and-checking-an-executing-dll-on-a-running-web -servidor/

en una aplicación de formulario de Windows, simplemente puede usar Application.StartupPath

pero para las DLL y las aplicaciones de consola, el código es mucho más difícil de recordar ...

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

Obtendrá un directorio incorrecto si una ruta contiene el símbolo '#'. Entonces uso una modificación de la respuesta de John Sibly que es la combinación UriBuilder.Path y 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);
     }
}

Esto es lo que se me ocurrió. Entre proyectos web, pruebas unitarias (nunit y runner test runner) ; Encontré que esto funcionó para mí.

He estado buscando código para detectar qué configuración es la acumulación en, Debug/Release/CustomName. Por desgracia, el #if DEBUG. Entonces, si alguien puede mejorar eso !

Siéntase libre de editar y mejorar.

Obteniendo la carpeta de la aplicación . Útil para raíces web, pruebas unitarias para obtener la carpeta de archivos de prueba.

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

Cómo obtener la carpeta bin : útil para ejecutar ensamblajes usando la reflexión. Si los archivos se copian allí debido a las propiedades de compilación.

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

Esto debería funcionar:

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

Estoy usando esto para implementar bibliotecas de archivos DLL junto con algún archivo de configuración (esto es para usar log4net desde dentro del archivo DLL).

Encuentro mi solución adecuada para la recuperación de la ubicación.

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

Obtuve el mismo comportamiento NUniten el pasado. Por defecto NUnitcopia su ensamblaje en el directorio temporal. Puede cambiar este comportamiento en la NUnitconfiguración:

Quizás TestDriven.NETy MbUnitGUI tienen la misma configuración.

Lo uso para obtener la ruta al directorio Bin:

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

Obtienes este resultado:

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

¿Aplicación web?

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