The Visual Studio Blog makes great reading for .NET developers, and not only because of the product it describes. Visual Studio 2010 is one of the few Microsoft products that has made a transition from native C++ code to .NET managed code – the transition is partial, in that parts of Visual Studio remain in native code, but this is true of the shell and the editor, two of the core components. Visual Studio is also a complex application, and one that is extensible by third parties. Overall the development team stressed the .NET platform, which is good for the rest of us because the developers are in a strong position both to understand problems, and to get them fixed even if it means changes to the .NET Framework.

Two recent posts interested me. One is Marshal.ReleaseComObject Considered Dangerous. I have some familiarity with this obscure-sounding topic, thanks to work on embedding Internet Explorer components. It relates to a fundamental feature of .NET: the ability to interact with the older COM component model, which is still widely used. In fact, Microsoft still uses COM for new Windows 7 APIs; but I digress. A strong feature of .NET from its first release is that it can easily consume COM objects, and also expose .NET objects to COM.

The .NET platform manages memory using garbage collection, where the runtime detects objects that are no longer referenced by active code and deletes them. COM on the other hand uses reference counting, maintaining a count of the number of references to an object and deleting the object when it reaches zero.

Visual Studio 2008 and earlier has lots of COM APIs. Some of these were called from .NET code, and for the same of efficiency called the method mentioned above, Marshal.ReleaseComObject, to reduce the reference count immediately so that the COM object would be deleted.

Now here comes Visual Studio 2010, and some of those COM APIs are re-implemented as .NET code. For compatibility with existing code, the new .NET code is also exposed as a COM API. Some of that existing code is actually .NET code which wraps the COM API as .NET code. Yes, we have .NET to COM to .NET, a double wrapper. Everything still works though, until you call Marshal.ReleaseComObject on the doubly-wrapped object. At this point the .NET runtime throws up its hands and says it cannot decrement the reference count, because it isn’t really a COM object. Oops.

The post goes on to observe that Marshal.ReleaseComObject is dangerous in any cause, because it leaves you with an invalid .NET wrapper. This means you should only call it when the .NET instance is definitely not going to be used again. Obvious, really.

Once you’ve digested that, try this illuminating post on WPF in Visual Studio 2010 – Part 2 : Performance tuning. WPF, or Windows Presentation Foundation, is the .NET API for rich graphical user interfaces on desktop Windows applications. Here is an example of why you should read the post, if you work with WPF. Many of us frequently use Remote Desktop to run applications on remote PCs or PCs that do not have a screen and keyboard attached. This is really a bad scenario for WPF, which is designed to take advantage of local accelerated graphics. Here’s the key statement:

Over a remote desktop connection, all WPF content is rendered as a bitmap. This is in contrast to GDI rendering, where primitives such as rectangles and text are sent over the wire for reconstruction on the client.

It’s a bad scenario, but mitigated if you use graphics that are amenable to compression, like solid colours. There are also some tweaks introduced in WPF 4.0, like the ability to scroll an area on the remote client, which saves having to re-send the entire bitmap if it has moved.