What is the hidden considerations to avoid memory leak in CF2.0 applications

1. Certain constructor overloads for XmlSerializer leaks resources. A dynamic assembly is being created serialize or deserialize the object and you cannot unload the assembly (unless you are using app domains). A better way around this is to cache any serializers that you create for a specific type.

2. If you use Activator.CreateX and adding those objects to a collection (List or Dictionary) then you must clear the collection if you ever new it up again. Items in the collection are not dereferenced because they where created dynamically so the GC never picks them up unless they were specifically removed or the Clear method is called.

Maybe now is a good time to learn how to use a memory profiler like .NET Memory Profiler. You get a 2 week trial to figure it out. Just look for object instances that are growing out of control and investigate the code (you can easily jump to offending areas from the profiler) to see why it is leaking.

Later version of VS come with much better performance monitoring but since your on 2005 you'll have to rely on external tools that have evolved from way back then.

.NET memory leaks are usually very hard to find without the right tools but the two areas I highlighted are the most common pitfalls I've seen. I would also suggest avoiding your own calls to GC.Collect especially when you are testing for the leak. The more you call it the more likely you'll get false positives with what the GC cannot deal with.

Good luck!

Dear brutaldev
Actually I have VS2010 Pro recently, and not used yet ,because  it’s not  supporting WM6.5 as VS2005 & VS2008  , Do you think there is a way to use it to monitor memory leak in windows mobile applications?
Best Regards