2013-09-30 1 views
0

Comment puis-je utiliser EL pour spécifier les écouteurs de trace et les formateurs pour un seul sous-système (disons, DLL) d'un grand système? J'écris un sous-module d'une très grande application de grande taille (client lourd, pas application web) qui utilise un modèle passerelle/portail pour charger ses différents sous-systèmes. Je voudrais utiliser EL 5.0 (déjà utilisé) pour gérer la configuration de journalisation/traçage, mais seulement pour mon sous-système. Il semble que app.config est converti par VS en foo.dll.config. Puis-je convaincre EL de récupérer les paramètres dans foo.dll.config (au moment de l'exécution) et de les fusionner dans ses données de configuration existantes, en mémoire? (. Pas dans un fichier de configuration fusionné)Comment utiliser la bibliothèque d'entreprise pour spécifier la configuration d'une seule DLL ou sous-système?

(. On dirait, sur la base Enterprise Library Class Library App.Config, il ne peut pas être fait)

Répondre

1

Je ne recommanderais pas d'essayer de fusionner la configuration - il peut peut être gênant. Au lieu de cela, je configurerais votre sous-module pour configurer et utiliser des références privées aux objets de bibliothèque d'entreprise appropriés dont vous avez besoin.

Je suppose que votre module est une bibliothèque de classes avec un app.config. Une fois compilé, il génère un fichier module.dll.config dans le répertoire de sortie. Pour prendre un exemple de journalisation à l'aide d'Enterprise Library 6, je créerais une classe d'assistance pour charger votre propre configuration et conserver une référence au LogWriter de votre module. De cette façon, votre module charge sa propre configuration et n'interfère pas et n'est pas influencé par d'autres configurations dans l'application.

namespace MyModule 
{ 
    public class MyModuleClass 
    { 
     public void DoSomething() 
     { 
      MyModuleLogger.LogWriter.Write("MyModule Test", "General"); 
     } 
    } 

    public static class MyModuleLogger 
    { 
     private static Lazy<LogWriter> logWriter = new Lazy<LogWriter>(() => 
      { 
       FileConfigurationSource configSource = 
        new FileConfigurationSource("MyModule.dll.config"); 
       LogWriterFactory factory = new LogWriterFactory(configSource); 
       return factory.Create(); 
      }); 

     public static LogWriter LogWriter 
     { 
      get { return logWriter.Value; } 
     }    
    } 
} 

J'ai utilisé une classe statique, mais vous pouvez utiliser une variété d'approches qui peuvent correspondre à votre conception (singleton, usine, etc.)

Vous devez vous assurer que votre dll.config le fichier est déployé avec votre assemblage. Vous pouvez également rencontrer des problèmes en cas de problèmes de version avec Enterprise Library (par exemple, vous utilisez la version 6 alors que l'application utilise la version 5.)

+0

Beautiful, thanks. J'avais continué à faire des recherches après avoir posté (criminel à poster sans recherche complète, je sais), et trouvé ceci: http://blogs.msdn.com/b/tomholl/archive/2006/04/02/entlib2externalconfig.aspx . Ce qui m'avait amené à penser que je pourrais vouloir essayer la référence privée à un LogWriter d'une usine initialisée avec une FileConfigurationSource. Merci beaucoup de confirmer que je suis sur la bonne voie. Belle initialisation paresseuse via l'idiome de la fonction lambda! Je n'avais pas vu ça avant. (Nous utilisons EL 5.0.505.0.) – JohnL4

+0

Le même code fonctionnera avec EL 5.0.505.0. –

Questions connexes