I still think that the DefaultAssemblyResolver needs a PurgeCache() method. That would make it actually useful for users of Mono Cecil who only need to load one batch of related assemblies at a time, while allowing for unloading and prevention of memory leaks. Of course, many wouldn't notice their apps leaking, but at least if they did, they'd be able to fix it if they managed to locate the PurgeCache() method.
Then, at least Mono Cecil would be usable as-is without eating up endless memory as it loads new assemblies - after all, that *is* one of the major benefits it has over System.Reflection. That's why I spent 3 weeks converting an app to use it that was previously using Reflection, only to discover that it also provided no method of unloading assemblies without custom coding. Writing a custom resolver wasn't a big deal, but it was very disappointing that it was necessary to avoid leaks. BTW, yes Mono Cecil is a lot faster loading metadata than Reflection, but sadly (and contrary to reports I've seen) it uses a lot more memory than Reflection - for my app, testing across many large test solutions, and loading exactly the same DLLs and types, it generally uses more than twice as much memory. Hopefully, your lowermemuse branch will help to close that gap. It does seem a bit ironic that there's effort going into reducing memory usage while the default behavior of never unloading assemblies goes ignored... I suppose wishing for a DefaultAssemblyResolver that supports multiple instances with a shared cache in order to handle different groups of assemblies is asking too much... or to bring Mono Cecil into the modern world of source code that includes documentation comments so that we can benefit from the wondrous magic known as Intellisense... -- -- mono-cecil
