linkedinfacebooktwittermenuarrow-up

GemBox Support Forum

Print Word file from ASP.NET Core 3.1 WebApi

GemBox.Document
#1

I’m trying to print a word document from an ASP.NET core web API (we still use .net core 3.1). On my development machine, it works fine, however on the test server the call to the DocumentModel.Print method hangs.

To speed up testing I created a .NET Core 3.1 console app and it produces the same result (works fine on my development machine, hangs on the test server).

When I create a .NET Framework (4.6) console app printing works fine on both my development machine and the test server.

What am I missing?

#2

Unfortunately, this is a known issue. You can read more about it in this thread: Printing Word file from .NET Core Windows Service

#3

I read the thread you mentioned. It’s over two years old! I would expect that this issue would have been solved by now.
Can you elaborate on the technical issue why this is not solved yet? I mean it works fine on my development machine.
We’re planning to update to .NET 6 in the near future, will this affect this issue?

The biggest reason why we purchased this library is because of the print functionality!! This is quite disappointing.

#4

I understand your disappointment, but you have to understand that this is a framework related issue. It is not in our code so we cannot really fix it. We can only find a workaround for it. However, we will schedule an investigation to see if the issue remains on .NET 5+ and get back to you with the results.

#5

I’m sorry but I don’t see the relation to the framework here, can you elaborate?
You mean you have a workaround available, can you share it so I can see if this also works for us?
When can you inform me about the results of the investigation? I need to know this week so we can decide on further actions for the development of our application.

#6

We have investigated this issue thoroughly, but I’m afraid we didn’t find a solid solution (one that would work with any printer).

However, note that the .NET team was able to resolve this in .NET 5.0, see this comment.
Unfortunately, the fix was not backported to 3.1.

Regards,
Mario