2010-08-25 6 views
1

Nous avons une solution Visual Studio 2010 qui contient plusieurs projets C# conformément au modèle Onion Architecture de Jeffery Palermo (http://jeffreypalermo.com/blog/the-onion-architecture-part-1/). Nous avons un projet d'interface utilisateur qui est un projet ASP.Net MVC, et nous avons un projet de bibliothèque de classes C# appelé Infrastructure qui est référencé par le projet d'interface utilisateur. Dans notre projet Infrastructure, nous avons ajouté un fichier app.config pour contenir les paramètres spécifiques au projet Infrastructure. Lors de l'exécution, le fichier app.config ne semble pas être disponible pour le projet Infrastructure, uniquement le fichier web.config contenu dans le projet d'interface utilisateur. Nous ne voulons pas mettre les paramètres relatifs au projet Infrastructure dans le fichier web.config du projet d'interface utilisateur, l'interface utilisateur n'a pas besoin de ces paramètres. Comment pouvons-nous rendre le fichier app.config de l'infrastructure disponible lors de l'exécution? Nous pensions peut-être que nous devrions mettre une Post Build Copy pour copier le fichier app.config dans le répertoire de l'interface utilisateur lorsque l'application est créée - est-ce la bonne façon de procéder, ou existe-t-il un meilleur moyen?Fichier app.config Visual C# pour un assembly référencé

Répondre

2

Même si vous copiez l'application.config après la construction, cela ne résoudra pas votre problème. L'application étant toujours une application Web, le système de configuration utilisera le fichier web.config. Les paramètres devront y aller d'une manière ou d'une autre. Une façon de garder ces paramètres un peu séparés consiste à les placer dans une section de configuration personnalisée, puis à placer les paramètres de cette section dans un fichier distinct. Il faudra quand même qu'il soit référencé depuis le web.config (en utilisant un attribut configSource).

6

Généralement, on vous dit que cela ne peut pas être fait. Cependant, vous pouvez certainement charger un fichier de configuration en utilisant la méthode System.Configuration.ConfigurationManager.OpenExeConfiguration. Vous pouvez passer le chemin du fichier à votre assembly (il ne doit pas être un exécutable, malgré le nom de la méthode). Accordé, ceci ne fusionne pas les paramètres de configuration de votre assembly dans les paramètres de configuration de l'application en cours d'exécution, et je ne pense pas que ce soit le cas. Votre assembly doit simplement savoir qu'il doit récupérer ses paramètres via un mécanisme différent de la fonction System.Configuration.ConfigurationManager.GetSection ou de la propriété statique AppSettings de cette classe. Voici un exemple très simple pour une classe "Settings" qui charge un fichier .config pour l'assemblage dont elle fait partie. Maintenant, vous aurez encore

public static class Settings 
{ 
    public static System.Configuration.Configuration Configuration { get; private set; } 

    static Settings() 
    { 
     // load a .config file for this assembly 
     var assembly = typeof(Settings).Assembly; 
     Configuration = System.Configuration.ConfigurationManager.OpenExeConfiguration(assembly.Location); 

     if (Configuration == null) 
      throw new System.Configuration.ConfigurationErrorsException(string.Format("Unable to load application configuration file for the assembly {0} at location {1}.", assembly.FullName, assembly.Location)); 
    } 

    // This function is only provided to simplify access to appSettings in the config file, similar to the static System.Configuration.ConfigurationManager.AppSettings property 
    public static string GetAppSettingValue(string key) 
    { 
     // attempt to retrieve an appSetting value from this assembly's config file 
     var setting = Configuration.AppSettings.Settings[key]; 
     if (setting != null) 
      return setting.Value; 
     else 
      return null; 
    } 
} 

Et l'utilisation ...

public class UsageExample 
{ 
    void Usage() 
    { 
     string mySetting = Settings.GetAppSettingValue("MySetting"); 

     var section = Settings.Configuration.GetSection("MySection"); 
    } 
} 

pour régler les questions de construction. L'ajout d'un élément "Application Configuration File" (App.config) à votre assembly de bibliothèque de classes entraîne Visual Studio pour le copier dans le dossier de sortie de l'assembly en tant que .dll.config, mais il n'est pas automatiquement copié dans le dossier de sortie des applications exécutables cette référence ce projet. Par conséquent, vous devez ajouter une étape de post-construction pour copier le fichier à l'emplacement approprié, comme vous l'avez mentionné. Je considérerais une étape post-construction sur la bibliothèque de classes qui copie le fichier .config dans un dossier "Configurations" au niveau de la solution, puis une étape post-construction pour les projets exécutables pour copier tout depuis le Dossier "Configurations" dans le dossier de sortie. Je ne suis pas sûr que cela fonctionnerait bien, mais si c'est le cas, vous ne créeriez pas de dépendances supplémentaires entre les projets dans vos étapes de post-construction (cela pourrait rendre la maintenance difficile).

EDIT: En fin de compte, vous devriez considérer si c'est vraiment ce que vous voulez faire. Ce n'est pas l'approche normale, et généralement vous pourriez être mieux servi en utilisant l'autre réponse à cette question qui mentionne l'utilisation de l'attribut configSource.Les inconvénients de cette approche qui peuvent ne pas être évidents sont que vous ne pourrez pas mettre les paramètres des composants tiers dans le fichier de configuration de votre bibliothèque de classes et attendez qu'ils soient utilisés. Par exemple, si votre bibliothèque de classes utilise log4net, vous ne pouvez pas mettre les paramètres de log4net dans le fichier de configuration de votre bibliothèque de classes, car les composants log4net s'attendent toujours à charger les paramètres du fichier de configuration de l'exécutable.