locked
Excel instance will not stop after calling asp.net page RRS feed

  • Question

  • User-1732200463 posted

    Hello Forum Folks,

     

    I'm attempting to download an Excel spreadsheet, adjust the columns as needed and save it as a .prn file so that it can be uploaded to an AS400.  I'm currently running this all through VisualStudio 2008 before I try to put this all on a IIS server.  The problem here is after I adjust the columns and close excel, excel continues to run in the background. Here is the code dealing with Excel:

     

      

    1                // get the workbook from the filepath.
    2                oXL = new Excel.Application();
    3                oWB = (Excel._Workbook)(oXL.Workbooks.Open(HttpContext.Current.Server.MapPath(filePath),
    4                                                            Type.Missing, Type.Missing, Type.Missing, Type.Missing,
    5                                                            Type.Missing, Type.Missing, Type.Missing, Type.Missing,
    6                                                            Type.Missing, Type.Missing, Type.Missing, Type.Missing,
    7                                                            Type.Missing, Type.Missing));
    8                oSheet = (Excel._Worksheet)oWB.Worksheets.get_Item(1);
    9    
    10               // make sure the column widths are correct - 
    11               foreach (DictionaryEntry de in columnWidths)
    12               {
    13                   oRange = (Excel.Range)oSheet.Columns[de.Key,Type.Missing];
    14                   oRange.ColumnWidth = de.Value;
    15               }
    16   
    17               // save as prn file
    18               middleFilePath = HttpContext.Current.Server.MapPath("~/UploadExcel/" + middleFile);
    19               oWB.SaveAs(middleFilePath, Excel.XlFileFormat.xlTextPrinter, Type.Missing, Type.Missing,
    20                           false, false, Excel.XlSaveAsAccessMode.xlNoChange, Excel.XlSaveConflictResolution.xlLocalSessionChanges, 
    21                           Type.Missing, Type.Missing, Type.Missing, Type.Missing);
    22   
    23               // exit out of excel, otherwise an instance of it keeps running.
    24               oWB.Close(false,Type.Missing,Type.Missing);
    25               Excel.Workbooks tmp = oXL.Workbooks;
    26               tmp.Close();
    27               System.Runtime.InteropServices.Marshal.ReleaseComObject(tmp);
    28               tmp = null;
    29               oXL.Quit();
    30               System.Runtime.InteropServices.Marshal.ReleaseComObject(oRange);
    31               System.Runtime.InteropServices.Marshal.ReleaseComObject(oSheet);
    32               System.Runtime.InteropServices.Marshal.ReleaseComObject(oWB);
    33               System.Runtime.InteropServices.Marshal.ReleaseComObject(oXL);
    34               oRange = null;
    35               oSheet = null;
    36               oWB = null;
    37               oXL = null;
    38               GC.Collect();
    39   
    

     As you can see at the end of the code, I am releasing all the objects and trying to get the GC to dispose of them.  No luck.  I have also tried to manipulate the DCOMCNFG to allow everyone full launch, access and configuration permissions.  Still nothing.  Any hints or help is greatly appreciated.

     

    Thanks,

    Andy

    Tuesday, November 4, 2008 6:47 PM

All replies

  • User-1827453801 posted

    Office was not designed to (and never will be) be used by a web server application. Microsoft expressly advises this as a bad idea. Every time I've seen people attempt this it's ended badly.

    That said, you could enumerate the running processes and 'kill' the excel process.

    See the process class: http://msdn.microsoft.com/en-us/library/system.diagnostics.process.aspx

    Tuesday, November 4, 2008 7:58 PM
  • User-1732200463 posted

     Thanks worldspawn. I will give that a try.

     Do you know where I can find documentation from Microsoft stating that Office apps in a Web application is a bad idea?  It would help tremendously in getting my superiors to try another route.

     

    Thanks again!

    --Andy

    Wednesday, November 5, 2008 10:23 AM
  • User-1827453801 posted

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;q257757

    This page spells out all the evil. Plus working with com objects just sux. Love those 'Unknown Error 0x8000500' errors. So descriptive!

    Wednesday, November 5, 2008 5:45 PM