Is there any harm in killing a COM server without releasing com objects in .net?

Folks - I'm creating many COM servers (I'm launching开发者_运维问答 numerous EXEs) in .net, talking to COM via COM -interop, using numerous COM objects in the server, etc. If I kill the process, is there any harm? Is there anything bad about NOT releasing all the COM objects I've used via Marshal.FinalReleaseComObject()? Will I have a memory leak over time?

I'll assume you are talking about out-of-process COM servers although they are far less common than in-process servers. Killing the client app is bad, the server will never get the release calls, the resources for any objects that the client allocated will stay in use until the EXE is terminated. Killing the server app is going to make the client app fail with RPC errors, nothing is leaked.

There's nothing bad about not using Marshal.FinalReleaseComObject(), COM object reference counts are managed by the RCW (runtime callable wrapper). It is a managed object like any other in .NET programming, the garbage collector takes care of it. The reference count is decremented when the finalizer runs. It is unpredictable when that happens.

Using Final/ReleaseComObject() can make it predictable but you have to call it on every object you create. Which can be difficult, it isn't always obvious that you created one when you use the indexer for example. It is also dangerous, mis-timing the call or not properly tracking all references to the object causes the infamous "COM object that has been separated from its underlying RCW cannot be used" exception. A good war story is available here.