"A complete guide to avoid memory leaks and unwanted caching in Office"
You may wonder why one should worry about memory management in C# (or any .NET application); the mighty Garbage Collector (GC) built into Common Language Runtime (CLR) should spare us from messing around memory management till the end of time (this is one of the reasons why we chose .NET and why we make fun of C/C++ developers, right ?). Well Garbage Collector may serve us well as long as we are inside our "managed world", but as soon as your code make calls to COM (which is exactly what you have to do if you want to work with Outlook or any other Office application) Garbage Collector won't always save you. I'm not saying GC will not do its job (it eventually will), but the problem is that you cannot tell when it will happen, i.e. when the GC will free unused objects and their COM references. In this article I'd like to illustrate using an example of Outlook automation that this may sometimes be a problem.