共计 1645 个字符，预计需要花费 5 分钟才能阅读完成。
在应用 Microsoft Office 组件之前我有理解过许多不须要依赖的形式，比方 Spire.Presentation，Aspose 这些组件，Spire.Presentation 应用起来很便捷，然而免费版有图片张数限度，Aspose 如同没有单纯的 PPT 解决，应该是把 PPT 先转为 PDF，再从 PDF 进行输入的。但毕竟是商业我的项目，免费问题是防止不了的，对于这些组件的开发商并不算大厂，所以什么破解、盗版的形式我都会间接回绝（集体认为应该尊重劳动成果），对于本人从底层解析 PPT 的难度过大，因为波及到解释类语言，即便费良久功夫解析进去也要思考平台兼容性，所以最终我还是抉择了 Microsoft Office。应用 Office 套件的毛病实际上也非常明显，像是体积太宏大，原本只须要这么一个小点的性能却要装置几个 GB 的多余部件，部署环境从此须要依赖 Windows + Office。不过倒是相比拟其它商业我的项目，Microsoft Office 能够不用激活就可能应用可编程的组件（过期后可能会存在一点小问题），这的确是一个比拟具备说服力的理由。性能的实现从代码上来看并不多：
using Microsoft.Office.Core;
using Microsoft.Office.Interop.PowerPoint;
Application app = new Application();
Presentation ppt = app.Presentations.Open(fileName, MsoTriState.msoTrue, MsoTriState.msoTrue, MsoTriState.msoFalse);
int slideCounts = ppt.Slides.Count + 1;
for (int i = 1; i < slideCounts; i++)
{
string picSavePath = "D:/filename_" + i + ".jpg";
ppt.Slides[i].Export(picSavePath, ".jpg");
}
ppt.Close();
app.Quit();代码到这里实际上就曾经完了，增加的援用是 COM 程序集里的 Microsoft PowerPoint 15.0 Object Library 与 Microsoft Office 15.0 Object Library，具体的版本号视状况而定。
尽管代码没有什么问题，或者本地调试也没有什么问题，然而部署到大多数的生产环境中多半是不能执行的，因为 COM 程序集的调用须要肯定的权限，如果某些中央的配置不当就可能会遇到各种各样的谬误，而且大多数的异样音讯可能也很难看出问题所在。我是把程序作为 ASP.NET 网站给部署到 IIS 上的，比方上面就是我遇到的各种异样：
甚至还会有看似毫无关系的这种谬误：
解决办法是把应用程序池的标识改为更高的权限所有者，比方 LocalSystem；这还不是基本，还须要在 Windows 组件服务 （dcomcnfg） 中设定 PPT 组件的权限：
平安选项卡中默认为管理员提供了权限，所以只有应用程序池设定了 LocalSystem 就不必去管它，否则就视状况更改用户的权限。
组件服务的配置实现后基本上大多数的环境都可能失常应用性能了，然而在我所用的环境中还遇到了另一个异样：
大略意思如同是类型不匹配，应该是 PowerPoint 的程序类型与另一个 PowerPoint 的程序类型不统一，这个奇怪的问题困扰了我很长的工夫，前面我发现金山公司的 WPS 提供了一个名字叫做 office 的组件，外面具备 Microsoft.Office.Interop.PowerPoint 命名空间，外面具备这个 _Application 类型，我就发现我被误导了，用了微软的 PowerPoint 类型，却援用了金山的 Office 内核，我不明确到底是金山 WPS 应用了微软 Office 的内核还是金山 WPS 篡改了微软 Office 的内核，反正我也装上了微软 Office，所以我就罗唆把 WPS 给卸载掉，从新援用微软清一色的组件就好了。
