Question

I’ve inherited an ecommerce ASP.NET (c# code behind) web application. We’ve recently moved servers and it’s proving somewhat troublesome. I have very little experience with IIS server configuration and dealing with large projects like this. Most of the problems have now been fixed, but we’re experiencing problems with a crucial part, as a customer attempts to make a payment.
As the customer confirms payment, the application encounters the following error:

    Unable to serialize the session state. In 'StateServer' and 'SQLServer' mode, ASP.NET
will serialize the session state objects, and as a result non-serializable objects or 
MarshalByRef objects are not permitted. The same restriction applies if similar 
serialization is done by the custom session state store in 'Custom' mode.  

Stack Trace:

[SerializationException: Type 'PayerAuthentication.PayerAuthenticationServicePost' in Assembly 'PayerAuthentication, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' is not marked as serializable.]
   System.Runtime.Serialization.FormatterServices.InternalGetSerializableMembers(RuntimeType type) +7733643
   System.Runtime.Serialization.FormatterServices.GetSerializableMembers(Type type, StreamingContext context) +258
   System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.InitMemberInfo() +111
   System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.InitSerialize(Object obj, ISurrogateSelector surrogateSelector, StreamingContext context, SerObjectInfoInit serObjectInfoInit, IFormatterConverter converter, ObjectWriter objectWriter) +161
   System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.Serialize(Object obj, ISurrogateSelector surrogateSelector, StreamingContext context, SerObjectInfoInit serObjectInfoInit, IFormatterConverter converter, ObjectWriter objectWriter) +51
   System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Serialize(Object graph, Header[] inHeaders, __BinaryWriter serWriter, Boolean fCheck) +410
   System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(Stream serializationStream, Object graph, Header[] headers, Boolean fCheck) +134
   System.Web.Util.AltSerialization.WriteValueToStream(Object value, BinaryWriter writer) +1577

Google search results indicate I should add [Serializable] to the class declaration affected, but this is in a compiled dll to which I do not have the csproj.
The code was working fine on the previous server and I do not believe any changes have been made to the code, only to web.config – what can I do?

The sessionstate section of web.config reads <sessionState mode="StateServer" />

UPDATE1: Using Reflector, I exported the class above, made it serializable, recompiled and replaced the dll. The order process went one step further, wherepon I encountered the same error for another dll-compiled class. Once again I was able to use Reflector to see the code, and then export it, edit and recompile.
Now I have the same error occurring in:

SerializationException: Type 'System.Runtime.Remoting.Messaging.AsyncResult' in Assembly 'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' is not marked as serializable.]

I’m not sure I can do anything about this, as this must be part of the .net system files! Any further ideas?

UPDATE2: Ha, well I’ve subsequently discovered it’s processing the payments correctly, but then throwing the above Unable to serialize the session state error on System.Runtime.Remoting.Messaging.AsyncResult before the user gets receipt of the transaction. Not good. Unsure how to move forward now…

UPDATE3: I tried creating a copy of the System.Runtime.Remoting.Messaging.AsyncResult class, and making it serializable but this is then leading to inconsistent accessibility problems.

using System;
using System.Runtime.InteropServices;
using System.Threading;
using System.Security.Permissions;
using System.Runtime.Remoting.Messaging;

    [Serializable, ComVisible(true)]
    public class myAsyncResult : IAsyncResult, IMessageSink
    {
        // Fields
        private AsyncCallback _acbd;
        private Delegate _asyncDelegate;
        private object _asyncState;
        private ManualResetEvent _AsyncWaitHandle;
        private bool _endInvokeCalled;
        private bool _isCompleted;
        private IMessageCtrl _mc;
        private IMessage _replyMsg;

        // Methods
        internal myAsyncResult(Message m);
        //[SecurityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.Infrastructure)]
        public virtual IMessageCtrl AsyncProcessMessage(IMessage msg, IMessageSink replySink);
        private void FaultInWaitHandle();
        public virtual IMessage GetReplyMessage();
        public virtual void SetMessageCtrl(IMessageCtrl mc);
        //[SecurityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.Infrastructure)]
        public virtual IMessage SyncProcessMessage(IMessage msg);

        // Properties
        public virtual object AsyncDelegate { get; }
        public virtual object AsyncState { get; }
        public virtual WaitHandle AsyncWaitHandle { get; }
        public virtual bool CompletedSynchronously { get; }
        public bool EndInvokeCalled { get; set; }
        public virtual bool IsCompleted { get; }
        public IMessageSink NextSink { [SecurityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.Infrastructure)] get; }
    }

Specifically, that error CS0122: 'System.Runtime.Remoting.Messaging.Message' is inaccessible due to its protection level. I can see this is because Message is an internal class. But surely I can’t change the accessibility level of it as it is part of the System.Runtime namespace. And making a copy and renaming it is going to cuase the same problem again, surely?
Can anyone help me now?

FINAL UPDATE
Looks like, after all this, that it was the SSL certificate (see my answer below)

Answer 1

I now believe that this problem arose when we installed a new SSL certificate.

The new certificate had Postcode extensions which our payment merchant HSBC doesn’t accept over it’s CPI payment gateway.

Getting the correct SSL certificate installed seems to have finally solved this problem.