ASP.Net 3.0 File Open (WebForms)

I am trying to move the orginal PDF after the images have been created and displayed but the file is left open. Any suggestions.

Hello Jemoritz,


Thank you for your inquiry,

Actually, I couldn’t get your point clearly. More likely it is an Issue of CSS which can be adjusted by the user himself according to his requirement.

Moreover, I would like to suggest you to use our example project which is actually a console based/command line tool. The accuracy rate of the output using this tool is much higher because no CSS or other layout effects are applying on the rendered output.

Kindly try to use the example C# or VB project and observe the output. If the issue would raised again then back to us with you case study and provide us the problematic file.

If you need any assistance to run the example project then please let us know.


Thanks in advance

The issues you have found earlier (filed as VIEWERNET-667) have been fixed in this update.


This message was posted using Notification2Forum from Downloads module by groupdocs.notifier.

I am using the new sample WebForms application in my Webforms application. ASP.Net


When I select a file to be opened, it displays the file as it suppose to. As part of the process on the WebForm, I am streaming the file into a database, then I either want to rename the original file that was viewed or I want to move it. The system is report the file is open. I commented out the converting the file to bytes to make sure I wasn’t leaving the file open. Some where in the GroupDocs Viewer it seems to be leaving the file open. I am using the image viewer, not the html viewer.

Does this clear up my request?

Hi Jemoritz,


Thanks you for your explanation,

I tried to reproduce the issue but unable to do it. I think in your case the file stucks somewhere in the stream and that stream doesn’t end/close properly.

Please make sure that are you closing the stream properly.

You may use fileStream.Dispose(). to release the resources.

Happy Coding!!!

I have some done more testing with this. After I open the pdf file as images with the viewer I have button that I click to save the data to a table and move the file. I commented everything out but moving the file. I still get a system.io exception that the file is being used by another process.


This is a c# asp.net webform app. I built a page from the sample front end. Something isn’t releasing the file handle. Any ideas?

Hi Jemoritz,


Sorry for the delay.

Can you provide us the problematic project source code along with problematic file?

Warm Regards.

It is every single file I view. My folder I view from is not under the IIS folder directory.


I am not able to send the app as I have it, but all I did was take the sample page for the web forms you provide.

I view the pdf file, then I added a submit button with c# code to file.move();

I am told the file is still locked in another process.

If needed I will apply my changes to the same to provide that back to you but all i changes was the storage path and add the button to move the file.


Hi Jemoritz,


Thank you for the explanation.

It is really hard to speculate the actual scene.

However, lets try to getting closer. Kindly write down the C# code which you wrote against file.move().

Thanks in advance.
this is in the viewdocument
public static ViewDocumentResponse ViewDocument(ViewDocumentParameters request)

// If no cache - save images to temp folder
var tempFolderPath = Path.Combine(HttpContext.Current.Server.MapPath("~"), "Content", "TempStorage");
I added this
HttpContext.Current.Session["CompleteDocumentName"] = _storagePath + "\\" + fileName;


your file name is defined as

var fileName = Path.GetFileName(request.Path);


this is on my submit button

string filePath = HttpContext.Current.Session["CompleteDocumentName"].ToString();


File.Move(filePath, filePath.Replace(_storagePath, _storagePath + "\\Uploaded"));


So basically to your sample I added one line of code to viewdocument, then a button with 2 lines of code.

Hello Jemoritz,


Thank you for providing us the coding information.

In fact this issue is not relevant to the back end API. Even this issue couldn’t reproduce in MVC project. Therefore, our team is looking the WebForm front end. You would be informed through this forum thread about the progress/updates regarding to this issue.

Please stay tuned.

any updates?

I did more testing


in the function ViewDocumentAsHtml

var docInfo = _htmlHandler.GetDocumentInfo(new DocumentInfoOptions(request.Path));

This call is where the file first gets locked and can’t move

var docInfo = _imageHandler.GetDocumentInfo(new DocumentInfoOptions(request.Path));

on the image side

i added this to the end of
docInfo = null;
htmlOptions = null;
htmlPages = null;

ViewDocumentAsHtml

Then in GetImageUrls

Looks like the issue is in here

using (var stream = pageImage.Stream)
using (FileStream fileStream = new FileStream(pageImageName, FileMode.Create))
{
stream.Seek(0, SeekOrigin.Begin);
stream.CopyTo(fileStream);
}
the

Hello Jemoritz,


Thank you for your work around.

Infact our front end team is working on this issue. I am going to post a request to the team to confirm about the progress. Soon, we will inform you via this forum thread, as we get any further update.

Please stay tuned!

Its not a full work around. Look forward to seeing your fix.

Hello Jemoritz,


Thanks for your patience. Certainly, before long, you will hear some good news in this regard.

Cheers!

Do we have an update yet?

Hello Jemoritz,


We were hopefull that the issue might be resolved at the front-end side but now it seems that the issue is relevant to the back-end side.Therefore, the ticket (VIEWERNET-667) for this issue has been created into our product level issue tracking system. The product team will look into this issue very closely because this is a rare/special case. However, you will be informed through this forum thread in a case of any further update.

Many Thanks!

Has this bug been fixed yet?

Hello Jemoritz,


Thanks for your patience.

The product team has shown significant progress over it. Since the issue is very complex and it may effect the core functionality of the API. That’s why the product team is examining all the aspects. Hopefully, you will listen a good news soon via this forum thread.

Please stay tuned.