PowerShell计划任务使用Excel Com对象运行脚本

这里有一些奇怪的行为，我有一个PowerShell脚本，可以将XLSX文件转换为CSV文件。此脚本在控制台中运行，没有问题

尝试计划任务/脚本会导致CSV文件中没有数据（0字节）

在我的搜索中，我发现这很有帮助

基本上，包含使用Excel ComObject的Powershell脚本的计划任务会失败，因为您必须创建一个文件夹（或64位windows上的两个文件夹）。完成此操作后，手动运行时的任务将按预期工作。当设置了触发器并且用户注销时，它也可以工作

是否在任何地方记录了有关Excel ComObject的此类行为？我花了3个小时试图让它工作。

C:\Windows\System32\config\systemprofile\Desktop

(64Bit)

C:\Windows\SysWOW64\config\systemprofile\Desktop

---

AFAIK没有MS关于此问题/限制的正式文件。应将其报告为错误（请与Microsoft支持部门联系）

---

excel运行时不需要桌面文件夹（系统默认情况下没有），如果缺少，至少应该创建文件夹。

我认为Microsoft不支持您尝试的操作。据此，微软声明：

Microsoft目前不建议也不支持从任何无人参与、非交互式客户端应用程序或组件（包括ASP、ASP.NET、DCOM和NT服务）自动化Microsoft Office应用程序，因为在该环境中运行Office时，Office可能会表现出不稳定的行为和/或死锁

---

这些文档似乎是针对Office2003的，但我不确定从那时起它们是否改变了立场，因为我还没有找到其他说明支持的文档。就在2009年，他重申它不受支持。建议用于非交互式自动化，或用于直接使用文件格式的其他第三方库

更糟糕的是，TechNet线程来自2010年。这是来自Windows、Excel还是PowerShell的错误？问题在于

Excel.Application

ComObject（或Excel应用程序本身）。vbscript示例中也记录了该问题。我无法在上记录错误，因此我不确定下一步要采取什么措施。我认为当遇到Office错误时，您必须致电Microsoft支持部门。如果他们能复制它，他们会制作一个bug报告。我会研究这个选项，因为现在我发现事情开始变得有意义了，这就是我所说的受过去问题支配的当前行为。在技术领域，这些问题可能已经通过更新的代码/技术或理解得到识别和解决。正如所指出的，建议的方法是在Microsoft.NET 3.x框架中使用OpenXML和

System.IO.Package.IO

命名空间来编辑Office文件。问题是，我必须学会这一点！是的，我遇到了类似的问题。有一种方法可以利用。你可以用这两种方法中的任何一种来减轻学习负担。