Il n'est pas anodin de créer un fichier de configuration .NET pour un .DLL, et pour une bonne raison. Le mécanisme de configuration .NET contient de nombreuses fonctionnalités intégrées pour faciliter la mise à niveau / mise à jour facile de l'application et pour protéger les applications installées contre le piétinement des fichiers de configuration les uns des autres.
Il existe une grande différence entre la façon dont une DLL est utilisée et la façon dont une application est utilisée. Il est peu probable que plusieurs copies d'une application soient installées sur la même machine pour le même utilisateur. Mais vous pouvez très bien avoir 100 applications ou bibliothèques différentes utilisant toutes des DLL .NET.
Alors qu'il est rarement nécessaire de suivre les paramètres séparément pour différentes copies d'une application dans un profil utilisateur, il est très peu probable que vous souhaitiez que toutes les différentes utilisations d'une DLL partagent la configuration entre elles. Pour cette raison, lorsque vous récupérez un objet Configuration à l'aide de la méthode "normale", l'objet que vous récupérez est lié à la configuration du domaine d'application dans lequel vous exécutez, plutôt qu'à l'assembly particulier.
Le domaine d'application est lié à l'assembly racine qui a chargé l'assembly dans lequel se trouve réellement votre code. Dans la plupart des cas, il s'agira de l'assembly de votre .EXE principal, qui a chargé le .DLL. Il est possible de faire tourner d'autres domaines d'application dans une application, mais vous devez explicitement fournir des informations sur l'assembly racine de ce domaine d'application.
À cause de tout cela, la procédure de création d'un fichier de configuration spécifique à la bibliothèque n'est pas si pratique. C'est le même processus que vous utiliseriez pour créer un fichier de configuration portable arbitraire non lié à un assembly particulier, mais pour lequel vous souhaitez utiliser le schéma XML, la section de configuration et les mécanismes d'élément de configuration de .NET, etc. Cela implique la création d'un ExeConfigurationFileMap
objet , chargement des données pour identifier où le fichier de configuration sera stocké, puis appel ConfigurationManager
. OpenMappedExeConfiguration
pour l'ouvrir dans une nouvelle Configuration
instance. Ce va vous couper de la protection de la version offerte par le mécanisme de génération de chemin automatique.
Statistiquement parlant, vous utilisez probablement cette bibliothèque dans un cadre interne, et il est peu probable que plusieurs applications l'utilisent sur une seule machine / utilisateur. Mais sinon, il y a quelque chose que vous devez garder à l'esprit. Si vous utilisez un seul fichier de configuration global pour votre DLL, quelle que soit l'application qui la référence, vous devez vous soucier des conflits d'accès. Si deux applications référençant votre bibliothèque s'exécutent en même temps, chacune avec leur propreConfiguration
objet ouvert, alors quand on enregistre les modifications, cela provoquera une exception la prochaine fois que vous essayez de récupérer ou d'enregistrer des données dans l'autre application.
Le moyen le plus sûr et le plus simple de contourner ce problème est d'exiger que l'assembly qui charge votre DLL fournisse également des informations sur lui-même, ou de le détecter en examinant le domaine d'application de l'assembly de référence. Utilisez-le pour créer une sorte de structure de dossiers pour conserver des fichiers de configuration utilisateur distincts pour chaque application référençant votre DLL.
Si vous êtes certain de vouloir disposer de paramètres globaux pour votre DLL, quel que soit l'endroit où elle est référencée, vous devrez déterminer votre emplacement pour celle-ci plutôt que .NET pour en trouver automatiquement une appropriée. Vous devrez également être agressif dans la gestion de l'accès au fichier. Vous aurez besoin de mettre en cache autant que possible, en gardant l' Configuration
instance UNIQUEMENT le temps nécessaire pour charger ou enregistrer, ouvrir immédiatement avant et éliminer immédiatement après. Et enfin, vous aurez besoin d'un mécanisme de verrouillage pour protéger le fichier pendant qu'il est modifié par l'une des applications qui utilisent la bibliothèque.