Open a excel file through Com-interop C# API on microsoft HPC

Question

I'm working on a Windows hpc and I'm trying to make a small program which run excel's macro on the grid. I'm using the Com Interop API
It works fine on my computer, it runs the different VBA macros, but when I'm using it on the grid, it doesn't work anymore. The Open method doesn't work properly.

workBook = excelApp.Workbooks.Open(path, Type.Missing,false, Type.Missing, Type.Missing, Type.Missing, true, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing);

Here is the exception translated from french :

Exception Found: Type: System.Runtime.InteropServices.COMException Message: Microsoft Office Excel can't access the file

\server\path\test.xls. There is multiple possibilities :

• The file's name or the path doesn't existe
• The file is currently used par another program
• The workbook you are trying to use has the same name of another workbook already open

Source: Microsoft Office Excel

Stacktrace: at Microsoft.Office.Interop.Excel.Workbooks.Open(String Filename, Object UpdateLinks, Object ReadOnly, Object Format, Object Password, Object WriteResPassword, Object IgnoreReadOnlyRecommended, Object Origin, Object Delimiter, Object Editable, Object Notify, Object Converter, Object AddToMru, Object Local, Object CorruptLoad) at namespace.ExcelFile.readExcel(Application excelApp) in E:\path\ExcelFile.cs:line 37

I've tried to access the file from the compute node with the same account as the one used in the application and it works fine. I can access it, it seems that there is no other program using it, and Excel is not open.
Edit : I also can run my small application on the compute node without using the Microsoft API (head node)

What am I missing ?

Answer 1

So there are a few things to remember when dealing with COM API that instantiates an application (such as the office COM) when working with HPC. You seem to have already covered permissions when run locally; however when running under the guise of a service it gets a bit trickier.

HPC mocks IIS as it hosts your service; and as such has to be treated similarly; in IIS when you need to run one of these applications through a WCF Service you usually specify allowing the AppPool's identity to launch a profile which will give the application profile directories to access to perform actions. You also have to ensure that any settings you make to your app pools to run these services without HPC are also reflected within the Service Config file you place in the Service Registration directory for HPC.

If this application is a 32 bit application (your application not COM+) you must add an entry to the SericeRegistration Tag to specify this the same way you configure application pools in IIS to accept x86 applications. By Default HPC specifies architecture="X64" internally in the Broker's configuration file.

<microsoft.Hpc.Session.ServiceRegistration>
    <service assembly="C:\ServicesR2\OfficeService.dll"
      contract="OfficeService.IOfficeService" type="OfficeService.OfficeService"
      includeExceptionDetailInFaults="true" maxConcurrentCalls="0"
      serviceInitializationTimeout="60000" enableMessageLevelPreemption="true"
      stdError="" maxMessageSize="65536" soaDiagTraceLevel="Off"
      architecture="X86" />
</microsoft.Hpc.Session.ServiceRegistration>

Ensure that you have a directory called "Desktop" at the following locations:

C:\Windows\SysWOW64\config\systemprofile\ C:\Windows\System32\config\systemprofile\

This is for all nodes in the cluster; if you are only running 32 bit windows you can ignore the SysWow64 directory location.

Next you need to go and check the DCOM setup for Office Excel. To do this simply open a run dialogue and type:

Dcomcnfg -32

We add the -32 to open the 32 bit DCOM configuration as Office only supplies 32 bit COM+ objects to consume (well for 2010 and below, I cannot comment on 365/2013).

Ensure that under Location "Run Application on this Computer" is checked.

Ensure that under Security your account has full control for Launch and Activation Permissions, Access Permissions, and Configuration Permissions. If your user is an administrator account on this system you shouldn't need to make any changes as Admin's by default have these abilities.

If the compute node running this task is a Windows Server 2008 R2 machine specify in the Identity tab - "The Launching User". If the compute node running this task is a windows Server 2012 machine, specify - "This User" and provide your credentials; or specify interactive user. I had very little luck with the latter so I suggest the former.

Once you have taken care of these things your HPC Service should be properly executing the Application without seeing those Pesky failed COM+ errors.

Also, you will need to be extra sure that you cleanup the Application upon Exit; I highly suggest you write a small routine as a finally for your WCF Service that kills the excel process when you are done; I discovered that while utilizing Excel under HPC the usual methods of terminating the application just plain we not reliable.

Answer 2

When you say you can access it, do you mean through the file system using Explorer, or through code? Is it possible your code doesn't like the path or thinks there is a permissions issue?

If you add something like the following, what is the result?

 System.IO.FileInfo info = new System.IO.FileInfo(path);

 if(info.Exists)
 {
      System.Security.Permissions.FileIOPermission permission =
           new System.Security.Permissions.FileIOPermission(
               System.Security.Permissions.FileIOPermissionAccess.AllAccess, path);

       permission.Demand();
 }
 else{ 
      throw new System.IO.FileNotFoundException(path);
 }