How do I properly clean up Excel interop objects?
Asked Answered
L

43

805

I'm using the Excel interop in C# (ApplicationClass) and have placed the following code in my finally clause:

while (System.Runtime.InteropServices.Marshal.ReleaseComObject(excelSheet) != 0) { }
excelSheet = null;
GC.Collect();
GC.WaitForPendingFinalizers();

Although this kind of works, the Excel.exe process is still in the background even after I close Excel. It is only released once my application is manually closed.

What am I doing wrong, or is there an alternative to ensure interop objects are properly disposed of?

Lipolysis answered 1/10, 2008 at 17:18 Comment(6)
Are you trying to shut down the Excel.exe without closing your application? Not sure I fully understand your question.Minor
I'm trying to make sure the unmanaged interop objects are disposed of properly. So that there are not Excel processes hanging around even when the user has finished with Excel spreadsheet we created from the app.Lipolysis
If you can try to do it by producing XML Excel files, otherwise please consider VSTO un/managed Memory Management: jake.ginnivan.net/vsto-com-interopCreed
Does this translate to Excel nicely?Nondisjunction
Answer is below. But I have two tips anyway for the code above: 1) You should use Marshal.FinalReleaseComObject(excelSheet) instead of using this while loop 2) The row "excelSheet = null;" isn't needed when "excelSheet" is a local variablePsychotechnology
See (besides answers below) this support article from Microsoft, where they specifically give solutions to this problem: support.microsoft.com/kb/317109Katy
B
710

Excel does not quit because your application is still holding references to COM objects.

I guess you're invoking at least one member of a COM object without assigning it to a variable.

For me it was the excelApp.Worksheets object which I directly used without assigning it to a variable:

Worksheet sheet = excelApp.Worksheets.Open(...);
...
Marshal.ReleaseComObject(sheet);

I didn't know that internally C# created a wrapper for the Worksheets COM object which didn't get released by my code (because I wasn't aware of it) and was the cause why Excel was not unloaded.

I found the solution to my problem on this page, which also has a nice rule for the usage of COM objects in C#:

Never use two dots with COM objects.


So with this knowledge the right way of doing the above is:

Worksheets sheets = excelApp.Worksheets; // <-- The important part
Worksheet sheet = sheets.Open(...);
...
Marshal.ReleaseComObject(sheets);
Marshal.ReleaseComObject(sheet);

POST MORTEM UPDATE:

I want every reader to read this answer by Hans Passant very carefully as it explains the trap I and lots of other developers stumbled into. When I wrote this answer years ago I didn't know about the effect the debugger has to the garbage collector and drew the wrong conclusions. I keep my answer unaltered for the sake of history but please read this link and don't go the way of "the two dots": Understanding garbage collection in .NET and Clean up Excel Interop Objects with IDisposable

Breakdown answered 1/10, 2008 at 17:30 Comment(22)
Unfortunately, I find that this policy is almost impossible to utilize properly in practice. If one ever slips anywhere and uses "two dots", or iterates cells via a for each loop, or any other similar kind of command, then you'll have unreferenced COM objects and risk a hang...Asdic
... and there would be no way at all to know where in the code you had such a mistake. You'd have to scan ALL your code by hand and hope you find them all. For anyone reading this, I would strongly consider reading my full reply on this below, and then decide for yourself.Asdic
Then I suggest not using Excel from COM and save yourself all of the trouble. The Excel 2007 formats can be used without ever opening Excel, gorgeous.Marcela
I did not understand what "two dots" mean. Can you please explain?Incarnadine
This means, you shouldn't use the pattern comObject.Property.PropertiesProperty (you see the two dots?). Instead assign comObject.Property to a variable and use and dispose that variable. A more formal version of the above rule could be sth. like "Assign com object to variables before you use them. This includes com objects that are properties of another com object."Breakdown
I was not aware that I even had to close the worksheets I had created. worksheet = null removed the two Excel instances that I started. Great thread - appreciate it :)Ardenia
Since sheet is a child of sheets, wouldn't that be released first?Inflationism
@Nick: Actually, you don't need any kind of cleanup, since the garbage collector will do it for you. The only thing you need to do is to assign every COM object to its own variable so the GC knows of it.Breakdown
@VSS thats bollocks, the GC cleans up everything since the wrapper variables are made by the .net framework. It just might take forever for the GC to clean it up. Calling GC.Collect after heavy interop isn't a bad idear.Dentilabial
@I__: Since I don't know your code I can only guess that you missed a COM object (a dot) somewhere.Breakdown
@vvs thank you for your help. what does a dot somewhere mean?Fourpenny
Wow.. This can make up pretty long code for nothing though. So I cannot do worksheet(strrange).value2. I must define the range THEN assign the value to make sure everything is ok ?Chrissa
@sixlettervariables but how can you write to excel without COM, do you have reference URL?Nondisjunction
@sixlettervariables Ah writing an XML that seems a little more code to build the XML but much simpler overall in terms of not dealing with COM objects =)Nondisjunction
I just loudly groaned "OOOOOOOOOOOOOOOOOOOOOOOOOOOH" in the middle of my office. I've never really understood that two-dots thing until now. Thanks!Clime
Thanks. I had a situation where all the advice didn't seem to work until I tried a combo of being extremely careful to avoid "double dotting", with using a group of If objWhatever IsNot Nothing Then System.Runtime.InteropServices.Marshal.FinalReleaseComObject(objWhatever) (VB) in reverse order. I then found that manually invoking the GC wasn't required as, at last, EXCEL was no longer hanging around. The looming last resort Dim NewestExcelProcess = Process.GetProcessesByName("EXCEL").OrderByDescending(Function(p) p.StartTime).First()/NewestExcelProcess.Kill() approach wasn't needed.Katar
Is there a typo in the answer or am I missing something? According to this stackoverflow answer we need to release com objects in the reverse order. Doesn't this mean we need to reverse the order of Marshal.ReleaseComObject(sheets); and Marshal.ReleaseComObject(sheet); in the answer?Efrainefram
Hans Passant disagrees with this answer here: https://mcmap.net/q/55190/-clean-up-excel-interop-objects-with-idisposable Not saying he is right. Just saying he disagrees...and his opinion carries some weight.Splashdown
You should post your Post Mortem Update at the top of the answer. It turns out Hans Passant solution is perfect. Make the real solution more visible.Persimmon
Hans' answer is indeed correct, but note that it does not apply to all COM interop scenarios. Here .NET is spawning the EXCEL.EXE process and has full control over everything. If your .NET code is a COM add-in hosted in-process by the Visual Basic Editor, .NET is being spawned by COM, and this changes everything. The "two-dot" rule isn't completely bullocks.Instinct
The "two-dot" rule is always bullocks. The one thing missing from the answer is that COM STA - office add-ins - require message pumping. If you call them from threads without a message pump then there are scenarios where they cannot exit cleanly.Harden
To Emphasize what has been said above: Follow Hans Passant. Ignore "two-dot rule". Ignore "Marshall.ReleaseComObject". These are much too difficult to get right. Instead, the answer is to force GC to clean up leftover COM objects, as Hans wrote.Isidoro
A
287

You can actually release your Excel Application object cleanly, but you do have to take care.

The advice to maintain a named reference for absolutely every COM object you access and then explicitly release it via Marshal.FinalReleaseComObject() is correct in theory, but, unfortunately, very difficult to manage in practice. If one ever slips anywhere and uses "two dots", or iterates cells via a for each loop, or any other similar kind of command, then you'll have unreferenced COM objects and risk a hang. In this case, there would be no way to find the cause in the code; you would have to review all your code by eye and hopefully find the cause, a task that could be nearly impossible for a large project.

The good news is that you do not actually have to maintain a named variable reference to every COM object you use. Instead, call GC.Collect() and then GC.WaitForPendingFinalizers() to release all the (usually minor) objects to which you do not hold a reference, and then explicitly release the objects to which you do hold a named variable reference.

You should also release your named references in reverse order of importance: range objects first, then worksheets, workbooks, and then finally your Excel Application object.

For example, assuming that you had a Range object variable named xlRng, a Worksheet variable named xlSheet, a Workbook variable named xlBook and an Excel Application variable named xlApp, then your cleanup code could look something like the following:

// Cleanup
GC.Collect();
GC.WaitForPendingFinalizers();

Marshal.FinalReleaseComObject(xlRng);
Marshal.FinalReleaseComObject(xlSheet);

xlBook.Close(Type.Missing, Type.Missing, Type.Missing);
Marshal.FinalReleaseComObject(xlBook);

xlApp.Quit();
Marshal.FinalReleaseComObject(xlApp);

In most code examples you'll see for cleaning up COM objects from .NET, the GC.Collect() and GC.WaitForPendingFinalizers() calls are made TWICE as in:

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();

This should not be required, however, unless you are using Visual Studio Tools for Office (VSTO), which uses finalizers that cause an entire graph of objects to be promoted in the finalization queue. Such objects would not be released until the next garbage collection. However, if you are not using VSTO, you should be able to call GC.Collect() and GC.WaitForPendingFinalizers() just once.

I know that explicitly calling GC.Collect() is a no-no (and certainly doing it twice sounds very painful), but there is no way around it, to be honest. Through normal operations you will generate hidden objects to which you hold no reference that you, therefore, cannot release through any other means other than calling GC.Collect().

This is a complex topic, but this really is all there is to it. Once you establish this template for your cleanup procedure you can code normally, without the need for wrappers, etc. :-)

I have a tutorial on this here:

Automating Office Programs with VB.Net / COM Interop

It's written for VB.NET, but don't be put off by that, the principles are exactly the same as when using C#.

Asdic answered 1/10, 2008 at 17:18 Comment(6)
A related discussion can be found on the ExtremeVBTalk .NET Office Automation forum, here: xtremevbtalk.com/showthread.php?t=303928.Asdic
And if all else fails, then Process.Kill() can be used (as a last resort) as described here: #51962Asdic
Glad it worked Richard. :-) And here is a subtle example where simply avoiding "two dots" is not sufficient to prevent a problem: #4965163Asdic
Here's an opinion on this from Misha Shneerson of Microsoft on the topic, within the comment date Oct. 7, 2010. (blogs.msdn.com/b/csharpfaq/archive/2010/09/28/…)Asdic
I'm hoping this helps a persistent problem we're having. Is it safe to do the garbage collection and release calls within a finally block?Bethea
Worked for me, but only after moving the GC.Collect() after the Marshal.FinalReleaseComObject(xlApp). GC.WaitForPendingFinalizers() was unnecessary.Balbur
C
231

