Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

Memory Footprint

I'm working on a project that integrates with Office and the Windows shell. Right now we have add-ins for Excel, PowerPoint, Word and Outlook, and a couple of shell extensions for Windows Explorer, all written in C++.

We're at a point where we want to overhaul some of this stuff, so we're considering whether to use C# instead of C++. There are lots of huge advantages to C#, but we're concerned about the memory footprint of the CLR.

As I understand it, we'd have a separate CLR for each process, meaning someone using multiple Office applications simultaneously could be hit pretty hard memory-wise with all those managed add-ins.

Is this an accurate view? Is there anything we can do to alleviate the problem?

Eric Smith
Tuesday, November 30, 2004

No. The .NET virtual machine is a set of dynamic link libraries; they're shared across processes, so unlike Java you will have one .NET VM floating around with a bunch of different applications poking and prodding at the parts they want.

Unless you make heavy use of the 'static' keyword there'll be an instance of your plugin-in for every instance of Office running, though.

Arron Washington
Tuesday, November 30, 2004

I would avoid writing a managed plugin for an environment that is expecting just an (inprocess) COM object.

There are a number of issues relating to firing up the CLR in a process that may not be properly handled if some arbitrary plugin tries to load up managed code.  For example, AppDomain managment - what happens if your plugin is ever unloaded?  The CLR doesn't support being shutdown and restarted in a process.

I have some vague recollection of support for managed extensions to office via an SDK, but I don't know if they would address the extensibility points you are using.

I don't believe any such thing exists for shell extensions in the current OS.

Rob Walker
Wednesday, December 01, 2004

*  Recent Topics

*  Fog Creek Home