Les redirections de liaison dans app.config pour les bibliothèques de classes font-elles quelque chose?
Les solutions VS avec lesquelles je travaille souvent consistent en un projet unique exécutable (application console, application Web) et plusieurs projets de bibliothèque de classes qui sont tous référencés par l'exécutable.
Lors de l'utilisation de NuGet et de l'installation de packages, un fichier app.config est créé pour chaque projet. Il ne contient généralement rien d'autre qu'une liste de redirections de liaisons qui consolident les versions des assemblys référencés. Parfois, il existe un contenu spécifique à une bibliothèque tierce (comme la section de configuration d'Entity Framework), mais laissons cela de côté pour le moment.
Lorsque je crée la solution et utilise les fichiers binaires du projet exécutable principal, tous les assemblages de projet de la bibliothèque de classes de la sortie de génération sont affichés avec les fichiers *.config correspondants (le fichier app.config est renommé en AssemblyName.config lors de la construction).
Lors du lancement de l'exécutable principal, les fichiers de configuration des assemblys de bibliothèques de classes ont-ils un effet quelconque? Ou est-ce simplement le fichier app.config de l'exécutable qui a un effet dans ce cas? Que se passe-t-il si des redirections de liaison sont configurées sur certains projets de bibliothèque de classes et différentes redirections de liaison sur le projet exécutable principal? Comment sont-elles combinées, lesquelles sont prioritaires?
J'ai essayé de rechercher cela en ligne et d'après ce que j'ai lu, il me semble que les fichiers app.config pour les assemblys non exécutables sont inutiles (en ce qui concerne les redirections de liaison). Quelqu'un peut-il confirmer ceci ou développer un peu plus sur le sujet?
Si tel est le cas, est-il vraiment indésirable que ces fichiers app.config soient créés par NuGet dans les bibliothèques de classes s'ils ne contiennent que les redirections de liaison? Il me semble que NuGet ne devrait pas créer ces redirections de liaisons pour les projets de bibliothèques de classes, car cela ne ferait qu'accroître la confusion quant aux paramètres réellement appliqués.
J'ai trouvé ces questions Stover Overflow existantes sur le sujet, mais leurs les réponses acceptées sont en réalité contradictoires, même lorsqu'elles sont marquées comme des doublons.
La réponse acceptée à la première question indique que les fichiers app.config sont réellement utilisés pendant la compilation, ce qui signifie qu'ils pourraient avoir un effet. Des sources telles que MSDN et le code source de MSBuild sont citées ici comme une preuve de son utilisation lors de la compilation. Malheureusement, je ne maîtrise pas suffisamment MSBuild pour comprendre comment il est utilisé et si c'est vraiment un argument valable.
Quelqu'un peut-il décrire un exemple de scénario pour prouver qu'un app.config avec des redirections de liaison pour une bibliothèque de classes peut faire quelque chose?
J'ai plusieurs applications avec une configuration similaire - application Web référençant plusieurs projets de bibliothèque ayant chacun leur propre paquet de pépites, etc., en fonction de mon expérience personnelle, les liaisons Assembly dans les projets de bibliothèque ne sont pas prises en compte lors de l'exécution.
Les liaisons spécifiées Web ou application config dans l’application racine (Web/console) sont importantes. Tous mes projets de bibliothèque sont configurés avec le paramètre "Copier dans le répertoire de sortie" comme "Ne pas copier" pour le fichier app.config. Ainsi, mon dossier de sortie n'est pas encombré de dll et de leurs fichiers de configuration.
Voici le lien qui indique comment l’Assemblée est chargée, où elle est recherchée et sa séquence. Aucun article dans l'article ne parle de fichiers de configuration de projet individuels.
J'espère que cela pourra aider.
Selon ce vieil article msdn :
Un fichier de configuration d'application est un fichier XML utilisé pour contrôler la liaison à un assemblage. Il peut rediriger une application en utilisant une version d'un assemblage côte à côte vers une autre version du même assemblage. Ceci est appelé configuration par application. Un fichier de configuration d'application ne s'applique qu'à un manifeste d'application spécifique et aux assemblys dépendants. Les composants isolés compilés avec un manifeste [ISOLATIONAWARE_MANIFEST_RESOURCE_ID] incorporé nécessitent un fichier de configuration de l'application distinct. Les manifestes gérés avec CreateActCtx nécessitent un fichier de configuration d'application distinct.
Ainsi, seules les DLL avec l'ensemble ISOLATIONAWARE_MANIFEST_RESOURCE_ID utilisent une configuration d'application indépendante, sinon, elles sont reportées au fichier de configuration du processus principal.
Pour plus d'informations sur ISOLATIONAWARE, vous pouvez lire cet article un autre article MSDN qui va plus en profondeur.
ISOLATIONAWARE_MANIFEST_RESOURCE_ID est principalement utilisé pour les DLL. Il devrait être utilisé si la dll veut des dépendances privées autres que le processus par défaut. Par exemple, si une dll dépend de comctl32.dll version 6.0.0.0. Il doit avoir une ressource de type RT_MANIFEST, ID ISOLATIONAWARE_MANIFEST_RESOURCE_ID dépend de la version de comctl32.dll 6.0.0.0, de sorte que même si l'exécutable du processus veut la version 5.1 de comctl32.dll, la DLL elle-même utilisera toujours la bonne version de comctl32.dll.
Non, seul le app.config de l'exécutable aura un effet. Par exemple, si vous avez une application console hébergeant un service WCF et que vous utilisez dans votre service WCF, par exemple, ConfigurationManager.AppSettings, les AppSettings proviendront du fichier hôte app.config de la console. Si vous lancez une autre application console (ConsoleClient) pour essayer de vous connecter à ConsoleHost, dans les parties où l'on peut dire que ConsoleClient est "en cours d'exécution" (par exemple dans sa méthode principale), il utilisera le app.config de ConsoleClient, mais dès que au moment où il commence à utiliser le service WCF, le service WCF déléguera l’utilisation du app.config de ConsoleHost. (Notez que ce dernier point est plus pertinent pour les détails derrière WCF cependant.)
Généralement, il n’existe qu’un seul fichier de configuration et c’est le fichier de configuration de l’exécutable (.exe.config, web.config).
Toute redirection d'assemblage doit être placée dans le fichier de configuration de l'exécutable.
Les fichiers de configuration des dll doivent être chargés manuellement à l'aide de la classe ConfigurationManager. Voir aussi cette question Équivalent de 'app.config' pour une bibliothèque (DLL)