Preface: my answer contains two solutions, so be careful when reading and don't miss anything.

There are different ways and advice of how to make Excel instance unload, such as:

  • Releasing EVERY com object explicitly with Marshal.FinalReleaseComObject() (not forgetting about implicitly created com-objects). To release every created com object, you may use the rule of 2 dots mentioned here:
    How do I properly clean up Excel interop objects?

  • Calling GC.Collect() and GC.WaitForPendingFinalizers() to make CLR release unused com-objects * (Actually, it works, see my second solution for details)

  • Checking if com-server-application maybe shows a message box waiting for the user to answer (though I am not sure it can prevent Excel from closing, but I heard about it a few times)

  • Sending WM_CLOSE message to the main Excel window

  • Executing the function that works with Excel in a separate AppDomain. Some people believe Excel instance will be shut, when AppDomain is unloaded.

  • Killing all excel instances which were instantiated after our excel-interoping code started.

BUT! Sometimes all these options just don't help or can't be appropriate!

For example, yesterday I found out that in one of my functions (which works with excel) Excel keeps running after the function ends. I tried everything! I thoroughly checked the whole function 10 times and added Marshal.FinalReleaseComObject() for everything! I also had GC.Collect() and GC.WaitForPendingFinalizers(). I checked for hidden message boxes. I tried to send WM_CLOSE message to the main Excel window. I executed my function in a separate AppDomain and unloaded that domain. Nothing helped! The option with closing all excel instances is inappropriate, because if the user starts another Excel instance manually, during execution of my function which works also with Excel, then that instance will also be closed by my function. I bet the user will not be happy! So, honestly, this is a lame option (no offence guys). So I spent a couple of hours before I found a good (in my humble opinion) solution: Kill excel process by hWnd of its main window (it's the first solution).

Here is the simple code:

[DllImport("user32.dll")]
private static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint lpdwProcessId);

/// <summary> Tries to find and kill process by hWnd to the main window of the process.</summary>
/// <param name="hWnd">Handle to the main window of the process.</param>
/// <returns>True if process was found and killed. False if process was not found by hWnd or if it could not be killed.</returns>
public static bool TryKillProcessByMainWindowHwnd(int hWnd)
{
    uint processID;
    GetWindowThreadProcessId((IntPtr)hWnd, out processID);
    if(processID == 0) return false;
    try
    {
        Process.GetProcessById((int)processID).Kill();
    }
    catch (ArgumentException)
    {
        return false;
    }
    catch (Win32Exception)
    {
        return false;
    }
    catch (NotSupportedException)
    {
        return false;
    }
    catch (InvalidOperationException)
    {
        return false;
    }
    return true;
}

/// <summary> Finds and kills process by hWnd to the main window of the process.</summary>
/// <param name="hWnd">Handle to the main window of the process.</param>
/// <exception cref="ArgumentException">
/// Thrown when process is not found by the hWnd parameter (the process is not running). 
/// The identifier of the process might be expired.
/// </exception>
/// <exception cref="Win32Exception">See Process.Kill() exceptions documentation.</exception>
/// <exception cref="NotSupportedException">See Process.Kill() exceptions documentation.</exception>
/// <exception cref="InvalidOperationException">See Process.Kill() exceptions documentation.</exception>
public static void KillProcessByMainWindowHwnd(int hWnd)
{
    uint processID;
    GetWindowThreadProcessId((IntPtr)hWnd, out processID);
    if (processID == 0)
        throw new ArgumentException("Process has not been found by the given main window handle.", "hWnd");
    Process.GetProcessById((int)processID).Kill();
}

As you can see I provided two methods, according to Try-Parse pattern (I think it is appropriate here): one method doesn't throw the exception if the Process could not be killed (for example the process doesn't exist anymore), and another method throws the exception if the Process was not killed. The only weak place in this code is security permissions. Theoretically, the user may not have permissions to kill the process, but in 99.99% of all cases, user has such permissions. I also tested it with a guest account - it works perfectly.

So, your code, working with Excel, can look like this:

int hWnd = xl.Application.Hwnd;
// ...
// here we try to close Excel as usual, with xl.Quit(),
// Marshal.FinalReleaseComObject(xl) and so on
// ...
TryKillProcessByMainWindowHwnd(hWnd);

Voila! Excel is terminated! :)

Ok, let's go back to the second solution, as I promised in the beginning of the post. The second solution is to call GC.Collect() and GC.WaitForPendingFinalizers(). Yes, they actually work, but you need to be careful here!
Many people say (and I said) that calling GC.Collect() doesn't help. But the reason it wouldn't help is if there are still references to COM objects! One of the most popular reasons for GC.Collect() not being helpful is running the project in Debug-mode. In debug-mode objects that are not really referenced anymore will not be garbage collected until the end of the method.
So, if you tried GC.Collect() and GC.WaitForPendingFinalizers() and it didn't help, try to do the following:

1) Try to run your project in Release mode and check if Excel closed correctly

2) Wrap the method of working with Excel in a separate method. So, instead of something like this:

void GenerateWorkbook(...)
{
  ApplicationClass xl;
  Workbook xlWB;
  try
  {
    xl = ...
    xlWB = xl.Workbooks.Add(...);
    ...
  }
  finally
  {
    ...
    Marshal.ReleaseComObject(xlWB)
    ...
    GC.Collect();
    GC.WaitForPendingFinalizers();
  }
}

you write:

void GenerateWorkbook(...)
{
  try
  {
    GenerateWorkbookInternal(...);
  }
  finally
  {
    GC.Collect();
    GC.WaitForPendingFinalizers();
  }
}

private void GenerateWorkbookInternal(...)
{
  ApplicationClass xl;
  Workbook xlWB;
  try
  {
    xl = ...
    xlWB = xl.Workbooks.Add(...);
    ...
  }
  finally
  {
    ...
    Marshal.ReleaseComObject(xlWB)
    ...
  }
}

Now, Excel will close =)

Chalfant answered 12/12, 2009 at 14:50 Comment(16)
sad that the thread is already so old that your excellent answer appears that far below, which I think is the only reason for it not being upvoted more times...Unfrock
@VVS: It's absolutely incorrect analogy. And your "rule of 2 dots" doesn't always work. Far not always.Chalfant
@nightcoder: Do you have a sample? Reminds me to codinghorror.com/blog/2008/03/…Breakdown
I can find a sample, but I don't want to waste my time and argue with you. Many people confirm that ReleaseComObject() doesn't always help.Chalfant
I have to admit, when I first read your answer, I thought it was a giant kludge. After about 6 hours of wrestling with this (everything is released, I've got no double dots, etc..), I now think your answer is genius.Bandstand
Thanks for this. Been wrestling with an Excel that wouldn't close no matter what for a couple of days before I found this. Excellent.Tenderfoot
I'm not noticing any issue using GC.Collect() and GC.WaitForPendingFinalizers() in Debug mode...if I do just your second step ("wrap the method working with Excel in a separate method"), it seems to work fine. In fact, Excel disappears nicely from my Task Manager process list even if I never use Marshal.ReleaseComObject(). If using either of your methods (KillProcessByMainWindowHwnd or GC.Collect() and GC.WaitForPendingFinalizers() with a wrapped method), isn't manually releasing com objects completely unnecessary?Blamed
DanM, if do not kill Excel's process and use GC.Collect() + GC.WaitForPendingFinalizers then you still need to call Marshal.ReleaseComObject() and set null to COM object wrappers (like workbook objects, etc.), otherwise Excel process will not be closed. If you kill Excel's process I would still call Marshal.ReleaseComObject() and set null to COM object wrappers, because it will help free memory sooner and it's more correct (for example, if you don't call ReleaseComObject() then those wrappers will try to access nonexistent com objects that were already destroyed when you killed Excel process).Chalfant
@nightcoder, thanks for your reply. Let me make sure we're talking about the same thing. Here's what I tried: (1) put all code dealing with Excel COM objects into a self-contained method (or hierarchy of methods), (2) create a calling method that invokes the self-contained method in a try block, then calls GC.Collect() and GC.WaitForPendingFinalizers() in a finally block. In my testing so far, this clears the Excel process from Task Manager every time. Step 1 ensures that COM objects are stored only in local variables, so once the method completes, there should be no live references.Blamed
@Chalfant (continued), You seem to be saying that this may not be reliable if I don't also manually call Marshal.ReleaseComObject() for certain COM object wrappers. If GC.Collect() and GC.WaitForPendingFinalizers() are really not enough (again, assuming that all references to COM objects are restricted to no-longer-in-scope local variables), (1) why? and (2) which Excel COM objects need to be released? In my test case, I am not releasing the following objects with no apparent ill effects: Application, Workbook, Sheets, Worksheet, and Range. Thanks again!Blamed
@nightcoder: awesome answer, really detailed. Your comments with respect to debug mode are very true and important that you pointed this out. The same code in release mode can often be fine. Process.Kill however, is only good when using automation, not when your program is running within Excel, e.g., as a managed COM add-in.Asdic
@DanM: Your approach is 100% correct and will never fail. By keeping all your variables local to the method, all references are effectively unreachable by .NET code. This means that when your finally section calls GC.Collect(), the finalizers for all your COM objects will get called with certainty. Each finalizer then calls Marshal.FinalReleaseComObject on the object being finalized. Your approach is therefore simple and fool-proof. Have no fear using this. (Only caveat: if using VSTO, which I doubt that you are, you would need to call GC.Collect() & GC.WaitForPendingFinalizers TWICE.)Asdic
@MikeRosenblum, thanks for responding to my comment. I appreciate the reassurance. For the particular project I was working on at the time, I ended up bypassing the issue altogether by using a file-based approach (using EPPlus) instead of COM. If I need to actually use COM interop again, though, I'll know what to do.Blamed
I think this takes 'leaky abstraction' to the extremePosting
Explicitly killing or posting a WM_CLOSE to an out-of-process COM server (that might be serving other COM clients) is a dreadful idea. If you are resorting to this it's because your COM protocol is broken. COM servers should not be treated as a regular windowed-appAdiabatic
the 2nd cleaner method wouldn't work with Marshal.ReleaseComObject, replaced with 2xClose() and a Quit() and it worked! so the guy who said use ReleaseComObject has some explaining to do!Garment
T
51

UPDATE: Added C# code, and link to Windows Jobs

