Excel not closing

Try this code:

private void NAR(object o)
{
     try
     {
          System.Runtime.InteropServices.Marshal.ReleaseComObject(o);
     }
     catch {}
     finally
     {
          o = null;
     }
}

/// When you quit Excel app, please call:
excelApp.Quit();
NAR(excelApp);

/// Remember that, if you already use: Workbooks , Sheets ... You also must use NAR to release all of them.

I tried the code you submitted and the instances of Excel are still there after the program runs just as before.

without opening the excel directly you can read the excel data by using  
System.Data.OleDbConnection object.  

Read entire data into dataset.... then close the connection object..... this is the best approach......


https://www.experts-exchange.com/questions/20972338/reading-open-Excel-file.html


itsvtk

Here is the sample code for readin excel file without opening excel file.......


using System;
using System.Data;
using System.Data.OleDb;

class Demo
{
      public static void Main()
      {
            OleDbConnection con = new OleDbConnection( "Provider=Microsoft.Jet.OleDb.4.0;Data Source=F:\\Book1.xls;Extended Properties=\"Excel 8.0;HDR=YES;\"" );
            con.Open();
            OleDbDataAdapter da = new OleDbDataAdapter( "select * from [Sheet1$]", con );
            DataSet ds = new DataSet();
            da.Fill( ds, "Sheet1" );
            con.Close();
            
            foreach( DataColumn dc in ds.Tables[0].Columns )
                        Console.Write( dc.ColumnName + "\t" );
            
            Console.Write( "\n" );
            
            foreach( DataRow dr in ds.Tables[0].Rows )
            {
                  foreach( DataColumn dc in ds.Tables[0].Columns )
                        Console.Write( dr[dc.ColumnName].ToString() + "\t" );
                  Console.Write( "\n" );
            }
                        
            ds = null;
      }
}


after reading i checked my excel file is not exists in Task Manager...

itsvtk

Don't forget to change the excel file path and sheet name...

1)  OleDbConnection con = new OleDbConnection( "Provider=Microsoft.Jet.OleDb.4.0;Data Source=<Excel File Path>;Extended Properties=\"Excel 8.0;HDR=YES;\"" );


2)  OleDbDataAdapter da = new OleDbDataAdapter( "select * from [<Excel Sheet Name>$]", con );


itsvtk

Hello itsvtk,

Thanks for the code but I've used Excel with ADO.NET and you're right, it works fine.  In this case though I MUST run Excel.  It's part of an automation process and along with needing some of the values that are in the spreadsheet, the process must save the spreadsheet out as a tab-delimited file, make changes to the tab-delimited file (that will be used by another process) and then re-open the tab-delimited file in Excel and save it as an Excel (.xls) file again.  I know it sounds a little strange but it's part of a much larger process that needs all this.  So, using Excel with ADO isn't going to do the job.

Thanks and Regards,
Rob

Hi rkellow

You should close all you workbook before close your Excel Application.
here is a sample code.

     foreach (Excel.Workbook book in excelApp.Workbooks)
     {
          //You should set the Saved property of a Workbook is set to True, Excel will not prompt you to save it.
          book.Saved = true;
          //Close the book
          book.Close(false, Type.Missing, Type.Missing);
     }
     //quit application
     excelApp.Quit();
     NAR(excelApp);

Hi melodiesoflife,

Thanks for the sample but I'm already doing that and still the instance(s) (one for each time I run Excel) stays in memory.  I've worked on it more over the weekend and found a few things.  First, I checked on some other forums and it appears that others have the same problem but it seems isolated to Excel 2003 and I haven't found any threads where there is a resolution.  Second, I found that the instance of Excel goes away (everything works) if I don't open a workbook.  This is obviously kind of useless but it does prove that everything else is working correctly and the problem seems to lie in the workbook more than Excel itself.  Third, I then thought that it might be something unique to the workbook(s) I was opening for testing my application but again, no luck as I tested it with both a new empty workbook as well as a new workbook with some data in it.  Fourth, I wrote some code that calls the GetObject function with "Excel.Application" as a parameter that would just loop trying to get the Excel instance that was still left in memory and repeatedly try to close (destroy) it.  I based the loop on a counter and to continue as long as the counter was less than 1000 and yet the GetObject function still returned a valid Excel object (! IsNothing(excelApp)) this ran until the counter hit 1000.  So the app is finding the instance it is just unable to close it.  Lastly, (and possibly my temporary workaround) is I found that if I make Excel Visible and leave it open after my app is finished (don't call CloseExcel()) and then close it manually by clicking the Close button in Excel, the instance of Excel goes away.  For now I may just leave it open and that way at least I know there won't be a hundred instances of Excel sitting in memory.

Thanks for the feedback and let me know if you have any other thoughts.

--Rob

before closing the excel   make  "DisplayAlerts" to false

======================
Book.DisplayAlerts = False
======================

itsvtk

Hi itsvtk,

Thanks but that didn't do it either.  I just added "excelApp.DisplayAlerts = false;" as you suggested but the instance of Excel remained in memory.  It's making me crazy!

Thanks again,
Rob

Hello Everyone,

I was getting help on another forum with this problem as well and a person (Thank you Fredrik!) sent me a link to an article about this problem.  Here is the link http://www.mswordtalk.com/ftopic23462.html and the steps in this thread fixes the problem.  It turns out to be a "side-effect" of the Google Desktop search engine (I never would have guessed).  I just verified that everything works as soon as the Google COM Add-in is turned off in Excel.

Thanks for everyone's help,
Rob