Search

XmlSerializer memory leak by Erand

Closed
as By Design Help for as By Design

4
0
Sign in
to vote
Type: Bug
ID: 98384
Opened: 10/13/2004 6:48:29 AM
Access Restriction: Public
1
Workaround(s)
2
User(s) can reproduce this bug
I've been experiencing some problems working with the
XmlSerializer class (from .net framework v2.0).

It appears that when using XmlSeializer to serialize a
class XmlSerializer will create a dynamic assembly on the
fly containing the serialization code.

The problem is that this assembly is never collected by
the GC since assebmlies cannot be unloaded once they have
been loaded in memory.

Looking at the code (using reflector) you can see that
XmlSerializer maintains a cache of temp assemblies in
order to speed up performance and save some memory space.

This is acceptable only that unfortunately only some
constructors use this cache, other constructors choose
from unobvious reason to bypass this mechanism.

Specifically the constructor that accepts a Type and a
string parameter uses this mechnism.
The constructor that accepts 7 parameters bypasses this
mechnism.
Details (expand)
Product Language
English
Version
Visual Studio 2005 Beta 1
Category
XML
Subcategory
 
Operating System
Windows XP Professional
Steps to Reproduce
Call the XmlSerializer with any constructor other than the one accepting Type parameter or the one accepting Type and String parameters.
Actual Results
Dynamic assembly created each time one uses an instace of XmlSerializer although an internal caching mechanism may improve performance and memory consumption.
Expected Results
XmlSerializer to use the caching mechanism in every constructor.
File Attachments
0 attachments
Sign in to post a comment.
Posted by Microsoft on 10/18/2004 at 3:30 PM
Thanks for the feedback. This is by design. The serialization code generated by the 7 parameter constructor differs based on each of the values passed in. Caching and retrieving all of the various potential arguments passed to this constructor would be quite complicated. The XmlSerializer, therefore, focuses on the most common constructor usage scenarios for caching and it is recommended that applications using the other constructors cache the serializer returned for re-use.

Thanks.

Matt Tavis
Program Manager
Microsoft Corporation
Posted by Microsoft on 10/13/2004 at 10:07 AM
Thank you for submitting this issue. You should hear back shortly with specific comments.

Ford McKinstry
XmlMessaging Team
Sign in to post a workaround.
Posted by Erand on 1/9/2005 at 7:14 PM
The upcoming 1.0 release of the Mvp.Xml project features an XmlSerializerCache class to help working aroung this issue. You can download it from http://www.mvpxml.org

Obtain XmlSerializer instances using the various overloads of XmlSerializerCache.GetSerializer() instead of the instantiating a serializer instance with the XmlSerializer constructor.

XmlSerializer ser = XmlSerializerCache.GetSerializer( typeof( MyClass ), "http://www.mvpxml.org/mytool" );

The Get Serializer method checks its internal cache for any instances that are compatible with the method parameters before constructing a new instance.