I spent sometime trying to figure out this problem, and at the time XtremeVBTalk was the most active and responsive. Here is a link to my original post, Closing an Excel Interop process cleanly, even if your application crashes. Below is a summary of the post, and the code copied to this post.

  • Closing the Interop process with Application.Quit() and Process.Kill() works for the most part, but fails if the applications crashes catastrophically. I.e. if the app crashes, the Excel process will still be running loose.
  • The solution is to let the OS handle the cleanup of your processes through Windows Job Objects using Win32 calls. When your main application dies, the associated processes (i.e. Excel) will get terminated as well.

I found this to be a clean solution because the OS is doing real work of cleaning up. All you have to do is register the Excel process.

Windows Job Code

Wraps the Win32 API Calls to register Interop processes.

public enum JobObjectInfoType
{
    AssociateCompletionPortInformation = 7,
    BasicLimitInformation = 2,
    BasicUIRestrictions = 4,
    EndOfJobTimeInformation = 6,
    ExtendedLimitInformation = 9,
    SecurityLimitInformation = 5,
    GroupInformation = 11
}

[StructLayout(LayoutKind.Sequential)]
public struct SECURITY_ATTRIBUTES
{
    public int nLength;
    public IntPtr lpSecurityDescriptor;
    public int bInheritHandle;
}

[StructLayout(LayoutKind.Sequential)]
struct JOBOBJECT_BASIC_LIMIT_INFORMATION
{
    public Int64 PerProcessUserTimeLimit;
    public Int64 PerJobUserTimeLimit;
    public Int16 LimitFlags;
    public UInt32 MinimumWorkingSetSize;
    public UInt32 MaximumWorkingSetSize;
    public Int16 ActiveProcessLimit;
    public Int64 Affinity;
    public Int16 PriorityClass;
    public Int16 SchedulingClass;
}

[StructLayout(LayoutKind.Sequential)]
struct IO_COUNTERS
{
    public UInt64 ReadOperationCount;
    public UInt64 WriteOperationCount;
    public UInt64 OtherOperationCount;
    public UInt64 ReadTransferCount;
    public UInt64 WriteTransferCount;
    public UInt64 OtherTransferCount;
}

[StructLayout(LayoutKind.Sequential)]
struct JOBOBJECT_EXTENDED_LIMIT_INFORMATION
{
    public JOBOBJECT_BASIC_LIMIT_INFORMATION BasicLimitInformation;
    public IO_COUNTERS IoInfo;
    public UInt32 ProcessMemoryLimit;
    public UInt32 JobMemoryLimit;
    public UInt32 PeakProcessMemoryUsed;
    public UInt32 PeakJobMemoryUsed;
}

public class Job : IDisposable
{
    [DllImport("kernel32.dll", CharSet = CharSet.Unicode)]
    static extern IntPtr CreateJobObject(object a, string lpName);

    [DllImport("kernel32.dll")]
    static extern bool SetInformationJobObject(IntPtr hJob, JobObjectInfoType infoType, IntPtr lpJobObjectInfo, uint cbJobObjectInfoLength);

    [DllImport("kernel32.dll", SetLastError = true)]
    static extern bool AssignProcessToJobObject(IntPtr job, IntPtr process);

    private IntPtr m_handle;
    private bool m_disposed = false;

    public Job()
    {
        m_handle = CreateJobObject(null, null);

        JOBOBJECT_BASIC_LIMIT_INFORMATION info = new JOBOBJECT_BASIC_LIMIT_INFORMATION();
        info.LimitFlags = 0x2000;

        JOBOBJECT_EXTENDED_LIMIT_INFORMATION extendedInfo = new JOBOBJECT_EXTENDED_LIMIT_INFORMATION();
        extendedInfo.BasicLimitInformation = info;

        int length = Marshal.SizeOf(typeof(JOBOBJECT_EXTENDED_LIMIT_INFORMATION));
        IntPtr extendedInfoPtr = Marshal.AllocHGlobal(length);
        Marshal.StructureToPtr(extendedInfo, extendedInfoPtr, false);

        if (!SetInformationJobObject(m_handle, JobObjectInfoType.ExtendedLimitInformation, extendedInfoPtr, (uint)length))
            throw new Exception(string.Format("Unable to set information.  Error: {0}", Marshal.GetLastWin32Error()));
    }

    #region IDisposable Members

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    #endregion

    private void Dispose(bool disposing)
    {
        if (m_disposed)
            return;

        if (disposing) {}

        Close();
        m_disposed = true;
    }

    public void Close()
    {
        Win32.CloseHandle(m_handle);
        m_handle = IntPtr.Zero;
    }

    public bool AddProcess(IntPtr handle)
    {
        return AssignProcessToJobObject(m_handle, handle);
    }

}

Note about Constructor code

  • In the constructor, the info.LimitFlags = 0x2000; is called. 0x2000 is the JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE enum value, and this value is defined by MSDN as:

Causes all processes associated with the job to terminate when the last handle to the job is closed.

Extra Win32 API Call to get the Process ID (PID)

    [DllImport("user32.dll", SetLastError = true)]
    public static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint lpdwProcessId);

Using the code

    Excel.Application app = new Excel.ApplicationClass();
    Job job = new Job();
    uint pid = 0;
    Win32.GetWindowThreadProcessId(new IntPtr(app.Hwnd), out pid);
    job.AddProcess(Process.GetProcessById((int)pid).Handle);
Topdress answered 20/8, 2009 at 16:0 Comment(1)
Explicitly killing an out-of-process COM server (that might be serving other COM clients) is a dreadful idea. If you are resorting to this it's because your COM protocol is broken. COM servers should not be treated as a regular windowed-appAdiabatic
P
46

This worked for a project I was working on:

excelApp.Quit();
Marshal.ReleaseComObject (excelWB);
Marshal.ReleaseComObject (excelApp);
excelApp = null;

We learned that it was important to set every reference to an Excel COM object to null when you were done with it. This included Cells, Sheets, and everything.

Parr answered 1/10, 2008 at 17:30 Comment(0)
S
42

