在Microsoft HPC上通过Com-interop C＃API打开一个excel文件
我正在Windows hpc上工作，我试图做一个运行在网格上的macros的macros的小程序。 我正在使用Com Interop API
它在我的电脑上工作正常，它运行不同的VBAmacros，但是当我在网格上使用它时，它不再工作。 Open方法无法正常工作。
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); 这是从法语翻译的例外：
发现exception：types：System.Runtime.InteropServices.COMException消息：Microsoft Office Excel无法访问该文件
\服务器\path\ TEST.XLS。 有多种可能性：
- 该文件的名称或path不存在
- 该文件当前用于另一个程序
- 您尝试使用的工作簿具有已经打开的另一个工作簿的相同名称
来源：Microsoft Office Excel
Stacktrace：在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）位于E：\ path \ ExcelFile.cs的namespace.ExcelFile.readExcel（Application excelApp）中：第37行
我试图从计算节点访问该文件与应用程序中使用相同的帐户，它工作正常。 我可以访问它，似乎没有其他程序正在使用它，并且Excel未打开。
编辑：我也可以在计算节点上运行我的小应用程序，而不使用Microsoft API（头节点）
我错过了什么？
因此，在处理使用HPC时实例化应用程序（如办公室COM）的COM API时，需要记住一些事情。 您在本地运行时似乎已经覆盖了权限; 然而，当运行在一个服务的幌子，它有点棘手。
HPC嘲笑IIS，因为它承载您的服务; 因此必须同样对待; 在IIS中，当您需要通过WCF服务运行这些应用程序时，您通常指定允许AppPool的身份启动configuration文件，该configuration文件将使应用程序configuration文件目录可以访问以执行操作。 您还必须确保您对应用程序池进行的任何设置才能在不使用HPC的情况下运行这些服务，这些设置也会反映在HPC服务注册目录中的Service Config文件中。
如果此应用程序是32位应用程序（您的应用程序不是COM +），则必须向SericeRegistration标记添加条目，以便在IIS中configuration应用程序池以接受x86应用程序的方式指定此项。 默认情况下，HPC在Broker的configuration文件中内部指定architecture =“X64”。
<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>
确保在以下位置有一个名为“桌面”的目录：
C：\ Windows \ SysWOW64 \ config \ systemprofile \ C：\ Windows \ System32 \ config \ systemprofile \
这适用于群集中的所有节点; 如果您只运行32位窗口，则可以忽略SysWow64目录位置。
接下来，您需要去检查Office Excel的DCOM设置。 要做到这一点，只需打开运行对话框，然后键入：
Dcomcnfg -32
我们添加-32来打开32位DCOMconfiguration，因为Office只提供32位COM +对象来使用（对于2010及以下版本，我无法对365/2013发表评论）。
确保在“在这台计算机上运行应用程序”位置下被选中。
确保在“安全”下，您的帐户完全控制“启动和激活权限”，“访问权限”和“configuration权限”。 如果您的用户是该系统上的pipe理员帐户，则不需要进行任何更改，因为pipe理员默认具有这些function。
如果运行此任务的计算节点是Windows Server 2008 R2计算机，请在“标识”选项卡 – “启动用户”中指定。 如果运行此任务的计算节点是Windows Server 2012计算机，请指定 – “此用户”并提供您的凭据; 或指定交互式用户。 后者的运气很不好，所以我build议前者。
一旦你注意到了这些事情，你的HPC服务应该正确执行应用程序，而不会看到那些Pesky失败的COM +错误。
另外，您还需要确保在退出时清理应用程序; 我强烈build议你写一个小例程作为你的WCF服务的终于，当你完成后，杀死了Excel的过程; 我发现，在HPC下使用Excel时，通常的终止应用程序的方法显然是不可靠的。
当你说你可以访问它，你的意思是通过文件系统使用资源pipe理器，或通过代码？ 是否有可能你的代码不喜欢的path或认为有权限问题？
如果添加如下内容，结果如何？
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); }