Free Support Forum - groupdocs.com

Word to PDF does not work on .NET Core 3.1

I have downloaded the the sample solution for C# .NET Core and it converts fine out the box. If you increase the target framework to .NET Core 3.1 it does not convert at all and returns a corrupted document.

This also appears to be a problem for Word (.doc & .docx), Excel (.xls & .xlsx) as well as Rich Text Files (.rtf) in fact the only thing actually working is images.

1 Like

@rthomas95

We couldn’t reproduce this issue using API version 20.11. Please share following details and we’ll look into this scenario:

  • API version that you are using or integrated in the application (e.g. 20.8, 20.11)
  • Sample/problematic files (e.g. Word, Excel)

I am using 20.11.0 and using the sample docs from the sample project.

I have seen this working in .NET Core 3.1 but it is failing suddenly for myself and a colleague. I thought it could be related to Windows Update but after uninstalling these, the problem still persists. I am still trying to investigate what has changed.

I have published my app to Azure and tried calling it from there and the problem still exists there. It only appears to be Word and Excel that are effected. Images and PowerPoint are fine.

I have also tried running in a Windows Sandbox with the .NET Core 3.1 Runtimes installed and that worked fine, so something on my machine must not be right. Any ideas?

@rthomas95

Maybe, there’s some environment level issue. However, please share following details:

  • Complete development and deployment environment details
  • A screencast/video that shows when and how issue appears
  • Problematic files

Unfortunately the video was too large (16MB) to upload here, so I have uploaded to Dropbox, which you can access here.

In the video I am using the latest downloaded code from the GroupDocs examples on GitHub. This also contains the problematic documents.

I am developing on Windows 10 (OS build: 19042.662) using Visual Studio 2019 16.8.2. The actual project I want to use is a .NET Core Web API that will be deployed to Microsoft Azure App Service.

I can also confirm that I have both .NET Core SDKs installed. (2.1.802) and (3.1.404) (Both 64-bit)

@rthomas95

We’ll investigate this scenario and update you.

@rthomas95

Could you please also share a console application using that issue could be reproduced? We still can’t reproduce it for .NET Core 3.1.

I have uploaded the Debug folder of a project with the problem here.

1 Like

@rthomas95

This issue is reproduced at our end.

When you try to open the converted PDF using Adobe PDF reader, it gives an exception There was a problem reading the document (14). However, if you try to open same output/resultant PDF using some other PDF reader (e.g. Foxit Reader), you will see the document without any issue. Have a look at this screenshot.png (397.1 KB).
We are investigating this behavior (exception in case of Adobe PDF reader). Your investigation ticket ID is CONVERSIONNET-4324. You’ll be notified as there’s any update.
Secondly, we noticed that you are evaluating the API in trial mode. Please have a look at these trial limitations. We’d encourage you to avail a temporary license here.

Can confirm the document opens correctly in another reader.

With regards to licensening, we are currently reviewing a number of PDF conversion platforms, and will look at a temporary license during performance testing.

1 Like

@rthomas95

Alright.

Can also confirm this is effecting Visio/Diagram conversions and .rtf

There also appears to be something strange going on with Fonts.

image.png (37.8 KB)

Left is how it should be, right is how it’s coming out. The font in the original Word Document is just a normal Calibri built in font. I am also not using the DefaultFont property as this font should be supported?

@rthomas95

Could you please share the sample and output files? Also, the code you wrote for this particular conversion.

Please ignore the fonts thing for now, as I only saw this once and have not been able to replicate it since.

1 Like

@rthomas95

Alright.

Are there any updates on this issue?

@rthomas95

This issue is expected to be fixed in API version 21.1. We’ll notify you if there’s any further progress.