Ok, hint is given in the title, but here is the code for you to observe and tell before you go any further what kind exactly of memory leak its causing and why :).
Previous debugging points into classic assembly heap loader leak with XmlSerializer temp assemblies (here is the example for how to debug from Tess: http://blogs.msdn.com/b/tess/archive/2006/02/15/532804.aspx)
It is obvious that there should be XmlSerializer somewhere inside. Road to finding it starts with how the TypedMessageConverter is created:
I’ll cut the story saying that inside that routes to creation of SerializerGenerationContext to instantiate the required serializers:
This “pre-cached” set of serializers is then used:
And just to complete the cycle of information, here is the inners of the XmlSerializer to return serializers from mappings:
So, now we can quite easily say what would be the problem of implementation on the top. Unmercifully, it leads to generating temp assemblies for the types in question every time it is called. Code snippets provided are to confirm and understand when/why that would happen or not.
So solution will be to “cache” the instance of TypedMessageConverter per type required, same as a usual solution when using XmlSerializer itself with “non-caching” constructors.