2008-12-18 29 views
23

¿Cómo puedo obtener la ruta (física) instalada de una DLL que está (puede) estar registrada en GAC? Este archivo DLL es un control que puede alojarse en cosas que no sean una aplicación .Net (incluidos IDEs que no sean VS ...).(Físico) (Instalado) ruta de acceso DLL instalada en el GAC

Cuando uso System.Reflection.Assembly.GetExecutingAssembly(). Ubicación, da la ruta de la carpeta GAC ​​en winnt \ system32 - o en modo Diseño en VS da la ruta al VS IDE.

Necesito obtener la ruta donde realmente está instalado el dll físico - o la carpeta bin/debug o (versión) para VS.

La razón es que hay un archivo XML que necesito encontrar en esta carpeta, con ajustes de configuración que se usan tanto en modo de diseño como en tiempo de ejecución.

¿O cómo es mejor manejar este escenario? Tengo una ubicación de red dudosa que estoy utilizando para el modo de diseño en este momento ... (No creo que la carpeta ApplicationData vaya a cortarla (pero tenga la versión .Net instalada ya que está instalada a través de ClickOnce y puede usar Clickonce Data) carpeta))

Respuesta

22

Si algo se puso en la GAC, que en realidad se copia en un punto en% windir% \ assembly, como

C:\WINDOWS\assembly\GAC_32\System.Data\2.0.0.0__b77a5c561934e089\System.Data.dll 

Asumo que eres ver algo así cuando verifica la ubicación del ensamblado en cuestión cuando está instalado en el GAC. Eso es realmente correcto. (En .NET 1.1 había una "Codebase" en la lista cuando mirabas las propiedades de un ensamblado de GAC, pero eso era solo para mostrarte dónde estaba el archivo original cuando ejecutabas gacutil; en realidad, no indicaba qué se cargaría).) Puedes leer more about that here.

En resumen, es posible que no pueda hacer lo que quiere hacer. En lugar de buscar en relación con algún ensamblaje que se está cargando (Assembly.GetExecutingAssembly()), es posible que desee cambiar el comportamiento para que se vea en relación con el ensamblado de la aplicación principal (Assembly.GetEntryAssembly()) o poner el archivo en una ubicación conocida, posiblemente en función de una variable de entorno eso se establece

+0

Desde el principio, he querido ir a una carpeta ApplicationData estándar, según su segunda sugerencia, pero tendrá que estar en la próxima versión, demasiado tarde para hacerlo ahora. Lo tengo intentando varias rutas de acceso por psosible por ahora ... – kpollock

+1

+1 que es un gran enlace –

3

¿Tiene la opción de incrustar un recurso en esta DLL? De esta manera, realmente no importa dónde se encuentra el archivo DLL en el disco, porque el archivo XML lo seguirá. A continuación, puede hacer algo como esto:

Stream s = Assembly.GetExecutingAssembly().GetManifestResourceStream("MyProject.MyXmlFile.xml"); 
XmlDocument d = new XmlDocument(); 
using (StreamReader r = new StreamReader(s)) 
{ 
    d.LoadXml(r.ReadToEnd()); 
} 
+0

Eso es lo que estábamos haciendo, pero el archivo es un archivo de configuración de configuración y eso significaba que teníamos que hacer varias compilaciones para diferentes entornos. La idea es hacer una construcción y hacer que el archivo de configuración controle la configuración dependiente del entorno. – kpollock

2

Si usted está buscando la ubicación física donde su GACed DLL se guarda en el sistema de archivos, intente esto: Inicio -> Ejecutar -> c: \ windows \ assembly \ GAC Si no encuentra su carpeta relacionada con DLL allí, puede hacer una carpeta "Arriba" en el explorador de Windows para mostrar todo en c: \ windows \ assembly como estructuras de carpetas. A continuación, puede buscar el archivo DLL bajo GAC_MSIL o cualquier otra carpeta por ahí ....

Cheers, Sri

+0

lo siento si no estaba claro, pero lo digo en el código! Esta es una pregunta muy antigua y prácticamente respondida por la respuesta marcada anteriormente. – kpollock

3

Después de la asamblea es la sombra copiado en la memoria caché de ensamblados global, no creo que hay cualquier metadato para rastrear la ubicación de los conjuntos de origen.

¿Qué intenta lograr al implementar en GAC? Si solo es por el bien de CLR para propósitos de resolución, entonces hay una manera alternativa que resuelve su problema.

No GAC instalar la dll, en vez agregue la siguiente clave en el registro, (esta ubicación del registro es consultado por CLR cuando se trata de resolver asambleas)

32 bit OS : HKEY_LOCAL_MACHINE\SOFTWARE\\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\foo 

64 bit OS : HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\foo 

Para la clave foo (Use su nombre favorito en lugar de foo), verá un Nombre de clave "Predeterminado". Haga doble clic en él y establezca el valor donde sea que exista su ensamblaje. (se prefiere la ruta absoluta)

Ahora, desde Visual Studio, su cliente debería poder ver sus ensamblajes en el cuadro de diálogo "Agregar referencia" y puede usarlos.

Ahora que se acerca a su problema real,

Assembly.GetExecutingAssembly() devolverá la ruta de la ubicación donde se encuentran presentes de la DLL insatlled. Encuentra el archivo XML desde allí. :)

Nota: En la clave de registro, la versión 4.0.30319 es la versión de .NET Framework que se aplica a su aplicación. Use la versión de su aplicación en su lugar.

Cuestiones relacionadas