views:

1402

answers:

5

Note that I'm not talking about the compiler-generated "Temporary ASP.NET Files".

My web application (ASP.NET MVC) uses Graphviz to generate images that are then fed to the client. This requires the creation of temporary files.

What's the best way to deal with these? Is there a way to delete them immediately after they're sent? Should I use a background thread? Something in Application_Start or Application_End?

A: 

we use application_start with a timer kind of a thing to run at an interval of every 24 hours and clean up/delete the temporary files folder once a day.

Vikram
+2  A: 

Graphviz creates the client, and adds them as a link in the page. so you cannot delete them directly.

there are several ways:

  • on application start, noone should use one of these images. so you can delete it
  • you add a reference to the image (e.g. the path) to the cache, and add a CacheItemRemovedCallback, that will delete your image. (limits nicely the amount of images on your HD
  • make a timer, that deletes the items periodically

be aware, that you should not delete the images, that are created just a second ago. due to they can be used.

cRichter
+3  A: 

couldn't you do it through a controller or use an ASHX (http://www.marklio.com/marklio/CommentView,guid,df8d6471-83fd-4f66-a799-ef8274979f0e.aspx) to stream out the content and delete the temp files once you had finished writing out the stream?

jamie
+1  A: 

I like to deal with temporary files created by an action in the same action that generates them. For instance: (in MVC, but this could apply to any framework)

public ActionResult Foo()
{
    FooCleanup(); // deletes files in "~/temp/Foo/" older than a day or so

    string filename = CreateTemporaryFile(); // Creates a temporary file like "~/temp/Foo/{timestamp}.foo"
    return File(filename);
}

If Foo() gets called a lot, you can add some logic to only call cleanup every so often. This is kind of like a poor man's cron job, but it works well.

Stuart Branham
A: 

You could create an handler (.ashx) and stream the temp-file through that. That way you will know that the file has been transfered to the client, and you can delete the temp-file in the end of the handler.

A possible problem with this is that the client won't be able to download the file twice, since you're deleting it immediately. (Which could then be mitigated using the page-output cache...)

Though the best thing would be if you could avoid the temp-file problem all over, and stream out the file on request, by generating it in the handler...

Arjan Einbu