Welcome Guest Search | Active Topics | Sign In | Register

Generating pdf with EO.pdf causes project dll file lock Options
323846
Posted: Tuesday, October 9, 2012 8:38:25 AM
Rank: Newbie
Groups: Member

Joined: 10/9/2012
Posts: 1
Code: C#
HtmlToPdf.Options.PageSize = new SizeF(8.27f, 11.69f); 
HtmlToPdf.Options.AutoFitX = HtmlToPdfAutoFitMode.ShrinkToFit;
HtmlToPdf.Options.AutoFitY = HtmlToPdfAutoFitMode.None;

EO.Pdf.HtmlToPdf.Options.OutputArea = new RectangleF(0f, 0f, HtmlToPdf.Options.PageSize.Width, HtmlToPdf.Options.PageSize.Height);

HtmlToPdf.ConvertHtml(html.ToString(), tempFileName);



When generating a pdf with EO.Pdf, very often our project.dll gets locked, causing Visual studio to throw an error on recompile:

Error 641 Unable to copy file "obj\Debug\Project.dll" to "bin\Project.dll". The process cannot access the file 'bin\Project.dll' because it is being used by another process.

The .dll file is blocked by following processes :

w3wp.exe
WebDev.WebServer.exe

This happens only when generating the pdf with EO.Pdf. When we just generate a .html file for example, the file lock issue is gone.
We suspect that somewhere a file isn't properly disposed, causing the lock.
Is there any solution or workaround for this, because this gets annoying to the point that we are doubting the purchase of the component.

Thanks in advance,

greetz

G
eo_support
Posted: Tuesday, October 9, 2012 8:59:27 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,195
Hi,

This is normal. It usually happens when the HTML you are trying to convert accessed something that triggers your local IIS. Below is an example when this can happen.

Normal Scenario

When you run your web app inside Visual Studio, Visual Studio would run WebDev.WebServer.exe and your application would have an Url like this:

http://localhost:1234/somepage.aspx

If you call our HTML to PDF converter with the following HTML:

Code: HTML/ASPX
<img src="http://localhost:1234/image_handler.aspx?id=xxxxx" />


Then the converter will try to load "http://localhost:1234/image_handler.aspx?id=xxxxx" in order to get the image data so that it can render the image. This request will be handled by WebDev.WebServer.exe, which would lock your Process.dll. This is all fine. When Visual Studio recompiles, it would kill WebDeve.WebServer.exe to release Process.dll so that it can update it.

Scenario When Your Local IIS is triggered

On the other hand, if you call our HTML to PDF converter with the following HTML:

Code: HTML/ASPX
<img src="http://localhost/image_handler.aspx?id=xxxxx" />


Then the converter will try to load "http://localhost/image_handler.aspx?id=xxxxx". Note this Url does not have the port number in it. So it will be handled by IIS, not by WebDev.WebServer.exe. As a result, W3WP.exe (ASP.NET worker process for IIS) is launched to handle that request. If the Url happens to map into your application (mostly like in your case), it will load your Process.dll. Visual Studio is not aware that your local IIS has kicked in and it would not try to kill it when recompiling your project. Thus your Process.dll would be locked.

The bottom line is W3WP.exe (your local IIS) should not be triggered. The easiest way to avoid this is to use relative Urls. For example, if your HTML is like:

Code: HTML/ASPX
<img src="image_handler.aspx?id=xxxxx" />


Then it would work regardless how you deploy your project.

Another way is to simply kill w3wp.exe from Task Manager when you recompile.

Hope this makes sense to you. Please feel free to let us know if you have any more questions.

Thanks!


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.