none
Excel 2013 Automation does not work from a Windows Service RRS feed

  • Question

  • Hi,

    We are using an Excel automation code from a Windows Service via Excel.Application OLE calls (from C++)

    It fails at the stage of creating Excel.Application object

    OleServer = CreateObject("Excel.Application");

    The same code works correctly with Excel 2010.

    Could you please advise?

    Thanks,
    Maurycy.

    Monday, October 21, 2013 11:54 AM

Answers

  • The problem you mentioned (cannot create Office automation object when running in a Windows service) is described in KB 257757. The article also notes:

    Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.

    Depending on what you want to do, there might be alternatives to Office automation, for example, using a third-party library that can natively read or write Excel documents.

    Tuesday, October 22, 2013 12:17 PM

All replies

  • Hi Maurycy,

    Would you give me some error information ?Is it the VBA Code ?I try to test this code in Excel 2013 using VBA ,but it work fine,The new excel application is created. My code is below and please correct me if I have any misunderstand.

    Dim OleServer As Application
    Set OleServer = CreateObject("Excel.Application")
    OleServer.Visible = True

    And i found some information about run-time error when you automate Office applications ,you can refer the Microsoft KB article :

    http://support.microsoft.com/kb/828550

    Tuesday, October 22, 2013 11:16 AM
  • Hi,

    We actually use Windows Service implemented in Builder C++ (Embarcadero).

    The code that you have provided in VBA is equivalent to our C++ code.

    The code to create Excel.Application OleServer works correctly when we execute it from Windows GUI application. The same code executed from a Windows Service cannot create such object.

    As advised in the KB828550 I have run Excel 2013 with /RegServer option but it didn't resolve the issue.

    HKEY_CLASSES_ROOT\Excel.Application\CLSID points to {00024500-0000-0000-C000-000000000046}

    I can see the corresponding entry under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID

    Our Windows Service is 32-bit running on Windows 7 64-bit

    Thanks,
    Maurycy.

    Tuesday, October 22, 2013 11:35 AM
  • Just to be clear - I've tried that code that you have provided from Office VBA and I get back OleServer reference for Excel.Application 
    Tuesday, October 22, 2013 11:37 AM
  • The problem you mentioned (cannot create Office automation object when running in a Windows service) is described in KB 257757. The article also notes:

    Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.

    Depending on what you want to do, there might be alternatives to Office automation, for example, using a third-party library that can natively read or write Excel documents.

    Tuesday, October 22, 2013 12:17 PM
  • We do understand that this is not recommended or supported way of automating Office actions.

    For new projects we use C# 3rd party library accessing directly XLSX - no installation of Excel is required.

    This is an inherited legacy code which works with Excel 2010 but it no longer works with Excel 2013. We are looking for a workaround/fix to minimise the impact of the platform upgrade.

    Tuesday, October 22, 2013 12:46 PM
  • Hello,

    Any fix to this problem available ? We are in 2018 and I can't use Dynamics Ax 2009 with Excel 2013 Ole Automation. It works with Excel 2010.

    Thank you


    • Edited by Mihaila Thursday, June 21, 2018 9:39 AM
    Thursday, June 21, 2018 9:39 AM
  • Hi Mihaila,

    I think it's really time to remove dependency on Excel which is 5+ years old and work with native XLSX file creation.

    Thanks,
    Mau.

    Thursday, June 21, 2018 10:00 AM
  • I'm not 100% sure about this but Excel 2010 is licensed to the PC so any user or service can run it.  Excel 2013 is licensed to a user so a system process isn't allowed to run it.  I was able to get it working under Apache 32-bit web server but I had to run Apache under a licensed user.  I recommend using EPPLUS ported to .NET Core. 
    Thursday, June 21, 2018 2:37 PM
  • I'm not sure what you mean by "fix". By design, the Office apps do not support multi-threading and running from service based apps that prevent user interaction with the UI.

    If your app is not running from a service based app then you will need to post a new question and identify the issue that you are encountering.


    Paul ~~~~ Microsoft MVP (Visual Basic)

    Tuesday, June 26, 2018 5:00 PM