C＃-SERVICE：... Excel.Application.Workbooks.Open从服务调用时失败 [英] C#-SERVICE: ...Excel.Application.Workbooks.Open fails when called from a Service

问题描述

在Windows VISTA SP1上使用C＃，.NET3.5，Visual Studio 2008和WCF，我编写了一个服务，服务主机（作为C＃控制台应用程序）和一个客户端。


该服务使用Microsoft.Office.Interop.Excel.Application访问本地硬盘驱动器上的Excel文件，打开它（使用Application.Workbooks.Open），读取一些数据并将所述数据提供给客户端。 br />

当服务主机是C＃控制台应用程序时，一切都很完美。也就是说，客户端调用该调用，服务主机正式调用该服务，该服务又读取Excel文件并返回预期的数据。


但是，当服务被包装为Windows服务（因此所有代码都相同），Application.Workbooks.Open无法打开文件;调试服务表明Excel返回错误无法访问文件...。

我原来的猜测是Windows服务在较低的信任情况下运行。但是，我尝试在我自己的管理员帐户下运行服务，允许与桌面交互，授予服务完全信任（从VS 2008并重新安装服务），添加了强名称密钥以及我能想到的任何其他内容。但无济于事。


我甚至在服务中添加了代码，从硬盘驱动器（不在隔离存储器中）打开二进制.dat文件，并读取一些任意值 - 这是有效的在控制台应用程序和Windows服务下很好，从而证明Windows服务具有更高的信任度。


当运行访问桌面时，我还将Application.visible属性设置为true，所以我可以与Excel交互并尝试弄清楚发生了什么。果然，在Windows服务下，Excel应用程序启动，但我所能做的就是创建一个新工作簿并输入它。应用程序不会让我保存它也不会打开现有的工作簿（因此，Application.Workbooks.Open方法在Windows服务中失败）。


总之，Windows服务本身显然具有提升的信任，因为它可以打开，读取，写入和保存到硬盘驱动器上的本地文件（而不是隔离存储）。但是，当Windows服务调用Application.Workbooks.Open与Excel交互时，表示COM对象无法执行任何文件操作。


猜测怪异，我想是Excel.Application用于与Excel交互的COM对象可能是在具有较低优先级的单独线程中运行的。


基本上我被困在这一点上并且非常感谢所提供的任何指导。


提前致谢，

Robert

解决方案

我也面临同样的问题。请回复，如果有人有任何解决方案。

罗伯特，


你有没有想过这个问题？我在Visio遇到同样的问题


David

想知道你是否已经解决了这个问题。


特别不确定vista ...但我的研究表明自动化是Windows Server 2008的一个问题，特别是64位版本。

32位版本以及Windows 2003 32 / 64位。

我不确定它是否仅影响服务或应用程序自动化..

我们使用服务来完成任务。


最近我们遇到了这个问题，这非常重要。我们使用excel自动化做了一些高成本的工作，并且最近获得了一个运行Windows Server 2008的新系统，只是为了发现似乎存在阻止我们的应用程序执行其核心工作的错误/问题。

我们得到同样的问题... excel加载，你去打开一个工作簿，它出错了。似乎是一个安全/权限错误，但已经尝试在许多可以访问该文件的帐户下运行，什么也没有。


如果您找到了解决方案，请告诉我。

Using C#, .NET3.5, Visual Studio 2008 and WCF on Windows VISTA SP1, I have written a service, service host (as a C# console application) and a client.

The service uses Microsoft.Office.Interop.Excel.Application to access an Excel file on the local hard drive, opens it (using Application.Workbooks.Open), reads out some data and the provides said data to the client.

Everything works perfectly when the Service Host is a C# console application. That is, the client invokes the call, the service host duly invokes the service, which in turn reads the Excel file and returns the expected data.

However, when the Service is wrapped as a Windows Service (so all the code is identical), Application.Workbooks.Open fails to open the file; debugging the service indicates that Excel returns an error "Cannot access the file...".

My original guess was that the Windows service was running in a lower trust situation. However, I have tried running the service under my own administrator account, allowed interaction with the desktop, granted the Service Full Trust (from VS 2008 and reinstalled the service), added a strong name key and anything else I can think of. But to no avail.

I even added code to the Service that opens a binary .dat file from the hard drive (not in Isolated Storage) and reads in some arbitrary values - this works fine under the console application and Windows Service, thereby proving the Windows Service has elevated trust.

When running with access to the desktop, I also set the Application.visible attribute to true, so I could interact with Excel and try to figure out what''s going on. Sure enough, under the Windows Service, the Excel application starts, but all I can do is create a New workbook and type in it. The application won''t let me Save it nor Open an existing workbook (hence, the Application.Workbooks.Open method fails from within the Windows Service).

In conclusion, the Windows Service itself clearly has elevated trust, as it can open, read, write and save to a local file on the hard drive (not in Isolated Storage). However, when the Windows Service calls Application.Workbooks.Open to interact with Excel, said COM object does not have the ability to do any file operations.

Guessing wildy, I imagine that the COM object that Excel.Application uses to interact with Excel is perhaps under-the-hood being run in a separate thread that has lower priority.

Essentially I''m stuck at this point and would appreciate any guidance that is on offer.

Thanks in advance,

Robert

解决方案

Me also facing the same issue. Pls reply if anybody has got any solution for it.

Robert,

Did you ever figure this issue out? I am having the same problem with Visio

David

Wondering if you have solved this issue yet.

Unsure of vista specifically... but my research shows that automation is an issue with Windows Server 2008, specifically the 64-bit version.
The 32bit version works, as well as windows 2003 32/64bit.
I''m unsure as to whether it affects only SERVICES or APPLICATION automation as well..
We use a service for our tasks.

Recently we have run into this problem, and it''s pretty important. We do some high dollar work using excel automation, and have recently obtained a new system running windows server 2008, just to find out there seems to be a bug/issue that prevents our application from doing its core work.
We get the same issue... excel loads, you go to open a workbook, and it errors out. Would appear to be a security / permissions bug, but have tried running under numerous accounts that have access to the file, and nothing.

If you have found a solution please let me know.

这篇关于C＃-SERVICE：... Excel.Application.Workbooks.Open从服务调用时失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！