Tear down isn't working 100%
When running unit test the testhost is kept running which holds a reference to the DLL of WkHtmlToPdf library, so if you're making changes it can't build. It's most likely something that isn't disposed/unloaded properly, but needs investigation.
Hi @HakanL ,
We've occurred with the same problem in integration tests and solved it via adding pdftools to DI container.
Please have a look in our code
public void ConfigureServices(IServiceCollection services)
{
// let's register pdf tools for correct ending the chrome process
// when application shutting down
services.AddSingleton(typeof(ITools), typeof(PdfTools);
// this scenario apply only in multi-thread scenario like in a webserver
// see also: https://github.com/rdvojmoc/DinkToPdf#dependency-injection
services.AddSingleton(typeof(IConverter), typeof(SynchronizedConverter);
}
If it looks normal I will prepare pull request to the documentation
@sflusov Yeah, that's a workaround (to always hold a reference to it), but the issue is if you want to do a teardown then it's not working.
We have ~1.5k integration tests which use WebApplicationFactory (TestServer) and there is no problem run it again and again. Maybe you lost dispose method in the end of test collection.
So If you provide example of code I will try to help you
It's not a problem if you don't try to dispose (which is typically the setup with DI), but this bug was raised because it didn't work to tear it down. We would probably need to add a separate unit test to the project to test repeated setup/teardown, I don't think there is one currently, PRs welcome.
Doing:
using(var converter = new SynchronizedConverter(new PdfTools())){
... do
}
Works the first time, but crashes the application on subsequent calls to this method.
This is solved by keeping one copy of SynchronizedConverter as a static variable, but rebuilding the site fails with the error:
The process cannot access the file '\bin\runtimes\win-x64\native\wkhtmltox.dll' because it is being used by another process. The file is locked by: "w3wp.exe (16856)"
Docs need to be clearer on how to use SynchronizedConverter and it looks like a bit of a showstopper bug for us that something isn't being disposed properly.
@TomGullen You should always just have a singleton/static instance of the SynchronizedConverter when using this project. I assume the teardown issue has something to do with the native library, but more investigation is needed. The examples in here use the SynchronizedConverter, but feel free to submit PR for how the docs can be improved.
Using the same approach, with dispose (using block). 1st generation is fine, although there's that warning and also the 80010106 warning. 2nd generation FAILS,
Hello, World! Qt: Could not initialize OLE (error 80010106) WARNING: QApplication was not created in the main() thread. Qt: Could not initialize OLE (error 80010106) QObject::startTimer: QTimer can only be used with threads started with QThread QObject::startTimer: QTimer can only be used with threads started with QThread QObject::startTimer: QTimer can only be used with threads started with QThread QObject::startTimer: QTimer can only be used with threads started with QThread
C:...{{ some folder structure here with client-specific naming }}...\Pdf-Generator.exe (process 34660) exited with code -1073740940.
So possibly the static lazy approach for SynchronizedConverter is needed, actually making it a "singleton".
@hidegh Yes, you absolutely have to have the SynchronizedConverter as a singleton, but the issue raised here is if you wanted to do a full teardown (not recommended though) then there's something that isn't realized. It shouldn't be an issue in a normal application.