views:

200

answers:

2

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.

A: 

It is possible that it is something to do with how and when you load data into your WebConfigurationManager.

UPDATE:

Could be related to rights. First hit comes in as annonymous, second as authenticated. Therefore, second is allowed to read data.

You need to check:

  • IIS security
  • security settings in web.config
  • identity of application pool
  • ACL for web.config file

UPDATE 2:

Shot in the dark: Are you reading the HttpContext too early, when it is not available? Is your code being called from init? Maybe move it to page load?

Shiraz Bhaiji
Well, I'm not doing anything specific (loading it manually). I'm letting the ASP.NET/WCF pipeline load my web.config files automatically and just utilizing the AppSettings property to get my appSettings as normal.I did try loading the web config manually, but it fails just the same on the first hit.
wojo
Good thinking if it was just the web.config. I did check my security settings, and everything looks fine.However, what really gets me is that the HttpContext.Current property is null on the first hit, too. That should have nothing to do with the ACLs/authentication status, etc, right?
wojo
It is available in my service itself, after authentication (but that is too late for me). I tested this by just bypassing my validator and it is indeed available. But this seems like a bug in that it should be available on the first hit in my validator, too. It is available on every subsequent hit, after all!
wojo
A: 

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)

wojo