我正在使用以下代码(Microsoft Office Interop)将DOCX文件转换为PDF文件。最近,我们创建了新服务器,并注意到PDF文件的大小正在增加。当我们在同一时间将同一DOCX文件转换为PDF到两个服务器时,新服务器的PDF文件大小大于旧服务器的PDF文件。
Microsoft.Office.Interop.Word.Document _wordDocument;
_wordDocument = _wordApp.Documents.Open(ref DocxFilePath);
_wordDocument.Activate();
object o_format = Microsoft.Office.Interop.Word.WdSaveFormat.wdFormatPDF;
_wordDocument.SaveAs(ref PdfFilePath, ref o_format);
object oFalse = false;
object nullobj = System.Reflection.Missing.Value;
_wordDocument.Close(ref oFalse, ref nullobj, ref nullobj);
System.Runtime.InteropServices.Marshal.ReleaseComObject(_wordDocument);
_wordDocument = null;
两个服务器都具有相同版本的Office(MS Office 2016)。
任何欢迎纠正此问题的建议/想法。
谢谢。
答案 0 :(得分:0)
首先,在服务器端自动化Word并不是一个好主意。微软明确声明:
所有当前版本的Microsoft Office都经过设计,测试和配置,可以作为最终用户产品在客户端工作站上运行。他们假定交互式桌面和用户个人资料。它们没有提供满足旨在无人值守运行的服务器端组件的需要所必需的可重入性或安全性级别。
Microsoft当前不建议并且不支持从任何无人参与的非交互客户端应用程序或组件(包括ASP,ASP.NET,DCOM和NT Services)自动化Microsoft Office应用程序,因为Office可能表现出不稳定在这种环境中运行Office时的行为和/或死锁。
如果要构建在服务器端上下文中运行的解决方案,则应尝试使用对无人值守执行安全的组件。或者,您应该尝试找到允许至少部分代码在客户端运行的替代方法。如果您从服务器端解决方案中使用Office应用程序,则该应用程序将缺少许多成功运行所需的功能。此外,您将承担整体解决方案稳定性的风险。
在Considerations for server-side Automation of Office文章中了解有关此内容和可能的替代方法的更多信息。
相反,如果仅处理打开的XML文档,则可以考虑使用Open XML SDK。
如果您正在服务器端进行文档生成,而无需使用Office文档作为输出,则通常使用iText或iTextSharp之类的东西,将直接渲染PDF。