CODEWITHSUNDEEP
c#ms-wordoffice-interopoffice-automationexport-to-pdf
Barnabeck
Barnabeck

Reputation: 481

Microsoft.Office.Interop.Word open does not work (no error thrown)

I have a Web Application that had been working for years on WindowsServer2012 with an Office automation implemented through microsoft.office.interop. I had to move the app to WindowsServer2019 and now the files can't be open. No error is thrown and the app is busy waiting for the server to proceed.

I perfectly know that this kind of automation is not recommended by Microsoft. It did a great job over the last 8 years and I'm using it only in our Intranet to convert Excel/Word documents to PDF and to bundle them in one PDF Binder using iTextSharp.

The fact that the browser keeps waiting all the time makes me think that Office popped up some (irrelevant) message or alert that need to be closed or accepted. The user that is supposed to run the application is set in Component Service. If I run Office under that identity no first-time-runtime message is displayed.

Comparing the old Server environment with the new one makes me think that the problem might be related to the behavior of Office. The documents I open are all ReadOnly. The new environment opens them in a restricted ReadOnly mode (where probably the "Save as" command isn't available?), while the old environment opens them in Edit mode. I couldn't manage to change that playing with the Office Options.

This is the code that works in the old environment:

    public void Indexchanged_ConvertWordPDF(Object sender, EventArgs e)
    {
        Microsoft.Office.Interop.Word.Application xlApp = new Microsoft.Office.Interop.Word.Application();
        object missing = System.Type.Missing;
        xlApp.AutomationSecurity = Microsoft.Office.Core.MsoAutomationSecurity.msoAutomationSecurityForceDisable;
        xlApp.DisplayAlerts = WdAlertLevel.wdAlertsNone;

        xlApp.Visible = false;        

        string path = Gridview_SO.SelectedRow.Cells[0].Text;

        string CertName = Gridview_SO.SelectedDataKey.Value.ToString().Replace("/", "-");

        Microsoft.Office.Interop.Word._Document wordDocument = xlApp.Documents.Open(path, false, false, ref missing, ref missing);

        wordDocument.ExportAsFixedFormat(@"C:\pdf\" + SALESID.Text + "_" + CertName + ".pdf", Microsoft.Office.Interop.Word.WdExportFormat.wdExportFormatPDF);

        object doNotSaveChanges = Microsoft.Office.Interop.Word.WdSaveOptions.wdDoNotSaveChanges;
        wordDocument.Close(ref doNotSaveChanges, ref missing, ref missing);
        xlApp.Quit();

        DownloadSinglePDF(CertName);

        GC.Collect();
        GC.WaitForPendingFinalizers();
    }

Upvotes: 0

Views: 1179

Answers (1)

Eugene Astafiev
Eugene Astafiev

Reputation: 49395

I perfectly know that this kind of automation is not recommended by Microsoft. It did a great job over the last 8 years

Nobody guarantees that your code will be working with new Office or Windows Server versions. You were lucky having automation running without issues on the server.

For other readers I'd like to remind that Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.

If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.

Consider using the Open XML SDK if you deal with open XML documents only, see Welcome to the Open XML SDK 2.5 for Office for more information.

Also you may consider using third-party components designed for the server-side execution.

Upvotes: 1

Related Questions