search

pruiz / WkHtmlToXSharp

C# wrapper wrapper (using P/Invoke) for the excelent Html to PDF conversion library wkhtmltopdf library.
239 stars 84 forks source link

Asp.net/IIS Support #42

Open nicholasguyett opened 7 years ago

nicholasguyett commented 7 years ago

In issues #30 and #10, its stated that this project does not support IIS/ASP.net. This is because of of incompatibilities with the app pool recycling and the releasing of resources in non-managed code.

Is it feasible to update how those resources are managed in order to fix this issue? I'm willing to put in the effort to try and make this project compatible with the app pool recycling if I could be pointed in the direction of where these non-managed code resources are at.

ggeurts commented 7 years ago

Replacing IntPtr usage in the P/Invoke calls with SafeHandle implementations may go a long way in ensuring that unmanaged resources are released on shutdown of AppDomains.

pruiz commented 7 years ago

Not really, as the one who releases this memory is nothing related to .Net. But internal memory management at wkhtmltox.

But we are open to accepting patches/prototypes.

Regards

On Fri, Feb 3, 2017 at 9:20 PM, Gerke Geurts notifications@github.com wrote:

Replacing IntPtr usage in the P/Invoke calls with SafeHandle implementations may go a long way in ensuring that unmanaged resources are released on shutdown of AppDomain s

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pruiz/WkHtmlToXSharp/issues/42#issuecomment-277352007, or mute the thread https://github.com/notifications/unsubscribe-auth/AALq-S5_QZ9TbgcI6DUkEucRWS2XCBtnks5rY4wBgaJpZM4LjQ4O .

nicholasguyett commented 7 years ago

@pruiz, so to make this project directly usable in an IIS project, the C++ project would have to be updated? There isn't anything on the C# end that can clean up the resources?

pruiz commented 7 years ago

@nicholasguyett It is not (just) an issue with regards to cleaning up resources. There's also the way each process (IIS AppPool vs wkhtmltox) work (compete) with it's internal threads management code, IIS AppPool recycling, etc.

As an example, of one of the worst cases take this one: when wkhtmltox receives some pointers to callback functions it will be invoking as conversion progresses. We can make such pointers/methods safe from collection, however, we cannot control IIS AppPool recycling (more than disabling it, which is not a great idea). So you can end up with native (wkhtmltox) code, trying to invoke a managed funcion/method, no longer existing in memory, as IIS has dumped/re-created the managed application while wkhtmltox was still working on conversion..

nicholasguyett commented 7 years ago

Just to confirm, this project is wrapping a different wrapper (wkhtmltox)?

Top google result for this is wkhtmltox which is a nodejs project, which seems an odd choice. I did also find wkhtmltoxdotnet but that project seems barely used. Are you using one of those or a different library entirely?

joantune commented 7 years ago

The previous commit solved the issue for me as well. I was having trouble with the garbage collection of the callbacks and after updating the nuget packages from 1.2.4 to 1.2.7 (which I'm guessing includes this commit) it solved it for me.

So, should the next commit be the removal of the following text from Readme.md or are there any other issues with IIS?

Text to remove:

No ASP.NET/IIS Support: This has to do with the way IIS manages underlaying threads, and application pools. IIS instantiates & re-cycles pools and AppDomains from time to time, and this causes non-managed resources used by this library to not be released properly.

pruiz commented 7 years ago

What was fixed was an issue with GC collecting non-managed pointers, affecting everybody. :)

The IIS/AspNetPool issues, still apply. As there's no (that I now) way to handle/force restarting of non-managed (memory) stuff when IIS performs it's automatic managed AspNetPool recycling. :(

On Thu, May 18, 2017 at 1:32 PM, João Antunes notifications@github.com wrote:

The previous commit solved the issue for me as well. I was having trouble with the garbage collection of the callbacks and after updating the nuget packages from 1.2.4 to 1.2.7 (which I'm guessing includes this commit) it solved it for me.

So, should the next commit be the removal of the following text from Readme.md or are there any other issues with IIS?

Text to remove:

No ASP.NET/IIS Support: This has to do with the way IIS manages underlaying threads, and application pools. IIS instantiates & re-cycles pools and AppDomains from time to time, and this causes non-managed resources used by this library to not be released properly.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pruiz/WkHtmlToXSharp/issues/42#issuecomment-302378368, or mute the thread https://github.com/notifications/unsubscribe-auth/AALq-Wjk7EWM4b3J1o33C_K2tD45gadTks5r7CxogaJpZM4LjQ4O .

rfvgyhn commented 7 years ago

Would implementing IRegisteredObject (more) for pre-.net core and ApplicationStopping for .net core help with this? This would allow for notification of when the app pool intends to reset and gives a chance to clean up and potentially block if a conversion is in progress.

pruiz commented 7 years ago

@Rfvgyhn If there was a way to 'completely' cleanup wkhtml resources, probably yes. But the thing is, trying to dispose/stop/shutdown and then re-intialize wkhtml engine under a single running program has never worked fine in my experience, and most of the time it wont re-initialize ok, or the process will end up crashing.

rfvgyhn commented 7 years ago

Makes sense. I'm not very familiar with wkhtmltox.

eltiare commented 6 years ago

Does this also apply to the .Net Core/Kestrel setup?

pruiz commented 6 years ago

only if it run under IIS.

On Fri, Aug 24, 2018 at 5:02 PM Jeremy Nicoll notifications@github.com wrote:

Does this also apply to the .Net Core/Kestrel setup?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pruiz/WkHtmlToXSharp/issues/42#issuecomment-415786250, or mute the thread https://github.com/notifications/unsubscribe-auth/AALq-dP0E7BwnE7iuuXz29lcGViwolMwks5uUBWagaJpZM4LjQ4O .