Something in Apache FOP is locking modify/delete file access rights.
Here is the situation..
First, there is a gif file on disk, in a certain location in my web application structure, but more importantly, in a certain physical location on the drive.
In the xsl stylesheet, the gif is referenced by absolute physical path through the XSL FO element external-graphic and given a url with preceded by file:///c:/etc. Like this from the input xml:
<logoLocationOnDisk>file:///c:/path/to/file.gif</logoLocationOnDisk>
and this in the xsl:
<fo:external-graphic src="{//logoLocationOnDisk}" width="20mm" height="20mm" scaling="uniform"/>
Btw, I'm generating a PDF. The good news is that the PDF does get the image permanently embedded in it.
The bad news is that after the transformation is complete, and all of the objects I called on to do the transformation have been nulled out, something down in either Apache Fop or the J# dll retains a lock on the gif file. What is strange about the file lock is that it is not found by Process Explorer. When I try to delete the gif file, Vista says that the action cannot be completed because another program is using it.
But, exiting the test harness (pressing Stop in Visual Studio) releases the lock, and the file deletes fine after that.
Now, the transformation that is performed on the stylesheet is a compiled one, which I think might have something to do with why it is claiming "use" of the image. I'm thinking it does not want to let go of the image because it might need it in the future? IDK, I have tried looking at everything that I can call into in the Apache classes, reset, delete temp files, everything.
I believe that I am closing all streams and writers correctly.
How do I tell it to "really clean up"?
Also, is there a way that I could trace with VS2008 or another tool, what really holds a lock on the file, and determine why it is holding on?
The original model for what we are doing is here, however we have changed things slightly from this. Perhaps I have introduced a bug. My next step is to go back to the original code and see if the image file gets locked if referenced by xsl via external-graphic. My strong suspicion is that it will stay locked. We'll see.
Does anyone know the answer just from experience doing this sort of thing?
Is it possible to have there not be any kind of lock on the logo image gif once the transformation is completed.
If there is a way, I'll do that, because it will smooth project deployment.
If there is no way, then I can live with it by taking the gif image out of the deployment, and saying that it is just going to sit somewhere else on disk.
(As an aside, the only reason I noticed the problem was re-release of my project, and that gif was the only thing locking/blocking everything else, and it was a culprit twice in a row.)
As I said, reproduced in test environment, there's a death grip on the gif every time until application exits.
Another thing of note is that on 64 bit machines, such as my own, one has to build for 32 bit and allow iis to run 32 bit code.
Here is some further context: http://www.codelathe.com/blog/index.php/2009/02/28/generate-pdf-from-cnet/ http://www.codelathe.com/blog/wp-content/uploads/2009/02/csharpcode.txt