First - you never have to call Marshal.ReleaseComObject(...) or Marshal.FinalReleaseComObject(...) when doing Excel interop. It is a confusing anti-pattern, but any information about this, including from Microsoft, that indicates you have to manually release COM references from .NET is incorrect. The fact is that the .NET runtime and garbage collector correctly keep track of and clean up COM references. For your code, this means you can remove the whole `while (...) loop at the top.

Second, if you want to ensure that the COM references to an out-of-process COM object are cleaned up when your process ends (so that the Excel process will close), you need to ensure that the garbage collector runs. You do this correctly with calls to GC.Collect() and GC.WaitForPendingFinalizers(). Calling this twice is safe, and ensures that cycles are definitely cleaned up too (though I'm not sure it's needed, and would appreciate an example that shows this).

Third, when running under the debugger, local references will be artificially kept alive until the end of the method (so that local variable inspection works). So GC.Collect() calls are not effective for cleaning object like rng.Cells from the same method. You should split the code doing the COM interop from the GC cleanup into separate methods. (This was a key discovery for me, from one part of the answer posted here by @nightcoder.)

The general pattern would thus be:

Sub WrapperThatCleansUp()

    ' NOTE: Don't call Excel objects in here... 
    '       Debugger would keep alive until end, preventing GC cleanup

    ' Call a separate function that talks to Excel
    DoTheWork()

    ' Now let the GC clean up (twice, to clean up cycles too)
    GC.Collect()    
    GC.WaitForPendingFinalizers()
    GC.Collect()    
    GC.WaitForPendingFinalizers()

End Sub

Sub DoTheWork()
    Dim app As New Microsoft.Office.Interop.Excel.Application
    Dim book As Microsoft.Office.Interop.Excel.Workbook = app.Workbooks.Add()
    Dim worksheet As Microsoft.Office.Interop.Excel.Worksheet = book.Worksheets("Sheet1")
    app.Visible = True
    For i As Integer = 1 To 10
        worksheet.Cells.Range("A" & i).Value = "Hello"
    Next
    book.Save()
    book.Close()
    app.Quit()

    ' NOTE: No calls the Marshal.ReleaseComObject() are ever needed
End Sub

There is a lot of false information and confusion about this issue, including many posts on MSDN and on Stack Overflow (and especially this question!).

What finally convinced me to have a closer look and figure out the right advice was blog post Marshal.ReleaseComObject Considered Dangerous together with finding the issue with references kept alive under the debugger that was confusing my earlier testing.

Stockroom answered 29/6, 2016 at 22:50 Comment(2)
Virtually ALL ANSWERS ON THIS PAGE ARE WRONG EXCEPT THIS ONE. They work but are way too much work. IGNORE the "2 DOTS" rule. Let the GC do your work for you. Supplementary evidence from .Net GURU Hans Passant : https://mcmap.net/q/55190/-clean-up-excel-interop-objects-with-idisposableIsidoro
Govert, what a relief to find the correct way to do it. Thank you.Silversmith
D
30

Anything that is in the Excel namespace needs to be released. Period

You can't be doing:

Worksheet ws = excel.WorkBooks[1].WorkSheets[1];

You have to be doing

Workbooks books = excel.WorkBooks;
Workbook book = books[1];
Sheets sheets = book.WorkSheets;
Worksheet ws = sheets[1];

followed by the releasing of the objects.

Darton answered 1/10, 2008 at 17:45 Comment(4)
How aobut xlRange.Interior.Color for example.Lipolysis
Interior needs to be release (its in the namespace)... Color on the other hand doesn't (cause its from System.Drawing.Color, iirc)Darton
actually Color is a Excel color not a .Net color. you just pass a Long. Also workbooks def. need to be released, worksheets... less so.Geffner
That is not true, the two-dot-bad, one-dot-good rule is nonsense. Also, you don't have to release Workbooks, Worksheets, Ranges, that is the job of the GC. The only thing that you must never forget is to call Quit on the one and only Excel.Application object. After calling Quit, null the Excel.Application object and call GC.Collect(); GC.WaitForPendingFinalizers(); twice.Silversmith
A
19

I found a useful generic template that can help implement the correct disposal pattern for COM objects, that need Marshal.ReleaseComObject called when they go out of scope:

Usage:

using (AutoReleaseComObject<Application> excelApplicationWrapper = new AutoReleaseComObject<Application>(new Application()))
{
    try
    {
        using (AutoReleaseComObject<Workbook> workbookWrapper = new AutoReleaseComObject<Workbook>(excelApplicationWrapper.ComObject.Workbooks.Open(namedRangeBase.FullName, false, false, missing, missing, missing, true, missing, missing, true, missing, missing, missing, missing, missing)))
        {
           // do something with your workbook....
        }
    }
    finally
    {
         excelApplicationWrapper.ComObject.Quit();
    } 
}

Template:

public class AutoReleaseComObject<T> : IDisposable
{
    private T m_comObject;
    private bool m_armed = true;
    private bool m_disposed = false;

    public AutoReleaseComObject(T comObject)
    {
        Debug.Assert(comObject != null);
        m_comObject = comObject;
    }

#if DEBUG
    ~AutoReleaseComObject()
    {
        // We should have been disposed using Dispose().
        Debug.WriteLine("Finalize being called, should have been disposed");

        if (this.ComObject != null)
        {
            Debug.WriteLine(string.Format("ComObject was not null:{0}, name:{1}.", this.ComObject, this.ComObjectName));
        }

        //Debug.Assert(false);
    }
#endif

    public T ComObject
    {
        get
        {
            Debug.Assert(!m_disposed);
            return m_comObject;
        }
    }

    private string ComObjectName
    {
        get
        {
            if(this.ComObject is Microsoft.Office.Interop.Excel.Workbook)
            {
                return ((Microsoft.Office.Interop.Excel.Workbook)this.ComObject).Name;
            }

            return null;
        }
    }

    public void Disarm()
    {
        Debug.Assert(!m_disposed);
        m_armed = false;
    }

    #region IDisposable Members

    public void Dispose()
    {
        Dispose(true);
#if DEBUG
        GC.SuppressFinalize(this);
#endif
    }

    #endregion

    protected virtual void Dispose(bool disposing)
    {
        if (!m_disposed)
        {
            if (m_armed)
            {
                int refcnt = 0;
                do
                {
                    refcnt = System.Runtime.InteropServices.Marshal.ReleaseComObject(m_comObject);
                } while (refcnt > 0);

                m_comObject = default(T);
            }

            m_disposed = true;
        }
    }
}

Reference:

http://www.deez.info/sengelha/2005/02/11/useful-idisposable-class-3-autoreleasecomobject/

Artemisa answered 8/12, 2008 at 11:10 Comment(2)
yup this one is good. I think this code can be updated though now that FinalReleaseCOMObject is available.Geffner
It's still annoying to have a using block for each object. See here #2191989 for an alternative.Catechism
H
18

I cant believe this problem has haunted the world for 5 years.... If you have created an application, you need to shut it down first before removing the link.

objExcel = new Excel.Application();  
objBook = (Excel.Workbook)(objExcel.Workbooks.Add(Type.Missing)); 

when closing

objBook.Close(true, Type.Missing, Type.Missing); 
objExcel.Application.Quit();
objExcel.Quit(); 

When you new an excel application, it opens a excel program in the background. You need to command that excel program to quit before you release the link because that excel program is not part of your direct control. Therefore, it will stay open if the link is released!

Good programming everyone~~

Huffish answered 21/11, 2010 at 3:41 Comment(3)
No, you don't, especially if you want to allow user interaction with the COM application (Excel in this case--OP doesn't specify whether user interaction is intended, but makes no reference to shutting it down). You just have to get the caller to let go for the user to be able to quit Excel when closing, say, a single file.Shipe
this worked perfectly for me - crashed when I only had objExcel.Quit(), but when I also did objExcel.Application.Quit() beforehand, closed cleanly.Propensity
objExcel.Application.Quit() and objExcel.Quit() is the same call because objExcel == objExcel.Application. Consequently, it doesn't matter which one you call. Just do it once. The second time you do it (regardless of which) it has already quit.Homogenize
M
13

Common developers, none of your solutions worked for me, so I decide to implement a new trick.

First let specify "What is our goal?" => "Not to see excel object after our job in task manager"

Ok. Let no to challenge and start destroying it, but consider not to destroy other instance os Excel which are running in parallel.

So , get the list of current processors and fetch PID of EXCEL processes , then once your job is done, we have a new guest in processes list with a unique PID ,find and destroy just that one.

< keep in mind any new excel process during your excel job will be detected as new and destroyed > < A better solution is to capture PID of new created excel object and just destroy that>

Process[] prs = Process.GetProcesses();
List<int> excelPID = new List<int>();
foreach (Process p in prs)
   if (p.ProcessName == "EXCEL")
       excelPID.Add(p.Id);

.... // your job 

prs = Process.GetProcesses();
foreach (Process p in prs)
   if (p.ProcessName == "EXCEL" && !excelPID.Contains(p.Id))
       p.Kill();

This resolves my issue, hope yours too.

Makedamakefast answered 16/10, 2009 at 11:1 Comment(2)
....this is a bit of a sledghammer approach? - it is similar to what I'm also using :( but need to change. The problem with using this approach is that often when opening excel, on the machine where this ran, it has the alert in left hand bar, saying something like "Excel was closed down incorrectly" : not very elegant. I think one of the earlier suggestions in this thread is to be preferred.Scrimshaw
Downvoted because it is an ugly hack rather than a solution.Oleograph
A
13

This sure seems like it has been over-complicated. From my experience, there are just three key things to get Excel to close properly:

1: make sure there are no remaining references to the excel application you created (you should only have one anyway; set it to null)

2: call GC.Collect()

3: Excel has to be closed, either by the user manually closing the program, or by you calling Quit on the Excel object. (Note that Quit will function just as if the user tried to close the program, and will present a confirmation dialog if there are unsaved changes, even if Excel is not visible. The user could press cancel, and then Excel will not have been closed.)

1 needs to happen before 2, but 3 can happen anytime.

One way to implement this is to wrap the interop Excel object with your own class, create the interop instance in the constructor, and implement IDisposable with Dispose looking something like

if (!mDisposed) {
   mExcel = null;
   GC.Collect();
   mDisposed = true;
}

That will clean up excel from your program's side of things. Once Excel is closed (manually by the user or by you calling Quit) the process will go away. If the program has already been closed, then the process will disappear on the GC.Collect() call.

(I'm not sure how important it is, but you may want a GC.WaitForPendingFinalizers() call after the GC.Collect() call but it is not strictly necessary to get rid of the Excel process.)

This has worked for me without issue for years. Keep in mind though that while this works, you actually have to close gracefully for it to work. You will still get accumulating excel.exe processes if you interrupt your program before Excel is cleaned up (usually by hitting "stop" while your program is being debugged).

Arms answered 31/8, 2011 at 21:18 Comment(1)
This answer works and is infinitely more convenient than the accepted answer. No worries about "two dots" with COM objects, no use of Marshal.Coccid
D
12

I've traditionally followed the advice found in VVS's answer. However, in an effort to keep this answer up-to-date with the latest options, I think all my future projects will use the "NetOffice" library.

NetOffice is a complete replacement for the Office PIAs and is completely version-agnostic. It's a collection of Managed COM wrappers that can handle the cleanup that often causes such headaches when working with Microsoft Office in .NET.

Some key features are:

  • Mostly version-independent (and version-dependant features are documented)
  • No dependencies
  • No PIA
  • No registration
  • No VSTO

I am in no way affiliated with the project; I just genuinely appreciate the stark reduction in headaches.

Dwelling answered 28/3, 2013 at 14:12 Comment(2)
This should be marked as the answer, really. NetOffice abstracts all this complexity away.Cenesthesia
I've been using NetOffice for a considerable amount of time writing an excel add-in and it worked perfectly. The only thing to consider is that if you don't dispose used objects explicitly, it will do it when you exit the application (because it keeps track of them anyway). So the rule of thumb with NetOffice is always to use "using" pattern with every Excel object like cell, range or sheet etc.Micheal
M
10

To add to reasons why Excel does not close, even when you create direct refrences to each object upon read, creation, is the 'For' loop.

For Each objWorkBook As WorkBook in objWorkBooks 'local ref, created from ExcelApp.WorkBooks to avoid the double-dot
   objWorkBook.Close 'or whatever
   FinalReleaseComObject(objWorkBook)
   objWorkBook = Nothing
Next 

'The above does not work, and this is the workaround:

For intCounter As Integer = 1 To mobjExcel_WorkBooks.Count
   Dim objTempWorkBook As Workbook = mobjExcel_WorkBooks.Item(intCounter)
   objTempWorkBook.Saved = True
   objTempWorkBook.Close(False, Type.Missing, Type.Missing)
   FinalReleaseComObject(objTempWorkBook)
   objTempWorkBook = Nothing
Next
Muffin answered 6/12, 2010 at 13:8 Comment(3)
And another reason, re-using a reference without releasing the previous value first.Muffin
Thank you. I was also using a "for each" your solution worked for me.Scherer
+1 Thanks. Plus, note that if you have an object for an Excel range, and you want to change the range during the lifetime of the object, I found that I had to ReleaseComObject before reassigning it, which makes the code a little untidy!Katar
C
9

The accepted answer here is correct, but also take note that not only "two dot" references need to be avoided, but also objects that are retrieved via the index. You also do not need to wait until you are finished with the program to clean up these objects, it's best to create functions that will clean them up as soon as you're finished with them, when possible. Here is a function I created that assigns some properties of a Style object called xlStyleHeader:

public Excel.Style xlStyleHeader = null;

private void CreateHeaderStyle()
{
    Excel.Styles xlStyles = null;
    Excel.Font xlFont = null;
    Excel.Interior xlInterior = null;
    Excel.Borders xlBorders = null;
    Excel.Border xlBorderBottom = null;

    try
    {
        xlStyles = xlWorkbook.Styles;
        xlStyleHeader = xlStyles.Add("Header", Type.Missing);

        // Text Format
        xlStyleHeader.NumberFormat = "@";

        // Bold
        xlFont = xlStyleHeader.Font;
        xlFont.Bold = true;

        // Light Gray Cell Color
        xlInterior = xlStyleHeader.Interior;
        xlInterior.Color = 12632256;

        // Medium Bottom border
        xlBorders = xlStyleHeader.Borders;
        xlBorderBottom = xlBorders[Excel.XlBordersIndex.xlEdgeBottom];
        xlBorderBottom.Weight = Excel.XlBorderWeight.xlMedium;
    }
    catch (Exception ex)
    {
        throw ex;
    }
    finally
    {
        Release(xlBorderBottom);
        Release(xlBorders);
        Release(xlInterior);
        Release(xlFont);
        Release(xlStyles);
    }
}

private void Release(object obj)
{
    // Errors are ignored per Microsoft's suggestion for this type of function:
    // http://support.microsoft.com/default.aspx/kb/317109
    try
    {
        System.Runtime.InteropServices.Marshal.ReleaseComObject(obj);
    }
    catch { } 
}

Notice that I had to set xlBorders[Excel.XlBordersIndex.xlEdgeBottom] to a variable in order to clean that up (Not because of the two dots, which refer to an enumeration which does not need to be released, but because the object I'm referring to is actually a Border object that does need to be released).

This sort of thing is not really necessary in standard applications, which do a great job of cleaning up after themselves, but in ASP.NET applications, if you miss even one of these, no matter how often you call the garbage collector, Excel will still be running on your server.

It requires a lot of attention to detail and many test executions while monitoring the Task Manager when writing this code, but doing so saves you the hassle of desperately searching through pages of code to find the one instance you missed. This is especially important when working in loops, where you need to release EACH INSTANCE of an object, even though it uses the same variable name each time it loops.

Cleisthenes answered 17/12, 2009 at 20:15 Comment(1)
Inside Release, check for Null (Joe's answer). That will avoid unnecessary null exceptions. I have tested a LOT of methods. This is the only way to effectively release Excel.Footpound
G
9

After trying

  1. Release COM objects in reverse order
  2. Add GC.Collect() and GC.WaitForPendingFinalizers() twice at the end
  3. No more than two dots
  4. Close workbook and quit application
  5. Run in release mode

the final solution that works for me is to move one set of

GC.Collect();
GC.WaitForPendingFinalizers();

that we added to the end of the function to a wrapper, as follows:

private void FunctionWrapper(string sourcePath, string targetPath)
{
    try
    {
        FunctionThatCallsExcel(sourcePath, targetPath);
    }
    finally
    {
        GC.Collect();
        GC.WaitForPendingFinalizers();
    }
}
Girardo answered 18/11, 2013 at 22:58 Comment(1)
I found I did not need to nullify ComObjects, only Quit() - Close() and FinalReleaseComObject. I can't believe this is all that was missing on my end to get it to work. Great!Thoracotomy
M
8

I followed this exactly... But I still ran into issues 1 out of 1000 times. Who knows why. Time to bring out the hammer...

Right after the Excel Application class is instantiated I get a hold of the Excel process that was just created.

excel = new Microsoft.Office.Interop.Excel.Application();
var process = Process.GetProcessesByName("EXCEL").OrderByDescending(p => p.StartTime).First();

Then once I've done all the above COM clean-up, I make sure that process isn't running. If it is still running, kill it!

if (!process.HasExited)
   process.Kill();
Missend answered 25/2, 2014 at 3:35 Comment(0)
F
7

¨°º¤ø„¸ Shoot Excel proc and chew bubble gum ¸„ø¤º°¨

public class MyExcelInteropClass
{
    Excel.Application xlApp;
    Excel.Workbook xlBook;

    public void dothingswithExcel() 
    {
        try { /* Do stuff manipulating cells sheets and workbooks ... */ }
        catch {}
        finally {KillExcelProcess(xlApp);}
    }

    static void KillExcelProcess(Excel.Application xlApp)
    {
        if (xlApp != null)
        {
            int excelProcessId = 0;
            GetWindowThreadProcessId(xlApp.Hwnd, out excelProcessId);
            Process p = Process.GetProcessById(excelProcessId);
            p.Kill();
            xlApp = null;
        }
    }

    [DllImport("user32.dll")]
    static extern int GetWindowThreadProcessId(int hWnd, out int lpdwProcessId);
}
Flamen answered 14/6, 2013 at 15:16 Comment(0)
E
6

You need to be aware that Excel is very sensitive to the culture you are running under as well.

You may find that you need to set the culture to EN-US before calling Excel functions. This does not apply to all functions - but some of them.

    CultureInfo en_US = new System.Globalization.CultureInfo("en-US"); 
    System.Threading.Thread.CurrentThread.CurrentCulture = en_US;
    string filePathLocal = _applicationObject.ActiveWorkbook.Path;
    System.Threading.Thread.CurrentThread.CurrentCulture = orgCulture;

This applies even if you are using VSTO.

For details: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q320369

Edington answered 6/11, 2008 at 15:21 Comment(0)
L
6

"Never use two dots with COM objects" is a great rule of thumb to avoid leakage of COM references, but Excel PIA can lead to leakage in more ways than apparent at first sight.

One of these ways is subscribing to any event exposed by any of the Excel object model's COM objects.

For example, subscribing to the Application class's WorkbookOpen event.

Some theory on COM events

COM classes expose a group of events through call-back interfaces. In order to subscribe to events, the client code can simply register an object implementing the call-back interface and the COM class will invoke its methods in response to specific events. Since the call-back interface is a COM interface, it is the duty of the implementing object to decrement the reference count of any COM object it receives (as a parameter) for any of the event handlers.

How Excel PIA expose COM Events

Excel PIA exposes COM events of Excel Application class as conventional .NET events. Whenever the client code subscribes to a .NET event (emphasis on 'a'), PIA creates an instance of a class implementing the call-back interface and registers it with Excel.

Hence, a number of call-back objects get registered with Excel in response to different subscription requests from the .NET code. One call-back object per event subscription.

A call-back interface for event handling means that, PIA has to subscribe to all interface events for every .NET event subscription request. It cannot pick and choose. On receiving an event call-back, the call-back object checks if the associated .NET event handler is interested in the current event or not and then either invokes the handler or silently ignores the call-back.

Effect on COM instance reference counts

All these call-back objects do not decrement the reference count of any of the COM objects they receive (as parameters) for any of the call-back methods (even for the ones that are silently ignored). They rely solely on the CLR garbage collector to free up the COM objects.

Since GC run is non-deterministic, this can lead to the holding off of Excel process for a longer duration than desired and create an impression of a 'memory leak'.

Solution

The only solution as of now is to avoid the PIA’s event provider for the COM class and write your own event provider which deterministically releases COM objects.

For the Application class, this can be done by implementing the AppEvents interface and then registering the implementation with Excel by using IConnectionPointContainer interface. The Application class (and for that matter all COM objects exposing events using callback mechanism) implements the IConnectionPointContainer interface.

Lulualaba answered 25/6, 2012 at 6:52 Comment(0)
I
5

A great article on releasing COM objects is 2.5 Releasing COM Objects (MSDN).

The method that I would advocate is to null your Excel.Interop references if they are non-local variables, and then call GC.Collect() and GC.WaitForPendingFinalizers() twice. Locally scoped Interop variables will be taken care of automatically.

This removes the need to keep a named reference for every COM object.

Here's an example taken from the article:

public class Test {

    // These instance variables must be nulled or Excel will not quit
    private Excel.Application xl;
    private Excel.Workbook book;

    public void DoSomething()
    {
        xl = new Excel.Application();
        xl.Visible = true;
        book = xl.Workbooks.Add(Type.Missing);

        // These variables are locally scoped, so we need not worry about them.
        // Notice I don't care about using two dots.
        Excel.Range rng = book.Worksheets[1].UsedRange;
    }

    public void CleanUp()
    {
        book = null;
        xl.Quit();
        xl = null;

        GC.Collect();
        GC.WaitForPendingFinalizers();
        GC.Collect();
        GC.WaitForPendingFinalizers();
    }
}

These words are straight from the article:

In almost all situations, nulling the RCW reference and forcing a garbage collection will clean up properly. If you also call GC.WaitForPendingFinalizers, garbage collection will be as deterministic as you can make it. That is, you'll be pretty sure exactly when the object has been cleaned up—on the return from the second call to WaitForPendingFinalizers. As an alternative, you can use Marshal.ReleaseComObject. However, note that you are very unlikely to ever need to use this method.

Invidious answered 1/10, 2008 at 17:18 Comment(1)
In my case, even local variables needed to be set to null in a finally {} block, in case of an exception being thrown in the try{} block.Othilie
W
4

As others have pointed out, you need to create an explicit reference for every Excel object you use, and call Marshal.ReleaseComObject on that reference, as described in this KB article. You also need to use try/finally to ensure ReleaseComObject is always called, even when an exception is thrown. I.e. instead of:

Worksheet sheet = excelApp.Worksheets(1)
... do something with sheet

you need to do something like:

Worksheets sheets = null;
Worksheet sheet = null
try
{ 
    sheets = excelApp.Worksheets;
    sheet = sheets(1);
    ...
}
finally
{
    if (sheets != null) Marshal.ReleaseComObject(sheets);
    if (sheet != null) Marshal.ReleaseComObject(sheet);
}

You also need to call Application.Quit before releasing the Application object if you want Excel to close.

As you can see, this quickly becomes extremely unwieldy as soon as you try to do anything even moderately complex. I have successfully developed .NET applications with a simple wrapper class that wraps a few simple manipulations of the Excel object model (open a workbook, write to a Range, save/close the workbook etc). The wrapper class implements IDisposable, carefully implements Marshal.ReleaseComObject on every object it uses, and does not pubicly expose any Excel objects to the rest of the app.

But this approach doesn't scale well for more complex requirements.

This is a big deficiency of .NET COM Interop. For more complex scenarios, I would seriously consider writing an ActiveX DLL in VB6 or other unmanaged language to which you can delegate all interaction with out-proc COM objects such as Office. You can then reference this ActiveX DLL from your .NET application, and things will be much easier as you will only need to release this one reference.

Willmert answered 1/10, 2008 at 18:26 Comment(0)
I
3

When all the stuff above didn't work, try giving Excel some time to close its sheets:

app.workbooks.Close();
Thread.Sleep(500); // adjust, for me it works at around 300+
app.Quit();

...
FinalReleaseComObject(app);
Incorporating answered 18/6, 2011 at 12:2 Comment(2)
I hate arbitrary waits. But +1 because you are right about needding to wait for the workbooks to close. An alternative is to poll the workbooks collection in a loop and use the arbitrary wait as the loop timeout.Mayce
I highly doubt that Close() is not blocking call, i.e. I don't think execution will continue until the workbooks are in fact closed. If the Close() method returned and you could then enumerate the collection of workbooks and it was not empty, then that would be a serious bug in my view. I would rather loop over the workbooks and call .Close(false) and then Quit().Homogenize
F
3

Make sure that you release all objects related to Excel!

I spent a few hours by trying several ways. All are great ideas but I finally found my mistake: If you don't release all objects, none of the ways above can help you like in my case. Make sure you release all objects including range one!

Excel.Range rng = (Excel.Range)worksheet.Cells[1, 1];
worksheet.Paste(rng, false);
releaseObject(rng);

The options are together here.

Forint answered 8/8, 2012 at 18:38 Comment(1)
Very good point! I think because I am using Office 2007 there is some clean-up done on my behalf. I have used the advise further up but have not stored variables as you have suggested here and EXCEL.EXE does exit but I could just be lucky and if I have any further problems I will definitely look at this part of my code =)Nondisjunction
W
2

You should be very careful using Word/Excel interop applications. After trying all the solutions we still had a lot of "WinWord" process left open on server (with more than 2000 users).

After working on the problem for hours, I realized that if I open more than a couple of documents using Word.ApplicationClass.Document.Open() on different threads simultaneously, IIS worker process (w3wp.exe) would crash leaving all WinWord processes open!

So I guess there is no absolute solution to this problem, but switching to other methods such as Office Open XML development.

Windsail answered 14/3, 2012 at 15:47 Comment(0)
L
2

The two dots rule did not work for me. In my case I created a method to clean my resources as follows:

private static void Clean()
{
    workBook.Close();
    Marshall.ReleaseComObject(workBook);
    excel.Quit();
    CG.Collect();
    CG.WaitForPendingFinalizers();
}
Lemaster answered 12/12, 2013 at 22:37 Comment(0)
V
2

My solution

[DllImport("user32.dll")]
static extern int GetWindowThreadProcessId(int hWnd, out int lpdwProcessId);

private void GenerateExcel()
{
    var excel = new Microsoft.Office.Interop.Excel.Application();
    int id;
    // Find the Excel Process Id (ath the end, you kill him
    GetWindowThreadProcessId(excel.Hwnd, out id);
    Process excelProcess = Process.GetProcessById(id);

try
{
    // Your code
}
finally
{
    excel.Quit();

    // Kill him !
    excelProcess.Kill();
}
Variolous answered 18/6, 2014 at 9:34 Comment(0)
M
2

Here is a really easy way to do it:

[DllImport("User32.dll")]
static extern uint GetWindowThreadProcessId(IntPtr hWnd, out int lpdwProcessId);
...

int objExcelProcessId = 0;

Excel.Application objExcel = new Excel.Application();

GetWindowThreadProcessId(new IntPtr(objExcel.Hwnd), out objExcelProcessId);

Process.GetProcessById(objExcelProcessId).Kill();
Meemeece answered 2/4, 2019 at 20:24 Comment(0)
T
1

I think that some of that is just the way that the framework handles Office applications, but I could be wrong. On some days, some applications clean up the processes immediately, and other days it seems to wait until the application closes. In general, I quit paying attention to the details and just make sure that there aren't any extra processes floating around at the end of the day.

Also, and maybe I'm over simplifying things, but I think you can just...

objExcel = new Excel.Application();
objBook = (Excel.Workbook)(objExcel.Workbooks.Add(Type.Missing));
DoSomeStuff(objBook);
SaveTheBook(objBook);
objBook.Close(false, Type.Missing, Type.Missing);
objExcel.Quit();

Like I said earlier, I don't tend to pay attention to the details of when the Excel process appears or disappears, but that usually works for me. I also don't like to keep Excel processes around for anything other than the minimal amount of time, but I'm probably just being paranoid on that.

Terza answered 1/10, 2008 at 17:47 Comment(0)
R
1

As some have probably already written, it's not just important how you close the Excel (object); it's also important how you open it and also by the type of the project.

In a WPF application, basically the same code is working without or with very few problems.

I have a project in which the same Excel file is being processed several times for different parameter value - e.g. parsing it based on values inside a generic list.

I put all Excel-related functions into the base class, and parser into a subclass (different parsers use common Excel functions). I didn't want that Excel is opened and closed again for each item in a generic list, so I've opened it only once in the base class and close it in the subclass. I had problems when moving the code into a desktop application. I've tried many of the above mentioned solutions. GC.Collect() was already implemented before, twice as suggested.

Then I've decided that I will move the code for opening Excel to a subclass. Instead of opening only once, now I create a new object (base class) and open Excel for every item and close it at the end. There is some performance penalty, but based on several tests Excel processes are closing without problems (in debug mode), so also temporary files are removed. I will continue with testing and write some more if I will get some updates.

The bottom line is: You must also check the initialize code, especially if you have many classes, etc.

Roster answered 11/4, 2013 at 14:1 Comment(0)
F
1

The accepted answer did not work for me. The following code in the destructor did the job.

if (xlApp != null)
{
    xlApp.Workbooks.Close();
    xlApp.Quit();
}

System.Diagnostics.Process[] processArray = System.Diagnostics.Process.GetProcessesByName("EXCEL");
foreach (System.Diagnostics.Process process in processArray)
{
    if (process.MainWindowTitle.Length == 0) { process.Kill(); }
}
Factorage answered 5/9, 2014 at 11:42 Comment(1)
social.msdn.microsoft.com/Forums/en-US/…Factorage
W
1

I am currently working on Office automation and have stumbled across a solution for this that works every time for me. It is simple and does not involve killing any processes.

It seems that by merely looping through the current active processes, and in any way 'accessing' an open Excel process, any stray hanging instance of Excel will be removed. The below code simply checks for processes where the name is 'Excel', then writes the MainWindowTitle property of the process to a string. This 'interaction' with the process seems to make Windows catch up and abort the frozen instance of Excel.

I run the below method just before the add-in which I am developing quits, as it fires it unloading event. It removes any hanging instances of Excel every time. In all honesty I am not entirely sure why this works, but it works well for me and could be placed at the end of any Excel application without having to worry about double dots, Marshal.ReleaseComObject, nor killing processes. I would be very interested in any suggestions as to why this is effective.

public static void SweepExcelProcesses()
{           
            if (Process.GetProcessesByName("EXCEL").Length != 0)
            {
                Process[] processes = Process.GetProcesses();
                foreach (Process process in processes)
                {
                    if (process.ProcessName.ToString() == "excel")
                    {                           
                        string title = process.MainWindowTitle;
                    }
                }
            }
}
Woolworth answered 2/8, 2016 at 14:32 Comment(0)
X
1

'This sure seems like it has been over-complicated. From my experience, there are just three key things to get Excel to close properly:

1: make sure there are no remaining references to the excel application you created (you should only have one anyway; set it to null)

2: call GC.Collect()

3: Excel has to be closed, either by the user manually closing the program, or by you calling Quit on the Excel object. (Note that Quit will function just as if the user tried to close the program, and will present a confirmation dialog if there are unsaved changes, even if Excel is not visible. The user could press cancel, and then Excel will not have been closed.)

1 needs to happen before 2, but 3 can happen anytime.

One way to implement this is to wrap the interop Excel object with your own class, create the interop instance in the constructor, and implement IDisposable with Dispose looking something like

That will clean up excel from your program's side of things. Once Excel is closed (manually by the user or by you calling Quit) the process will go away. If the program has already been closed, then the process will disappear on the GC.Collect() call.

(I'm not sure how important it is, but you may want a GC.WaitForPendingFinalizers() call after the GC.Collect() call but it is not strictly necessary to get rid of the Excel process.)

This has worked for me without issue for years. Keep in mind though that while this works, you actually have to close gracefully for it to work. You will still get accumulating excel.exe processes if you interrupt your program before Excel is cleaned up (usually by hitting "stop" while your program is being debugged).'

Xenogenesis answered 10/3, 2017 at 4:18 Comment(0)
S
1

My answer is late and its only purpose is to support the solution proposed by Govert.

Automating Excel or other COM objects from the COM-agnostic .NET world is a “tough nut,” as we say in German, and you can easily go nuts. I rely on the following steps:

  1. Native COM functions return an integer of type HRESULT whose value indicates success or failure of the function. In C# the HRESULT value is omitted and the retval parameter of the native COM function is the return value. A HRESULT that indicates a failure will result in an exception. Therefore, critical COM functions must be enclosed in a try/catch block.

  2. COM objects are represented in C# by smart variables that manage their own loading and uploading. Therefore, don’t Marshall.ReleaseComObject anything. That is the job of the Garbage Collection. References to COM objects behave in C# as smart pointers in C++ which aren’t released either.

  3. For each interaction with Excel, get one and only one instance ExcelApp of the Application interface and create a scope within which ExcelApp lives. This is necessary, because the CLR won’t free the resources of Excel before any reference to Excel goes out of scope. A new Excel process is started in the background. The best scope is the try part of a try/catch block since the loading of Excel may fail in which case an exception is thrown.

  4. Generate via Collection properties new objects like Workbook(s), Worksheet(s), and Cell(s). Don’t care for the voodoo one-dot-good, two-dot-bad rule, use as many references as you like, and as said before don’t Marshall.ReleaseComObject anything.

  5. When you are done with Excel, call the Quit function within the scope made for Excel handling. This should be the last statement within this scope. The Quit function is necessary to quit Excel but the process is not unloaded before all reference variables to this instance leave the scope. While your Excel instance is loaded, don’t allow any user actions that would bypass the Quit function.

Before you run my app, open the task manager and watch in the Processes tab the entries in background processes. When you start the program, a new Excel process entry appears in the list and stays there until the thread wakes up again after 5 seconds. After the call to the Quit function the variable ExcelApp goes out of scope unloading the Excel process, that gracefully vanishes from the list of background processes.

using System;
using System.Threading;
using Excel = Microsoft.Office.Interop.Excel;

class Program
{
  private static void DoSomething(Excel.Workbook Wb)
  {
    Excel.Worksheet NewWs = Wb.Worksheets.Add();
                        
    for (int i = 1; i < 10; i++)
    {
      NewWs.Cells[i, 1] = i;
    }

    Wb.Save();
    Wb.Close();
    //NewWs goes out of scope and will be released by the GC.
  }

  static void Main(string[] args)
  {
    try
    {
      Excel.Application ExcelApp = new Excel.Application();
      Excel.Workbook Wb = ExcelApp.Workbooks.Open(@"D:\ExcelFiles\\CSharpExample.xlsx");
      DoSomething(Wb);
      ExcelApp?.Quit(); //Don't forget!
      Thread.Sleep(5000);
      //ExcelApp and Wb go out of scope and will be released by the GC.
    }     
    catch (Exception ex)
    {
      Console.WriteLine(ex.Message);
    }
  }
}
Silversmith answered 29/9, 2019 at 6:46 Comment(0)
G
0

Use:

[DllImport("user32.dll")]
private static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint lpdwProcessId);

Declare it, add code in the finally block:

finally
{
    GC.Collect();
    GC.WaitForPendingFinalizers();
    if (excelApp != null)
    {
        excelApp.Quit();
        int hWnd = excelApp.Application.Hwnd;
        uint processID;
        GetWindowThreadProcessId((IntPtr)hWnd, out processID);
        Process[] procs = Process.GetProcessesByName("EXCEL");
        foreach (Process p in procs)
        {
            if (p.Id == processID)
                p.Kill();
        }
        Marshal.FinalReleaseComObject(excelApp);
    }
}
Gobbledegook answered 27/8, 2013 at 10:11 Comment(0)
B
0

So far it seems all answers involve some of these:

  1. Kill the process
  2. Use GC.Collect()
  3. Keep track of every COM object and release it properly.

Which makes me appreciate how difficult this issue is :)

I have been working on a library to simplify access to Excel, and I am trying to make sure that people using it won't leave a mess (fingers crossed).

Instead of writing directly on the interfaces Interop provides, I am making extension methods to make live easier. Like ApplicationHelpers.CreateExcel() or workbook.CreateWorksheet("mySheetNameThatWillBeValidated"). Naturally, anything that is created may lead to an issue later on cleaning up, so I am actually favoring killing the process as last resort. Yet, cleaning up properly (third option), is probably the least destructive and most controlled.

So, in that context I was wondering whether it wouldn't be best to make something like this:

public abstract class ReleaseContainer<T>
{
    private readonly Action<T> actionOnT;

    protected ReleaseContainer(T releasible, Action<T> actionOnT)
    {
        this.actionOnT = actionOnT;
        this.Releasible = releasible;
    }

    ~ReleaseContainer()
    {
        Release();
    }

    public T Releasible { get; private set; }

    private void Release()
    {
        actionOnT(Releasible);
        Releasible = default(T);
    }
}

I used 'Releasible' to avoid confusion with Disposable. Extending this to IDisposable should be easy though.

An implementation like this:

public class ApplicationContainer : ReleaseContainer<Application>
{
    public ApplicationContainer()
        : base(new Application(), ActionOnExcel)
    {
    }

    private static void ActionOnExcel(Application application)
    {
        application.Show(); // extension method. want to make sure the app is visible.
        application.Quit();
        Marshal.FinalReleaseComObject(application);
    }
}

And one could do something similar for all sorts of COM objects.

In the factory method:

    public static Application CreateExcelApplication(bool hidden = false)
    {
        var excel = new ApplicationContainer().Releasible;
        excel.Visible = !hidden;

        return excel;
    }

I would expect that every container will be destructed properly by the GC, and therefore automatically make the call to Quit and Marshal.FinalReleaseComObject.

Comments? Or is this an answer to the question of the third kind?

Brahmi answered 4/5, 2015 at 13:12 Comment(0)
P
0

Just to add another solution to the many listed here, using C++/ATL automation (I imagine you could use something similar from VB/C#??)

Excel::_ApplicationPtr pXL = ...
  :
SendMessage ( ( HWND ) m_pXL->GetHwnd ( ), WM_DESTROY, 0, 0 ) ;

This works like a charm for me...

Praxiteles answered 7/4, 2016 at 12:29 Comment(0)
K
0

There i have an idea,try to kill the excel process you have opened:

  1. before open an excelapplication,get all the process ids named oldProcessIds.
  2. open the excelapplication.
  3. get now all the excelapplication process ids named nowProcessIds.
  4. when need to quit,kill the except ids between oldProcessIds and nowProcessIds.

    private static Excel.Application GetExcelApp()
         {
            if (_excelApp == null)
            {
                var processIds = System.Diagnostics.Process.GetProcessesByName("EXCEL").Select(a => a.Id).ToList();
                _excelApp = new Excel.Application();
                _excelApp.DisplayAlerts = false;
    
                _excelApp.Visible = false;
                _excelApp.ScreenUpdating = false;
                var newProcessIds = System.Diagnostics.Process.GetProcessesByName("EXCEL").Select(a => a.Id).ToList();
                _excelApplicationProcessId = newProcessIds.Except(processIds).FirstOrDefault();
            }
    
            return _excelApp;
        }
    
    public static void Dispose()
        {
            try
            {
                _excelApp.Workbooks.Close();
                _excelApp.Quit();
                System.Runtime.InteropServices.Marshal.ReleaseComObject(_excelApp);
                _excelApp = null;
                GC.Collect();
                GC.WaitForPendingFinalizers();
                if (_excelApplicationProcessId != default(int))
                {
                    var process = System.Diagnostics.Process.GetProcessById(_excelApplicationProcessId);
                    process?.Kill();
                    _excelApplicationProcessId = default(int);
                }
            }
            catch (Exception ex)
            {
                _excelApp = null;
            }
    
        }
    
Kyat answered 19/12, 2018 at 3:6 Comment(0)
B
0

Tested with Microsoft Excel 2016

A really tested solution.

To C# Reference please see: https://mcmap.net/q/53804/-how-do-i-properly-clean-up-excel-interop-objects

To VB.net Reference please see: https://mcmap.net/q/55195/-best-way-to-release-excel-interop-com-object

1 include the class job

2 implement the class to handle the apropiate dispose of excel proces

Brownley answered 4/1, 2019 at 19:26 Comment(0)
U
0

I had this same problem getting PowerPoint to close after newing up the Application object in my VSTO AddIn. I tried all the answers here with limited success.

This is the solution I found for my case - DONT use 'new Application', the AddInBase base class of ThisAddIn already has a handle to 'Application'. If you use that handle where you need it (make it static if you have to) then you don't need to worry about cleaning it up and PowerPoint won't hang on close.

Uncovered answered 2/7, 2019 at 18:25 Comment(0)
O
0

Of the three general strategies considered in other answers, killing the excel process is clearly a hack, whereas invoking the garbage collector is a brutal shotgun approach meant to compensate for incorrect deallocation of COM-objects. After lots of experimentation and rewriting the management of COM objects in my version-agnostic and late-bound wrapper, I have come to the conclusion that accurate and timely invocations of Marshal.ReleaseComObject() is the most efficient and elegant strategy. And no, you do not ever need FinalReleaseComObject(), because in a well-writtin program each COM acquired on once and therefore requires a single decrement of the reference counter.

One shall make sure to release every single COM object, preferably as soon as it is no longer needed. But it is perfectly possible to release everything right after quitting the Excel application, at the only expense of higher memory usage. Excel will close as expected as long as one does not loose or forget to release a COM object.

The simplest and most obvious aid in the process is wrapping every interop object into a .NET class implementing IDisposable, where the Dispose() method invokes ReleaseComObject() on its interop object. Doing it in the destructor, as proposed in here, makes no sense because destructors are non-deterministic.

Show below is our wrapper's method that obtains a cell from WorkSheet bypassing the intermediate Cells member. Notice the way it disposes of the intermediate object after use:

public ExcelRange XCell( int row, int col)
{   ExcelRange anchor, res;
    using( anchor = Range( "A1") )
    {   res = anchor.Offset( row - 1, col - 1 );  }
    return res;
}

The next step may be a simple memory manager that will keep track of every COM object obtained and make sure to release it after Excel quits if the user prefers to trade some RAM usage for simpler code.

Futher reading

  1. How to properly release Excel COM objects,
  2. Releasing COM objects: Garbage Collector vs. Marshal.RelseaseComObject.
Oleograph answered 2/12, 2020 at 23:0 Comment(0)
R
0

I really like when things clean up after them selves... So I made some wrapper classes that do all the cleanup for me! These are documented further down.

The end code is quite readable and accessible. I haven't yet found any phantom instances of Excel running after I Close() the workbooks and Quit() the application (besides where I debug and close the app mid process).

function void OpenCopyClose() {
  var excel = new ExcelApplication();
  var workbook1 = excel.OpenWorkbook("C:\Temp\file1.xslx", readOnly: true);
  var readOnlysheet = workbook1.Worksheet("sheet1");

  var workbook2 = excel.OpenWorkbook("C:\Temp\file2.xslx");
  var writeSheet = workbook.Worksheet("sheet1");

  // do all the excel manipulation

  // read from the first workbook, write to the second workbook.
  var a1 = workbook1.Cells[1, 1];
  workbook2.Cells[1, 1] = a1

  // explicit clean-up
  workbook1.Close(false);
  workbook2 .Close(true);
  excel.Quit();
}

Note: You can skip the Close() and Quit() calls but if you are writing to an Excel document you will at least want to Save(). When the objects go out of scope (the method returns) the class finalizers will automatically kick in and do any cleanup. Any references to COM objects from the Worksheet COM object will automatically be managed and cleaned up as long as you are careful with the scope of your variables, eg keep variables local to the current scope only when storing references to COM objects. You can easily copy values you need to POCOs if you need, or create additional wrapper classes as discussed below.

To manage all this, I have created a class, DisposableComObject, that acts as a wrapper for any COM object. It implements the IDisposable interface and also contains a finalizer for those that don't like using.

The Dispose() method calls Marshal.ReleaseComObject(ComObject) and then sets the ComObjectRef property to null.

The object is in a disposed state when the private ComObjectRef property is null.

If the ComObject property is accessed after being disposed, a ComObjectAccessedAfterDisposeException exception is thrown.

The Dispose() method can be called manually. It is also called by the finalizer, at the conclusion of a using block, and for using var at the conclusion of the scope of that variable.

The top level classes from Microsoft.Office.Interop.Excel, Application, Workbook, and Worksheet, get their own wrapper classes where each are subclasses of DisposableComObject

Here is the code:

/// <summary>
/// References to COM objects must be explicitly released when done.
/// Failure to do so can result in odd behavior and processes remaining running after the application has stopped.
/// This class helps to automate the process of disposing the references to COM objects.
/// </summary>
public abstract class DisposableComObject : IDisposable
{
    public class ComObjectAccessedAfterDisposeException : Exception
    {
        public ComObjectAccessedAfterDisposeException() : base("COM object has been accessed after being disposed") { }
    }

    /// <summary>The actual COM object</summary>
    private object ComObjectRef { get; set; }

    /// <summary>The COM object to be used by subclasses</summary>
    /// <exception cref="ComObjectAccessedAfterDisposeException">When the COM object has been disposed</exception>
    protected object ComObject => ComObjectRef ?? throw new ComObjectAccessedAfterDisposeException();

    public DisposableComObject(object comObject) => ComObjectRef = comObject;

    /// <summary>
    /// True, if the COM object has been disposed.
    /// </summary>
    protected bool IsDisposed() => ComObjectRef is null;

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this); // in case a subclass implements a finalizer
    }

    /// <summary>
    /// This method releases the COM object and removes the reference.
    /// This allows the garbage collector to clean up any remaining instance.
    /// </summary>
    /// <param name="disposing">Set to true</param>
    protected virtual void Dispose(bool disposing)
    {
        if (!disposing || IsDisposed()) return;
        Marshal.ReleaseComObject(ComObject);
        ComObjectRef = null;
    }

    ~DisposableComObject()
    {
        Dispose(true);
    }
}

There is also a handy generic subclass which makes usage slightly easier.

public abstract class DisposableComObject<T> : DisposableComObject
{
    protected new T ComObject => (T)base.ComObject;

    public DisposableComObject(T comObject) : base(comObject) { }
}

Finally, we can use DisposableComObject<T> to create our wrapper classes for the Excel interop classes.

The ExcelApplication subclass has a reference to a new Excel application instance and is used to open workbooks.

OpenWorkbook() returns an ExcelWorkbook which is also a subclass of DisposableComObject.

Dispose() has been overridden to quit the Excel application before calling the base Dispose() method. Quit() is an alias of Dispose().

public class ExcelApplication : DisposableComObject<Application>
{
    public class OpenWorkbookActionCancelledException : Exception
    {
        public string Filename { get; }

        public OpenWorkbookActionCancelledException(string filename, COMException ex) : base($"The workbook open action was cancelled. {ex.Message}", ex) => Filename = filename;
    }

    /// <summary>The actual Application from Interop.Excel</summary>
    Application App => ComObject;

    public ExcelApplication() : base(new Application()) { }

    /// <summary>Open a workbook.</summary>
    public ExcelWorkbook OpenWorkbook(string filename, bool readOnly = false, string password = null, string writeResPassword = null)
    {
        try
        {
            var workbook = App.Workbooks.Open(Filename: filename, UpdateLinks: (XlUpdateLinks)0, ReadOnly: readOnly, Password: password, WriteResPassword: writeResPassword, );

            return new ExcelWorkbook(workbook);
        }
        catch (COMException ex)
        {
            // If the workbook is already open and the request mode is not read-only, the user will be presented
            // with a prompt from the Excel application asking if the workbook should be opened in read-only mode.
            // This exception is raised when when the user clicks the Cancel button in that prompt.
            throw new OpenWorkbookActionCancelledException(filename, ex);
        }
    }

    /// <summary>Quit the running application.</summary>
    public void Quit() => Dispose(true);

    /// <inheritdoc/>
    protected override void Dispose(bool disposing)
    {
        if (!disposing || IsDisposed()) return;
        App.Quit();
        base.Dispose(disposing);
    }
}

ExcelWorkbook also subclasses DisposableComObject<Workbook> and is used to open worksheets.

The Worksheet() methods returns ExcelWorksheet which, you guessed it, is also an subclass of DisposableComObject<Workbook>.

The Dispose() method is overridden and fist closes the worksheet before calling the base Dispose().

NOTE: I've added some extension methods which is uses to iterate over Workbook.Worksheets. If you get compile errors, this is why. Ill add the extension methods at the end.

public class ExcelWorkbook : DisposableComObject<Workbook>
{
    public class WorksheetNotFoundException : Exception
    {
        public WorksheetNotFoundException(string message) : base(message) { }
    }

    /// <summary>The actual Workbook from Interop.Excel</summary>
    Workbook Workbook => ComObject;

    /// <summary>The worksheets within the workbook</summary>
    public IEnumerable<ExcelWorksheet> Worksheets => worksheets ?? (worksheets = Workbook.Worksheets.AsEnumerable<Worksheet>().Select(w => new ExcelWorksheet(w)).ToList());
    private IEnumerable<ExcelWorksheet> worksheets;

    public ExcelWorkbook(Workbook workbook) : base(workbook) { }

    /// <summary>
    /// Get the worksheet matching the <paramref name="sheetName"/>
    /// </summary>
    /// <param name="sheetName">The name of the Worksheet</param>
    public ExcelWorksheet Worksheet(string sheetName) => Worksheet(s => s.Name == sheetName, () => $"Worksheet not found: {sheetName}");

    /// <summary>
    /// Get the worksheet matching the <paramref name="predicate"/>
    /// </summary>
    /// <param name="predicate">A function to test each Worksheet for a macth</param>
    public ExcelWorksheet Worksheet(Func<ExcelWorksheet, bool> predicate, Func<string> errorMessageAction) => Worksheets.FirstOrDefault(predicate) ??  throw new WorksheetNotFoundException(errorMessageAction.Invoke());

    /// <summary>
    /// Returns true of the workbook is read-only
    /// </summary>
    public bool IsReadOnly() => Workbook.ReadOnly;

    /// <summary>
    /// Save changes made to the workbook
    /// </summary>
    public void Save()
    {
        Workbook.Save();
    }

    /// <summary>
    /// Close the workbook and optionally save changes
    /// </summary>
    /// <param name="saveChanges">True is save before close</param>
    public void Close(bool saveChanges)
    {
        if (saveChanges) Save();
        Dispose(true);
    }

    /// <inheritdoc/>
    protected override void Dispose(bool disposing)
    {
        if (!disposing || IsDisposed()) return;
        Workbook.Close();
        base.Dispose(disposing);
    }
}

Finally, the ExcelWorksheet.

UsedRows() simply returns an enumerable of unwrapped Microsoft.Office.Interop.Excel.Range objects. I haven't yet encountered a situation where COM objects accessed from properties of the Microsoft.Office.Interop.Excel.Worksheet object need to manually wrapped like was needed with Application, Workbook, and Worksheet. These all seem to clean them selves up automatically. Mostly, I was just iterating over Ranges and getting or setting values, so my particular use-case isn't as advanced as the available functionality.

There is no override of Dispose() in this case as no special action needs to take place for worksheets.

public class ExcelWorksheet : DisposableComObject<Worksheet>
{
    /// <summary>The actual Worksheet from Interop.Excel</summary>
    Worksheet Worksheet => ComObject;

    /// <summary>The worksheet name</summary>
    public string Name => Worksheet.Name;

    // <summary>The worksheets cells (Unwrapped COM object)</summary>
    public Range Cells => Worksheet.Cells;

    public ExcelWorksheet(Worksheet worksheet) : base(worksheet) { }

    /// <inheritdoc cref="WorksheetExtensions.UsedRows(Worksheet)"/>
    public IEnumerable<Range> UsedRows() => Worksheet.UsedRows().ToList();
}

It is possible to add even more wrapper classes. Just add additional methods to ExcelWorksheet as needed and return the COM object in a wrapper class. Just copy what we did when wrapping the workbook via ExcelApplication.OpenWorkbook() and ExcelWorkbook.WorkSheets.

Some useful extension methods:

public static class EnumeratorExtensions
{
    /// <summary>
    /// Converts the <paramref name="enumerator"/> to an IEnumerable of type <typeparamref name="T"/>
    /// </summary>
    public static IEnumerable<T> AsEnumerable<T>(this IEnumerable enumerator)
    {
        return enumerator.GetEnumerator().AsEnumerable<T>();
    }

    /// <summary>
    /// Converts the <paramref name="enumerator"/> to an IEnumerable of type <typeparamref name="T"/>
    /// </summary>
    public static IEnumerable<T> AsEnumerable<T>(this IEnumerator enumerator)
    {
        while (enumerator.MoveNext()) yield return (T)enumerator.Current;
    }

    /// <summary>
    /// Converts the <paramref name="enumerator"/> to an IEnumerable of type <typeparamref name="T"/>
    /// </summary>
    public static IEnumerable<T> AsEnumerable<T>(this IEnumerator<T> enumerator)
    {
        while (enumerator.MoveNext()) yield return enumerator.Current;
    }
}

public static class WorksheetExtensions
{
    /// <summary>
    /// Returns the rows within the used range of this <paramref name="worksheet"/>
    /// </summary>
    /// <param name="worksheet">The worksheet</param>
    public static IEnumerable<Range> UsedRows(this Worksheet worksheet) =>
        worksheet.UsedRange.Rows.AsEnumerable<Range>();
}
Rebec answered 19/11, 2021 at 6:33 Comment(0)
F
-1

Excel is not designed to be programmed via C++ or C#. The COM API is specifically designed to work with Visual Basic, VB.NET, and VBA.

Also all the code samples on this page are not optimal for the simple reason that each call must cross a managed/unmanaged boundary and further ignore the fact that the Excel COM API is free to fail any call with a cryptic HRESULT indicating the RPC server is busy.

The best way to automate Excel in my opinion is to collect your data into as big an array as possible / feasible and send this across to a VBA function or sub (via Application.Run) which then performs any required processing. Furthermore - when calling Application.Run - be sure to watch for exceptions indicating excel is busy and retry calling Application.Run.

Fertilization answered 19/6, 2011 at 0:16 Comment(8)
C# and VB.NET all run under the CLR,so it can't be designed for VB.NET and not C#. They are the ultimately the same thing, just with different language semantics for building an application.Condor
Please try calling the Run method from the excel Application object in C# ( ver 3.0 and earlier) or C++. Then try doing the same from VB.net. After the 10th or 12th missing parameter you pass in - you will probably realize what I meant :]Fertilization
Also - like you mentioned - C# and VB.net are both CLR languages. They offer programmers varying subsets of the CLR's functionality along with various syntactic sugar. It just so happens that the subset offered by VB.net makes com and excel programming easier.Fertilization
But again, thats just semantics of the language (prior to v3.5). I do indeed feel the pain of Application.Run(Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value,,Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value); which VB has had, even before .NET. The managed libraries of Microsoft.Office.Tools DLL makes it easy peesy to do all this stuff without any COM cleanup at all, as its all managed wrapper.Condor
Excel is not designed to be programmed via C++ or C# - is incorrect information.Creed
@Jeremy - it's true though. It's primarily designed to be programmed via late bound clients like VBA and VB. Using c++ or c# to work with Excel is a nightmare.Fertilization
We can agree to disagree, IMHO its far from a nightmare. Using C# .Net 4.0 with optional parameter support is practically the same as VB.Net. In my experience more companies are porting old VBA code to C# rather than VB.Net.Creed
Excel is an automation server written in C++, so of course it is best to automate from C++, but with the primary Microsoft.Office.Interop.Excel assembly, it is just as easy to handle in C# as in VBA, see my answer.Silversmith
S
-1

This is the only way that really works for me

        foreach (Process proc in System.Diagnostics.Process.GetProcessesByName("EXCEL"))
        {
            proc.Kill();
        }
Sexlimited answered 14/2, 2017 at 7:55 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.