It seems when I enable the <serviceHostingEnvironment aspNetCompatibilityEnabled="true" /> setting in system.serviceModel and decorate my service with the AspNetCompatibilityRequirements attribute, something is not happening correctly in the IIS ASP.NET/WCF pipeline to set up HttpContext.Current and my ConfigurationManager correctly.

On the first hit (or after recyclying the application pool), HttpContext.Current is always null in my UserNamePasswordValidator. My web.config appSettings values are also not loaded from my path (~/service/test.svc contains a ~/service/web.config that contains the values I need).

On every subsequent hit, HttpContext.Current is valid and my (Web)ConfigurationManager.AppSettings contains the correct values from my ~/service/web.config as expected.

The two stack traces of trying to access HttpContext.Current from my validator are located at http://img12.imageshack.us/gal.php?g=capturezk.png which I also attached to this report.

See my post on http://stackoverflow.com/questions/1468924/inherited-web-config-files-and-httpcontext-bug-in-wcf as well, which may have some updates from other users as time goes on.

This is a pretty serious issue as we expect HttpContext.Current to be available. The AppSettings can be moved into the global web.config, but there is no workaround for the HttpContext issue.