I am currently involved in a project that uses ASP.NET. The project is on its second implementation. During the first implementation the environment was controlled by the project team and they chose to turn on persistent sessions for the load balancers. This allowed the system to store session data in memory for the application.

Now the project is being rolled out for a new client where the environment is no longer controlled by the team. The client has specified that a central session server must be used so that the load balancers can be used without persistant sessions, as a recommended best practice by the vendor, F5 Networks.

I was tasked to assess the readiness of the product to be placed in this environment. After changing the web.config file to point to the new session server I immediately started seeing problems with pages not loading correctly. The problem was I couldn’t debug the issue because the .Net Framework was doing the work and I didn’t have source code or PDB files for the libraries. I guessed the issue dealt with serialization since objects that cannot be serialized will not go across the wire to the session server. So I took the first page the application hits and placed the following code into the Page_Load event handler (wrapped by a try…catch, of course):

IFormatter formatter = new BinaryFormatter();
using (System.IO.Stream stream = new System.IO.FileStream(
    "C:\\Users\\rudyscot\\desktop\\userstate.bin",
    System.IO.FileMode.Create, System.IO.FileAccess.Write,
    System.IO.FileShare.None))
{
    formatter.Serialize(stream, Session);
    stream.Flush();
    stream.Close();
}

Any issues with the serialization will throw an exception, so I was able to see what the issues were by looking at the Message property of the caught Exception. All of the issues turned out to be what I was expecting. They were all classes not marked with a Serialization attribute. Unfortunately, one of the objects turned out to be a .Net framework object though, so code changes needed to occur to move the needed properties of that control to an object that could be serialized.

Copyright © Scott P. Rudy 2009 All Rights Reserved
Advertisements

I was writing some unit tests the other day and wanted a way to compare an entire object for a test assertion. I also wanted to be able to hand write an object and then use it to compare a result in a test. I immediately thought of XML serialization in .Net and started writing the code.

Unfortunately, it was then that I realized that the XML Serializer has a few limitations. First of all, you must have a default constructor declared for all of your classes. Now I normally use this convention (especially with the C# 3.0 initialization features), but there were several classes I didn’t write in the project I am working on.

The second limitation had to do with properties in a class that were declared as interfaces (e.g. IList<T>). I don’t know why Microsoft didn’t include this as part of the serializer, but it is definitely missing.

I started thinking about WCF and serialization across the wire and realized this problem had to have been solved by the DataContractSerializer or people would be irate. So I created some code to use the DataContractSerializer instead. The code looked like this:

DataContractSerializer oDcs =
new DataContractSerializer(typeof(TypeToBeSerialized));
XmlWriterSettings settings =
new XmlWriterSettings() { Indent = true };
using (XmlWriter w = XmlWriter.Create(fileName, settings))
{
    oDcs.WriteObject(w, list);
}

That worked quite well.

Copyright © Scott P. Rudy 2009 All Rights Reserved