.net WCF中继承的web.config文件和HttpContext错误？

我正在使用WCF创建一个SOAP服务，该服务在IIS上承载以下文件布局：

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

在/web.config中，我有一些常规设置（system.codedom等），在/service/web.config中，我有一个appSettings部分，其中定义了一些设置

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

这就是它变得奇怪的地方：

• 第一次点击此服务时，expectedUserName和expectedPassword为空
• 在第二次和后续的点击中，这两个变量包含/service/web.config文件中的值
• 如果您遇到了第二次或后续的命中，并且它确实按照预期工作，那么只需重新启动web服务器或重新编译即可中断下一次命中

事实上，它实际上是在第一次点击时从/web.config加载appSettings部分，然后在WCF缓存了WSDL/XSD等的创建之后，它使用/service/web.config

这似乎是一个bug，除了将appSettings放入/web.config文件之外，我似乎找不到其他解决方法

也许是WCF，在第一次命中时，没有考虑将/service目录作为执行的根目录，因为test.svc尚未编译（或调用它所做的任何缓存），是吗？然后，在第一次命中之后，它会考虑Web.CONFIG继承排序中的目录吗？< /P>

---

更新：根据下面的注释，您将看到，即使HttpContext.Current仅在第一次命中时为null，但此后的每次命中都不是null（服务上有适当的web.config和属性以允许ASP.NET兼容模式）。web.config加载不正确似乎只是一个更大问题的症状。

这可能与如何以及何时将数据加载到WebConfiguration Manager有关

更新：

可能与权利有关。第一支安打是匿名的，第二支是经过认证的。因此，允许第二个用户读取数据

您需要检查：

• IIS安全
• web.config中的安全设置
• 应用程序池的标识
• web.config文件的ACL

更新2：

---

在黑暗中拍摄：您阅读HttpContext是否太早，而它不可用？您的代码是从init调用的吗？可能会将其移动到页面加载？

这可能与如何以及何时将数据加载到WebConfiguration Manager有关

更新：

可能与权利有关。第一支安打是匿名的，第二支是经过认证的。因此，允许第二个用户读取数据

您需要检查：

• IIS安全
• web.config中的安全设置
• 应用程序池的标识
• web.config文件的ACL

更新2：

---

在黑暗中拍摄：您阅读HttpContext是否太早，而它不可用？您的代码是从init调用的吗？也许将其移动到页面加载？

这是.NET3.5中的一个错误。微软通知我，它已经在.NET4.0Beta2中修复了（有详细信息）

这是.NET3.5中的一个bug。微软通知我，它已在.NET 4.0 beta 2中修复（有详细信息）

配置管理器也会出现这种情况。这越来越奇怪了。我正在调试HttpContext.Current（查看一些配置文件路径的私有字段等），第一次点击时它总是空的。之后，HttpContext.Current可用。顺便说一句，这是利用服务上的属性和属性来访问HttpContext的。请参见MS Connect错误：ConfigurationManager也会出现这种情况。这变得很奇怪。我正在调试HttpContext.Current（查看一些配置文件路径的私有字段等），第一次点击时它总是空的。之后，HttpContext.Current可用。顺便说一句，这是利用服务上的属性和属性来访问HttpContext的。请看MS Connect错误：我没有做任何特定的事情（手动加载）。我让ASP.NET/WCF管道自动加载我的web.config文件，并利用AppSettings属性正常获取我的AppSettings。我确实尝试过手动加载web配置，但第一次点击时同样失败。如果只是web.config，那就好了。我检查了我的安全设置，一切看起来都很好。然而，真正吸引我的是HttpContext.Current属性在第一次命中时也是空的。这应该与ACL/身份验证状态等无关，对吗？在身份验证之后，它在我的服务本身中可用（但对我来说太晚了）。我通过绕过我的验证器来测试它，它确实是可用的。但这似乎是一个bug，因为它也应该在我的验证器第一次命中时就可用。毕竟，它在以后的每一次点击中都是可用的！嗯，我没有做任何具体的事情（手动加载）。我让ASP.NET/WCF管道自动加载我的web.config文件，并利用AppSettings属性正常获取我的AppSettings。我确实尝试过手动加载web配置，但第一次点击时同样失败。如果只是web.config，那就好了。我检查了我的安全设置，一切看起来都很好。然而，真正吸引我的是HttpContext.Current属性在第一次命中时也是空的。这应该与ACL/身份验证状态等无关，对吗？在身份验证之后，它在我的服务本身中可用（但对我来说太晚了）。我通过绕过我的验证器来测试它，它确实是可用的。但这似乎是一个bug，因为它也应该在我的验证器第一次命中时就可用。毕竟，它在以后的每一次点击中都是可用的！

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

        ... snip ...
    }
}