0

Similar to This Question, I have an application that relies heavily on in-process session. I'm now trying to move the session store to a local State Server.

I'm getting the error:

Type 'System.Web.UI.Control' in Assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.

The problem is I can't determine which control is trying to be serialized.

The full exception and the stack trace doesn't show me any additional information.

Is there a way to determine what control is trying to be serialized?

Using ASP.net, IIS7, Framework 4.0

Community
  • 1
  • 1
AaronS
  • 7,649
  • 5
  • 30
  • 56
  • Why are controls being serialized and stored in session in the first place? – James Johnson Nov 08 '11 at 18:47
  • Good question. :) It's a legacy application that I've inherited, and I'm updating. One goal is to stop storing them in session altogether. – AaronS Nov 08 '11 at 18:49
  • Have you narrowed it down to a page yet at least? Can you set a breakpoint somewhere to see where it bombs? – James Johnson Nov 08 '11 at 18:50
  • It's basically when the application first loads, after the user has logged in, and everything is initialized. The initialization process is fairly large, so it's not easy to step through every step to see where something may be thrown into session. I may have to do this if there isn't an easier way to find out where the control is added to session. – AaronS Nov 08 '11 at 18:58

1 Answers1

1

Do a global search for Session[ or Session.Item and find everything with the = to the right. That is all the assignments to Session. It can't me more than a few hundred. One of them is a System.Web.UI.Control. It was probably put into session to avoid hitting the database. Rewrite that code to store the DataTable or DataSet or other values instead of storing the Control.

If you don't have the source code, there isn't an easy way to deal with this short of decompiling, fixing the code and recompiling.

Even if you give up on SqlSession, you may still want to stop putting UI controls into Session-- it can cause OutOfMemory problems: http://blogs.msdn.com/b/tess/archive/2008/05/28/asp-net-memory-thou-shalt-not-store-ui-objects-in-cache-or-session-scope.aspx

MatthewMartin
  • 32,326
  • 33
  • 105
  • 164
  • None of them are directly added via session[""] calls. I believe they are hidden somewhere inside a data object, but multiple searches have turned up nothing. The ultimate goal is to make sure none are being added to session at all, once I can determine where they are. – AaronS Nov 08 '11 at 18:34
  • Turn on trace.axd and check the session variable. It will show the key, type and value. Then search for that key in the source code. Again, if you don't have the source code (i.e. if this is 3rd party code or the source code is lost) this won't have a solution. – MatthewMartin Nov 08 '11 at 18:48
  • Good call. While this didn't directly tell me what was causing the issue, it did show me which specific data objects were stored in session. I was able to step through each one of these to determine where the control was getting added. Thanks for the help. – AaronS Nov 08 '11 at 19:24