Dink2PDF Azure deployment.
So i’ve been using Dink2PDF to generate PDF files.
It requires this .dll file from their github repo titled ”libwkhtmltox.dll” to be used.
Now here’s the kicker, locally this method works fine. But if the method is generated through the Azure deployed backend the text isn’t generated properly and ends up just being a bunch of squares.
As the image supplied.
Ontop of this; you can only use the method ONCE after each deployment, the following times it starts looping endlessly forever.
Which leads me to believe that the issue stems from the deployed .dll file. How do you guys typically handle loose .dll files in cloud based environments?
10 Replies
Prolly missing some required font
Server environments don't usually come with many, if any, fonts by default
Thanks for the reply, but Wouldn’t it revert to a basic font?
The problem seems to also be that it gets stuck in a loop if you run the method through swagger any consecutive times
huh
To be honest, I never really used wkhtml2pdf or any wrappers for it, I just generate PDFs with QuestPDF if need arises
I see 😮 The issue im facing now is that it just spins indefinitely when i test the method in Swagger
and its the Azure backend alone; Locally its fine.
doesn't address your scenario directly but we gave up on wrapping wkhtmltopdf a long time ago and use puppeteer (via puppeteersharp)
may be worth looking into if you can't resolve the issue and it's not an insane amount of work to replace the wkhtmltopdf wrapper
@surf68 Thanks for the info! i'll definitely look into it because this is getting pretty tedious.
So the challenge im facing; Im a student and our Azure instance is in 32bit, Puppetsharp seems to only work for 64bit systems @surf68 @Angius
I ended up fixing it by scaling up our Azure to a Basic B1 tier rather than Free F1 and that fixed it.
@Nox 🌺
Ahhh. aHHHHHHHHHH
:BlobCatPTSD: