Why would .NET suddenly try to serialize my object in my ASP.NET application?

问题

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

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.

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;
    }
}

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).

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?

回答1:

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

First, I assume you haven't set up something like sql session management, and the only thing you changed is the user under which IIS is running.

You observe two phenomenon:

Serialization of an object which shouldn't be serialized
Loading of your assembly by an AppDomain which hasn't already loaded it.

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.)

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)

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

One if the IIS service and Runtime are running under the same user, which doesn't require appdomain switching.
another if the IIS service and runtime doesn't share the user they are running under. In this case, the runtime requires it, as the two user doesn't have the same rights.

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.

回答2:

EDIT Re-reading your question, I'm not so sure this is the issue. I'm leaving it here because I spent 5 minutes writing it, and it's useful info :) If you're writing web-apps, you need to know about session state and your storage options!

As Daniel Powell says, it's very likely that you are storing an instance of your object in the session state.

ASP.NET applications have 3 standard modes for storing session state. InProc (in-process) stores it in memory, so no serialization is required. StateServer or SqlServer will attempt to serialize the session state to either an ASP.NET State Server or a SQL server respectively.

To confirm that this is the issue you will need to check what the mode attribute of the sessionState element is in the web.config file.

<sessionState mode="InProc|SqlServer|StateServer" />

If you are using SQL Server or State Server, then your application will be serializing the entire session state at the end of every request. You have a few options here:

Change your session state to InProc. This will prevent the serialization, but you will not be able to use a load-balanced environment. Also, if your application restarts, all users will lose their session (as it is held in memory).
Stop putting this object in the Session. If you don't need to store this object in the Session, then don't! Problem solved.
Make the object, and any child elements of it, serializable, by implementing ISerializable. This will not be possible if the object uses "live" elements such as database connections, etc.