Fichiers web.config hérités et bogue HttpContext dans WCF?

Question

J'utilise WCF pour créer un service SOAP avec la mise en page de fichier suivant hébergé sur IIS:

/ 
/web.config 
/service 
/service/test.svc 
/service/web.config 

Dans le /web.config, j'ai quelques paramètres généraux (System.CodeDom, etc.) et en /service/web.config J'ai une section appSettings avec quelques paramètres définis.

<?xml version="1.0"?> 
<configuration> 
    <appSettings> 
    <add key="Username" value="user" /> 
    <add key="Password" value="password" /> 
    </appSettings> 

J'ai alors le mot de passe personnalisés validateur:

public class CustomUserNameValidator : UserNamePasswordValidator 
{ 
    public override void Validate(string userName, string password) 
    { 
     string expectedUsername = WebConfigurationManager.AppSettings["Username"]; 
     string expectedPassword = WebConfigurationManager.AppSettings["Password"]; 

     ... snip ... 
    } 
} 

C'est là que ça devient bizarre:

• Sur le premier coup à ce service, expectedUserName et expectedPassword sont nuls
• Sur les hits suivants, ces deux variables contiennent les valeurs du fichier /service/web.config
• Si vous arrivez à la deuxième ou succès ultérieur et il fonctionne en effet comme prévu, un simple redémarrage du serveur web ou recompiler brisera le prochain coup

En fait, ce qu'il est en train de faire est de charger le La section appSettings du fichier /web.config lors de la première occurrence, puis après que WCF ait mis en cache la création des fichiers WSDL/XSD et ainsi de suite, elle utilise /service/web.config.

Cela semble être un bogue et je n'arrive pas à trouver une solution de contournement autre que de placer appSettings dans le fichier /web.config. Peut-être que c'est WCF, au premier coup, ne considérant pas que le répertoire/service soit la racine de l'exécution parce que test.svc n'est pas compilé (ou quel que soit le nom de la cache)? Puis après ce premier hit, considère-t-il ce répertoire dans l'ordre d'héritage web.config? MISE À JOUR: par les commentaires ci-dessous, vous verrez que même HttpContext.Current est null seulement sur le premier hit, mais chaque hit après qu'il n'est pas nul (avec le web.config et l'attribut sur le service pour autoriser le mode de compatibilité ASP.NET). Le web.config ne se charge pas correctement est juste un symptôme d'un plus gros problème, il semble.

Answer 1

Il s'avère qu'il s'agit d'un bogue dans .NET 3.5. J'ai été notifié par Microsoft qui a été corrigé dans .NET 4.0 beta 2 (http://connect.microsoft.com/wcf/feedback/ViewFeedback.aspx?FeedbackID=491844 a des détails)

Answer 2

Il est possible que cela concerne le mode et le moment du chargement des données dans WebConfigurationManager.

MISE À JOUR:

pourrait être lié aux droits. Le premier hit arrive en tant que signet, second en tant qu'authentifié. Par conséquent, deuxième est autorisé à lire des données.

Vous devez vérifier:

• sécurité IIS
• paramètres de sécurité dans web.config
identité
• de pool d'applications
• ACL pour le fichier web.config

MISE À JOUR 2 :

Tourné dans le noir : Lisez-vous le HttpContext trop tôt, quand il n'est pas disponible?Est-ce que votre code est appelé depuis init? Peut-être le déplacer au chargement de la page?