我运行在完整的IIS模式下的Azure Web角色。请求被授权使用自定义的基本身份验证。

I run an Azure web role in Full IIS mode. Requests are authorized with custom basic authentication.

我有 MyAssembly.CustomIdentity 类，它继承 System.Security.Principal.GenericIdentity 。当 HttpApplication.AuthenticateRequest 处理程序（的OnEnter（） $ C $从上面的链接三）被调用它进行检查，然后创建 MyIdentity.CustomIdentity 的实例，并将其分配给 HttpContext.Current.User 。然后实际的ASP.NET请求处理程序获取该对象，并可以用它来寻找它是什么用户。

I have MyAssembly.CustomIdentity class that inherits from System.Security.Principal.GenericIdentity. When HttpApplication.AuthenticateRequest handler (OnEnter() code from the link above) is invoked it performs checks, then creates an instance of MyIdentity.CustomIdentity and assigns it to HttpContext.Current.User. Then an actual ASP.NET request handler obtains that object and can use it to find what user it is for.

在IIS下网​​络服务运行帐户现在一切都或多或少地正常工作在默认配置。在角色启动我重新启动本地用户下的IIS应用程序池（授予它额外的特权）。现在，即使下面的code

Now everything more or less works fine in default configuration when IIS is running under NETWORK SERVICE account. During role startup I restart IIS application pool under a local user (to grant it extra privileges). Now even the following code

public partial class Default : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        bool isAvailable = Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.IsAvailable;
    }
}

会抛出各种异常。首先，它说，它无法序列化我的 CustomIdentity 类（这是我加入序列化属性修正），那么它说它不能加载 MyAssembly程序组件（这些是我处理修复 AppDomain.AssemblyResolve 事件）。

will throw various exceptions. First it says it can't serialize my CustomIdentity class (which I fix by adding Serializable attribute), then it says it can't load MyAssembly assembly (which I fix by handling AppDomain.AssemblyResolve event).

我不明白的是，为什么系列化踢？为什么运行本地用户在S中的应用程序池，并调用了琐碎code突然触发序列化？

What I don't get is why serialization kicks in? Why running the application pool under s local user and invoking that trivial code suddenly trigger serialization?

推荐答案

要小心这个答案，因为我没有绝对的把握这是很好的一个。

Be cautious with this answer, as I am not absolutely sure it is the good one.

首先，我假设你没有设置类似SQL会话管理，而你唯一改变的是在其下运行IIS用户。

您观察到两种现象：

随着AppDomain中已经加载的组件，它似乎是安全的假设，异常是由另一个AppDomain中抛出。如果它被另一个AppDomain中抛出，这可能是因为该AppDomain中试图反序列化的自定义对象。 （它已系列化的其他异常表明之前。）

As your appdomain has already loaded the assembly, it seems safe to assume that the exception is thrown by another AppDomain. If it is thrown by another Appdomain, it's probably because this AppDomain is attempting to deserialize your custom object. (It has been serialized before the other exception demonstrates that.)

确定。现在，即使IIS是本地用户下运行，角色ENVIRONNEMENT不是。该服务与Azure的OS安装，你可以不选择下运行的用户（你很可能在事实，但我不会）

OK. Now even if IIS is running under a local user, Role environnement isn't. This service is installed with the Azure OS, you can't choose the user it runs under (you could probably in fact, but I wouldn't)

我觉得，为了得到RoleEnvironnement信息，在Azure运行时能够使用两个code路径：

What I think is that in order to get informations from RoleEnvironnement, the Azure runtime is able to use two code paths:

最后，我当然不知道为什么在Azure运行时想移动不同的AppDomain之间的用户，但它可能是做这一点。

To conclude, I certainly don't know why the Azure runtime would like to move your user between different AppDomain, but it is probably doing exactly that.