2

私は Windows のマクロを実行する小さなプログラムを作成しようとしています。Com Interop API を使用して
います。私のコンピューターでは正常に動作し、さまざまな VBA マクロを実行しますが、グリッドで使用すると動作しなくなります。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);

フランス語から翻訳された例外は次のとおりです。

見つかった例外: タイプ: System.Runtime.InteropServices.COMException メッセージ: Microsoft Office Excel はファイルにアクセスできません

\サーバー\パス\test.xls. 複数の可能性があります:

  • ファイルの名前またはパスが存在しません
  • ファイルは現在、別のプログラムによって使用されています
  • 使用しようとしているブックには、既に開いている別のブックと同じ名前があります

出典: マイクロソフト オフィス エクセル

スタックトレース: 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

アプリケーションで使用されているものと同じアカウントで計算ノードからファイルにアクセスしようとしましたが、正常に動作します。私はそれにアクセスできます。それを使用している他のプログラムはないようで、Excel は開いていません。
編集: Microsoft API (ヘッド ノード) を使用せずに、コンピューティング ノードで小さなアプリケーションを実行することもできます

。

4

2 に答える 2

2

そのため、HPC を使用するときにアプリケーション (オフィス COM など) をインスタンス化する COM API を扱う際には、覚えておくべきことがいくつかあります。ローカルで実行するときは、既にアクセス許可をカバーしているようです。ただし、サービスを装って実行すると、少しトリッキーになります。

HPC は、サービスをホストするときに IIS をモックします。したがって、同様に扱われなければなりません。IIS では、WCF サービスを介してこれらのアプリケーションの 1 つを実行する必要がある場合、通常、AppPool の ID がプロファイルを起動できるように指定します。これにより、アクションを実行するためにアプリケーション プロファイル ディレクトリにアクセスできるようになります。また、HPC を使用せずにこれらのサービスを実行するためにアプリ プールに対して行ったすべての設定が、HPC のサービス登録ディレクトリに配置するサービス構成ファイルにも反映されていることを確認する必要があります。

このアプリケーションが 32 ビット アプリケーション (COM+ ではないアプリケーション) である場合は、ServiceRegistration タグにエントリを追加して、IIS で x86 アプリケーションを受け入れるようにアプリケーション プールを構成するのと同じ方法でこれを指定する必要があります。デフォルトでは、HPC は、ブローカーの構成ファイル内で 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>

次の場所に「Desktop」というディレクトリがあることを確認します。

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

これは、クラスター内のすべてのノードに適用されます。32 ビット ウィンドウのみを実行している場合は、SysWow64 ディレクトリの場所を無視できます。

次に、Office Excel の DCOM セットアップを確認する必要があります。これを行うには、実行ダイアログを開いて次のように入力します。

Dcomcnfg -32

-32 を追加して 32 ビット DCOM 構成を開きます。Office は消費する 32 ビット COM+ オブジェクトしか提供しないためです (2010 以下では、365/2013 についてはコメントできません)。

[場所] で [このコンピューターでアプリケーションを実行する] がオンになっていることを確認します。

[セキュリティ] の下で、アカウントが起動とアクティブ化のアクセス許可、アクセス許可、および構成アクセス許可を完全に制御できることを確認してください。ユーザーがこのシステムの管理者アカウントである場合、管理者にはデフォルトでこれらの機能があるため、変更を加える必要はありません。

このタスクを実行している計算ノードが Windows Server 2008 R2 マシンである場合は、[ID] タブで [起動ユーザー] を指定します。このタスクを実行する計算ノードが Windows Server 2012 マシンの場合は、「このユーザー」を指定し、資格情報を入力します。または対話ユーザーを指定します。私は後者でほとんど運がなかったので、前者をお勧めします。

これらの処理が完了すると、HPC サービスはアプリケーションを適切に実行し、厄介な COM+ エラーが発生することはありません。

また、終了時にアプリケーションを確実にクリーンアップする必要があります。最後に、完了時に Excel プロセスを強制終了する WCF サービスの小さなルーチンを作成することを強くお勧めします。HPC で Excel を使用しているときに、アプリケーションを終了する通常の方法は信頼できないことを発見しました。

于 2013-03-08T12:58:51.983 に答える