I built a converter using GhostScriptSharp to generate full-page images of PDF files via a website, and gsdll32.dll seems to remain locked (as well as the files it generated/worked from) whenever I call GenerateOutput().
My code snippet:
GhostscriptSharp.GhostscriptWrapper.GenerateOutput(pdfFile, outputFile, settings);
Immediately after calling this, I save the resulting bytes to a blob on Azure. Once that's done I try to call:
try {
File.Delete(outputFile); // clean up if we can
}
catch { }
Which throws an exception because the file is still locked.
Then when I try to build again (either via F5 or even in live situations) I get an error saying it can't copy gsdll32.dll to my bin folder because it's locked.
I checked GhostScriptSharp against the Ghostscript API, and it seems everything is being called in the correct order. I can't explain why IIS is retaining a lock on gsdll32.dll, though.
Anyone run into this before? I can't seem to find anyone with a similar problem.
Update: I tried calling ExitAPI/DeleteAPI a second time in the catch above in case it just didn't take the first time for some reason, and it threw an AccessViolationException. So it looks like the API is exiting properly, just IIS isn't releasing locks properly I guess?
After more research, this appears to actually be behavior between IIS and native dll imports. For most purposes this problem can be avoided by unloading the AppDomain (i.e. cycling the app pool) before publishing. This is doable in a normal publishing scenario using app_offline.htm, but in an Azure continuous integration environment this is not an option (which is sad because I've had to disable CI and resort to manual publishing on my master branch).
Any further input on how I could work around this to get builds automated would be incredibly helpful. The only workaround I have in right now involves offloading the Ghostscript dependency to a separate machine and setting up a message queue to process things (ugh).