Unable to copy dll files

[josefinscreentek]

Hi, I've seen similar issues here, but with the answer that it's been solved in pull #42 .I still recieve the same error (Unable to copy file ".... wkkthmltox0.dll" to bin\wkhtmltox0.dll". The process cannot access the file '\bin\wkhtmltox0.dll' because it is being used by another process.) for wkhtmltox0.dll, mingwm10.dll and libgcc_s_dw2-1.dll. I'm using Visual Studio 2012 and I have installed the latest available version via nuget (updated 30 jan 2014). I have a solution containing several projects, although only one is using Pechkin.

If I set dll files to "Never copy", then the build succeed, but the code stop working at byte[] pdfBuf = new SimplePechkin(new GlobalConfig()).Convert(html); and just don't proceed for the rest of the function.

Is there a way to make this copy issue resolved?

[josefinscreentek]

I thought the error was resolved by cloning a new project, but it isn't. I have set the dll files to "Copy if newser" since I saw this in another issue thread. And it builds fine and I think it also worked for a couple of runs. But suddenly I get this error again, with the code stop working at byte[] pdfBuf = new SimplePechkin(new GlobalConfig()).Convert(html); And if I set back to "Copy always" I get the unable to copy message again...

[tuespetre]

@josefinscreentek I am sorry this has been a problem for you. You might check sysinternals Handle (http://technet.microsoft.com/en-us/sysinternals/bb896655.aspx), it sounds like some process or another is just not letting go of that file/files.

[MacMcDell]

You are probably getting that error on web application? If so I found the issue to be having to restart the w3wp process. This made testing tedious as I usually use attach to process vs f5. If you do the same thing you are doing and then kill W3wp, refresh browser, does the error go away? Mac

[josefinscreentek]

@MacMcDell, @tuespetre Yes, I am (web application, MVC to be more precise). When I'm on localhost, then I can kill WebDev.WebServer40.EXE between the rebuilds and then it works one time, but this is not a solution on the website. Not really on localhost either, since you shouldn't have to kill a process every time you want to call the html to pdf converter. We have an azure website and then pechkin allocate all available space and we get some type of out of memory exception and the entire site goes down.

[tuespetre]

Hmm... check this out:

https://github.com/tuespetre/TuesPechkin/blob/master/Pechkin/Factory.cs#L351

From that line on is supposed to handle those scenarios; that was key to resolving the issue for us here where I work. In debug and production I can rebuild without the hanging. As you can see it depends on that conditional statement to attach the TearDown method. Could you tell when starting your app if that condition is true and if the handler is being attached?

[josefinscreentek]

@tuespetre I checked AppDomain.CurrentDomain.IsDefaultAppDomain() and that is false. Not sure how to test if the handler is being attached.

[tuespetre]

It just occurred to me that you cited the following as the code you are using:

byte[] pdfBuf = new SimplePechkin(new GlobalConfig()).Convert(html);

That is the API prior to the fixes I put out. Have you tried to use my fork? gmanny had never accepted the pull request and so that code was never integrated into master. I have since published my fork on NuGet, called 'TuesPechkin', for ease of use. Please give it a try.

[MacMcDell]

Hi. I am on web MVC 4 project as well and ran into the same issue. I however do not use webdev or webserver4.0. I use native IIS 7 for my testing environment. I don't think you will run into this issue on a pre prod or test environment where you generally do one deploy, spin up w3wp and start your app. Are you physically killing the webdev process in taskmgr? If not then you are most likely spinning up multiple instances during development phase. Do you have the capacity to make your dev environment as similar to your test enviro to see if this is really an issue or is simply a localhost issue? webdev is completely different from IIS. You should also be aware that if you are running this on web, you need to run in trusted 32 bit. Sucks but truth. If you are using Azure you might want to confirm this will even run on their servers. I read someone else complaining about this.

[josefinscreentek]

@tuespetre I tried to install it, but then it complained about me not having the dll files it required (the ones that is described above cannot be copied). Can I just install TuesPechkin and then just copy those dll files it requires somewhere?

[josefinscreentek]

@MacMcDell Yes, I need to physically kill the process in the task manager. And I think that it's the same ground error that occurs both when I run localhost and on the azure website. A collegue of mine that uses IIS 7 says he doesn't get the error localhost, even though it's the same project.

[tuespetre]

The TuesPechkin dll has the other dlls embedded into it; it unpacks them into the bin directory at runtime. If it says it cannot find them it may be related to the bitness; are you running in 32-bit?

I think I saw another issue as well about running in Azure. It may not even support running 32-bit, which is absolutely required by the wkhtmltopdf dll.

[tuespetre]

Relevant: http://blogs.msdn.com/b/zxue/archive/2011/10/31/enabling-support-for-32-bit-iis-applications-in-windows-azure.aspx

[josefinscreentek]

@tuespetre I'm running on 64 bit. Thanks, I will look at the link

[josefinscreentek]

@tuespetre

This is what I get when I'm trying to run TuesPechkin and use Factory.Create(..)

[tuespetre]

Okay, that's a start; that means wkhtmltox0.dll is loading, but for some reason it can't find its own dependencies now.

If you are running in Debug/Release/whatever configuration, please clean the solution, open that folder (i.e., \bin\Debug\), and ensure that all contents are deleted. Then "Rebuild All". Now, in the folder, you should see all the binaries for your application, and you should not see wkhtmltox0.dll or the other components that go with it. Then, run your application. When the Pechkin library is invoked, you should then see wkhtmltox0.dll copied into the directory along with four other components.

Please try this out and let me know what happens.

[josefinscreentek]

@tuespetre Now I got a real exception. Although, it seems to be the same as above. "{"The type initializer for 'Pechkin.PechkinBindings' threw an exception."}" And the innerexception says "{"The process cannot access the file 'D:\Projects\xxx\bin\libgcc_s_dw2-1.dll' because it is being used by another process."}" Stack trace: at Pechkin.PechkinBindings.FreeLibrary(IntPtr hModule) at Pechkin.Factory.TearDownAppDomain(Object sender, EventArgs e)

[tuespetre]

I see. It looks like I messed up by not checking File.Exists before trying to unpack the embedded dlls. I have just uploaded a patch bringing it to version 0.9.2. Please obtain this new version and try again. Thanks for your patience

[josefinscreentek]

@tuespetre I went home from work. I get back to you with feedback tomorrow.

[tuespetre]

Ok. I'll be watching.

[josefinscreentek]

@tuespetre Seems to work on localhost now and no errors as before. Although, it still doesn't work on azure websites, but it might be that other error with 32 bit, not the plugin itself.

[josefinscreentek]

@tuespetre Cannot find "Issues" on the TuesPechkin project. Is it possible to add and then we can create an issue there instead and continue from there?

[josefinscreentek]

@tuespetre Also, I've checked that the azure website platform runs as 32 bit. Didn't help.

[tuespetre]

There we go. I've added issues. Please feel free to create on there and we can pick up on this.

[josefinscreentek]

Continues here: https://github.com/tuespetre/TuesPechkin/issues/3