2010-06-01 2 views
3

Je développe un HttpHandler personnalisé, pour ce faire, j'écris une bibliothèque de classes C# et la compile en DLL.Pourquoi cette DLL de bibliothèque de classes n'obtient-elle pas d'informations de app.config?

Dans le cadre de cela, j'ai quelques emplacements de répertoire que je ne veux pas coder en dur dans l'application, donc j'essaie de le mettre dans le app.config que j'ai utilisé auparavant.

Avant cela a fonctionné simplement en allant construire le app.config:

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
    <appSettings> 
    <add key="Share" value="C:\...\"/> 
    </appSettings> 
</configuration> 

Et puis obtenir ce code comme dans:

var shareDirectory = ConfigurationManager.AppSettings["Share"]; 

Mais quand je le compiler et le mettre dans le dossier bin pour le webservice, il continue d'obtenir la valeur null pour shareDirectory, probablement parce qu'il ne trouve pas app.config. Alors, comment est-ce que je m'assure que c'est inclus pour que je n'ai pas à coder en dur mes emplacements de direcotry? Je remarque qu'il sera essentiellement après compilé nous obtenons l'assembly.dll et le assembly.dll.config qui est le fichier app.config, donc il est définitivement là dans le dossier bin!

Répondre

2

Vous êtes probablement confondant la portée de votre bibliothèque de classes. Rappelez-vous, votre config, que ce soit web.config, ou app.config, est la configuration présente dans l'application HEBERGEMENT. Dans ce cas votre application d'hébergement est le WebService, hébergé bien sûr par IIS, donc votre fichier de configuration est le web.config. Si vous aviez une application de console qui utilisait cette bibliothèque de classes (mais probablement pas dans un contexte http), alors la configuration serait app.config dans l'application console, pas dans l'app.config de votre bibliothèque de classes. .

2

Vous devez placer la configuration dans votre fichier web.config, pas dans assembly.dll.config: .NET ne lit pas (par construction) les fichiers assembly.dll.config.

3

C'est parce que votre service web utilise web.config

Questions connexes