2011-01-21 15 views
47

Tengo un archivo de configuración que necesito cargar como parte de la ejecución de un dll que estoy escribiendo.¿Cómo obtener la ubicación de la DLL que se está ejecutando actualmente?

El problema que estoy teniendo es que el lugar en el que poner el archivo DLL y el archivo de configuración no es la "ubicación actual" cuando la aplicación se está ejecutando.

Por ejemplo, pongo el archivo DLL y xml aquí:

D: \ Archivos de programa \ Microsoft Team Foundation Server 2010 \ Servicios de nivel de aplicación \ web \ bin \ Plugins

Pero si trato de hacer referencia al archivo XML (en mi DLL) como esto:.

XDocument doc = XDocument.Load(@".\AggregatorItems.xml") 

continuación \ AggregatorItems.xml se traduce en :

C: \ windows \ system32 \ inetsrv \ AggregatorItems.xml

Por lo tanto, la necesidad de encontrar una manera (espero) de saber dónde se encuentra el archivo DLL que se está ejecutando actualmente. Básicamente, estoy buscando esto:

XDocument doc = XDocument.Load([email protected]"\AggregatorItems.xml") 

Respuesta

67

Usted está buscando System.Reflection.Assembly.GetExecutingAssembly()

string assemblyFolder = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location); 
string xmlFileName = Path.Combine(assemblyFolder,"AggregatorItems.xml"); 

Editar:

Al parecer, la propiedad Location no funciona correctamente bajo algunas condiciones (la prueba utilizando NUnit, TFS instanciado DLL, Outlook?) - en ese caso puede utilizar la propiedad CodeBase.

+5

Ay! Devuelve 'C: \\ Windows \\ Microsoft.NET \\ Framework64 \\ v4.0.30319 \\ Archivos temporales de ASP.NET \\ tfs \\ de3c0c8e \\ c1bdf790 \\ assembly \\ dl3 \\ 20b156cb \\ 22331f24_bfb9cb01 \ \ AggregatorItems.xml' – Vaccano

+14

¡Ah! Pero 'Assembly.GetExecutingAssembly(). CodeBase' lo tiene! – Vaccano

+0

¿Cómo cargaste esa DLL? Probé ambos con un archivo DLL ejecutable y una biblioteca utilizada por otro EXE y la propiedad 'Ubicación' funcionó para ambos. – BrokenGlass

5
System.Reflection.Assembly.GetExecutingAssembly().Location 
24

La reflexión es su amigo, como se ha señalado. Pero debes usar el método correcto;

Assembly.GetEntryAssembly()  //gives you the entrypoint assembly for the process. 
Assembly.GetCallingAssembly() // gives you the assembly from which the current method was called. 
Assembly.GetExecutingAssembly() // gives you the assembly in which the currently executing code is defined 
Assembly.GetAssembly(Type t) // gives you the assembly in which the specified type is defined. 
+0

+1 para otras opciones (aunque yo no soy utilizarlos). – Vaccano

12

En mi caso (que trata de mis ensamblados cargados [como archivo] en Outlook):

typeof(OneOfMyTypes).Assembly.CodeBase 

Nota el uso de CodeBase (no Location) en el Assembly. Otros han señalado métodos alternativos para ubicar el ensamblaje.

1

Si está trabajando con una aplicación asp.net y que desea localizar asambleas cuando se utiliza el depurador, que se suelen poner en algún directorio temporal. Escribí este método para ayudar con ese escenario.

private string[] GetAssembly(string[] assemblyNames) 
{ 
    string [] locations = new string[assemblyNames.Length]; 


    for (int loop = 0; loop <= assemblyNames.Length - 1; loop++)  
    { 
     locations[loop] = AppDomain.CurrentDomain.GetAssemblies().Where(a => !a.IsDynamic && a.ManifestModule.Name == assemblyNames[loop]).Select(a => a.Location).FirstOrDefault(); 
    } 
    return locations; 
} 

Para más detalles ver esta entrada del blog http://nodogmablog.bryanhogan.net/2015/05/finding-the-location-of-a-running-assembly-in-net/

Si no puede cambiar el código fuente, o volver a implementar, pero puede examinar los procesos que se ejecutan en el Explorador de uso de la computadora de procesos. Escribí una descripción detallada here.

Aparecerá una lista de todas las DLL ejecutables en el sistema, es posible que deba determinar la ID del proceso de su aplicación en ejecución, pero eso no suele ser muy difícil.

He escrito una descripción completa de cómo hacer esto para un archivo DLL en el interior de IIS - http://nodogmablog.bryanhogan.net/2016/09/locating-and-checking-an-executing-dll-on-a-running-web-server/

Cuestiones relacionadas