c# - ¿Las redirecciones de enlace en app.config para bibliotecas de clase hacen algo?
.net nuget (4)
Generalmente, solo hay un archivo de configuración y ese es el archivo de configuración del ejecutable (.exe.config, web.config).
Cualquier redireccionamiento de ensamblajes debe colocarse en el archivo de configuración del ejecutable.
Los archivos de configuración de dlls deben cargarse manualmente utilizando la clase ConfigurationManager. Consulte también esta pregunta Equivalente a ''app.config'' para una biblioteca (DLL)
Las soluciones de VS con las que trabajo a menudo consisten en un solo proyecto ejecutable (aplicación de consola, aplicación web) y muchos proyectos de bibliotecas de clases a los que el ejecutable hace referencia.
Al trabajar con NuGet e instalar paquetes, a menudo hay un archivo app.config creado para cada proyecto, que generalmente no contiene nada más que una lista de redirecciones de enlace que consolidan las versiones de los ensamblajes a los que se hace referencia. A veces hay contenido específico de bibliotecas de terceros (como la sección de configuración de Entity Framework), pero dejemos eso de lado por ahora.
Cuando compilo la solución y uso los binarios del proyecto ejecutable principal, veo todos los ensamblados del proyecto de la biblioteca de clases en la salida de compilación junto con los archivos *.config correspondientes (el archivo app.config se renombra a AssemblyName.config cuando se construye) .
Al iniciar el ejecutable principal, ¿los archivos de configuración de los ensamblados de la biblioteca de clases tienen algún efecto? ¿O es solo el archivo app.config del ejecutable que tiene un efecto en este caso? ¿Qué sucede si hay algunos redireccionamientos de enlaces configurados en algunos de los proyectos de la biblioteca de clases y algunos redireccionamientos de enlaces diferentes configurados en el proyecto ejecutable principal? ¿Cómo se combinan, cuáles tienen prioridad?
He intentado investigar esto en línea y, por lo que he leído, me parece que los archivos app.config para ensamblajes no ejecutables son inútiles (con respecto a los redireccionamientos de enlace). ¿Alguien puede confirmar esto o elaborar un poco más sobre el tema?
Si es así, ¿es realmente indeseable tener estos archivos app.config creados por NuGet en las bibliotecas de clase si contienen solo los redireccionamientos de enlaces? Me parece que NuGet no debería crear esos redireccionamientos de enlace para proyectos de biblioteca de clases, ya que solo aumentará la confusión sobre qué configuración se aplica realmente.
Encontré estas preguntas existentes sobre el desbordamiento de pila en el tema, pero sus respuestas aceptadas son en realidad contradictorias incluso cuando están marcadas como duplicadas entre sí .
La respuesta aceptada a la primera pregunta menciona que los archivos app.config se usan realmente durante el tiempo de compilación, lo que significa que podrían tener efecto. Las fuentes como MSDN y el código fuente de MSBuild se citan allí como una prueba de que se utiliza durante el tiempo de compilación. Desafortunadamente, no soy lo suficientemente competente en MSBuild para entender cómo se está utilizando, y si es realmente un argumento válido.
¿Puede alguien describir un escenario de ejemplo para probar que un app.config con redirecciones de enlace para una biblioteca de clases puede hacer algo?
No, solo el app.config del ejecutable tendrá efecto. Por ejemplo, si tiene una aplicación de consola que aloja un servicio WCF, y en su servicio WCF utiliza, por ejemplo, ConfigurationManager.AppSettings , AppSettings provendrá del archivo app.config host de la consola. Si gira otra aplicación de consola (ConsoleClient) para intentar conectarse a ConsoleHost, entonces en las partes donde se puede decir que ConsoleClient se está "ejecutando" (por ejemplo, en su método principal), utilizará el app.config de app.config , pero tan pronto como comience a usar el servicio WCF, el servicio WCF delegará el uso de la aplicación de app.config de app.config . (Tenga en cuenta que este último punto es más relevante para los detalles detrás de WCF).
Sorprendentemente, msdn proporcionó esta gran fuente: https://social.msdn.microsoft.com/Forums/vstudio/en-US/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll-access-application-settings?referrer=http://social.msdn.microsoft.com/Forums/vstudio/en-US/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll-access-application-settings?referrer=http://social.msdn.microsoft.com/Forums/vstudio/en-US/e13194df-6308-4cbe-973c-f6a462f43eae/how-can-wcf-library-dll-access-application-settings?forum=wcf
Según este antiguo artículo de MSDN :
Un archivo de configuración de la aplicación es un archivo XML que se utiliza para controlar el enlace de ensamblaje. Puede redirigir una aplicación utilizando una versión de un ensamblaje en paralelo a otra versión del mismo ensamblaje. Esto se llama configuración por aplicación. Un archivo de configuración de la aplicación se aplica solo a un manifiesto de aplicación específico y a conjuntos dependientes. Los componentes aislados compilados con un manifiesto [ ISOLATIONAWARE_MANIFEST_RESOURCE_ID ] incrustado requieren un archivo de configuración de la aplicación por separado. Los manifiestos gestionados con CreateActCtx requieren un archivo de configuración de la aplicación por separado.
Por lo tanto, solo los archivos DLL con el conjunto ISOLATIONAWARE_MANIFEST_RESOURCE_ID realidad usan una configuración de aplicación independiente, de lo contrario, se difiere al archivo de configuración del proceso principal.
Para obtener más información sobre qué es ISOLATIONAWARE, puede leer este otro artículo de MSDN que profundiza más.
ISOLATIONAWARE_MANIFEST_RESOURCE_ID se usa principalmente para DLL. Se debe usar si la dll quiere dependencias privadas distintas del proceso predeterminado. Por ejemplo, si un dll depende de comctl32.dll versión 6.0.0.0. Debería tener un recurso de tipo RT_MANIFEST, ID ISOLATIONAWARE_MANIFEST_RESOURCE_ID para depender de comctl32.dll versión 6.0.0.0, de modo que incluso si el ejecutable del proceso desea comctl32.dll versión 5.1, el dll seguirá usando la versión correcta de comctl32.dll.
Tengo varias aplicaciones con una configuración similar: aplicaciones web que hacen referencia a múltiples proyectos de biblioteca, cada uno con sus propios paquetes nuget, etc. Según mi experiencia personal, los enlaces de ensamblaje en los proyectos de biblioteca no se consideran durante el tiempo de ejecución.
Los enlaces especificados en la configuración de la aplicación o web en la aplicación raíz (web / console) es que solo importa. Todos los proyectos de mi biblioteca se configuran con la configuración "Copiar en el Directorio de salida" como "No copiar" para el archivo app.config; de esa manera, mi carpeta de salida no está desordenada con dll y sus archivos de configuración.
Aquí está el enlace que dice cómo se carga el ensamblaje y dónde se busca y la secuencia del mismo. No donde en el artículo hablan de archivos de configuración de proyectos individuales.
Espero que ayude.