Question

I’m using WCF to create a SOAP service with the following file layout hosted on IIS:

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

In the /web.config, I have a few general settings (system.codedom, etc) and in the /service/web.config I have an appSettings section with a few settings defined.

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

I then have custom password validator:

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

        ... snip ...
    }
}

This is where it gets weird:

• On the first hit to this service, expectedUserName and expectedPassword are null
• On the second and subsequent hits, these two variables contain the values from the /service/web.config file
• If you get to the second or subsequent hit and it is indeed working as expected, a simple restart of the web server or recompile will break the next hit

In fact, what it is actually doing is loading the appSettings section from the /web.config on the first hit, and then after WCF has cached the creation of the WSDL/XSDs and such, it uses /service/web.config.

This seems like a bug and I can’t seem to find a workaround other than placing the appSettings into the /web.config file.

Perhaps it’s WCF, on the first hit, not considering the /service directory to be the root of the execution because test.svc isn’t compiled (or whatever the caching it does is called), yet? Then after that first hit, it does consider that directory in the web.config inheritance ordering?

UPDATE: per the comments below, you’ll see that even HttpContext.Current is null only on the first hit, but every hit after that it isn’t null (with the proper web.config and attribute on the service to allow for ASP.NET compatibility mode). The web.config not loading properly is just a symptom of a larger problem, it seems.

Answer 1

Turns out this is a bug in .NET 3.5. I’ve been notified by Microsoft that is has been fixed in .NET 4.0 beta 2 (http://connect.microsoft.com/wcf/feedback/ViewFeedback.aspx?FeedbackID=491844 has details)