Exception question, "File in Use"

[Samishii23]

If loaded an image into my program, but needed to load it in again later, would I get an expection saying that the file is in use?

[GaryTexmo]

There's a couple of discussions on this either on this page or the next one (a quick search should turn them up, try "image file in use" to show you how to get around this; however, as long as you're not trying to write or otherwise change the image file you should be able to load it normally multiple times and be just fine.

It puts a write-lock on the file, but read access should be ok... if I were you though, I'd run a quick test to see ;)

[tlhintoq]

Image.FromFile( string PathToFile) does indeed have a bug. It keeps a link to the file on HDD for as long as the image is being used by your program. In my opinion it should be avoided at all costs and I really wish MS would fix it since it has been a problem since framework 1.0

I recommend reading the file via a stream. Many examples exist on the net.


More importantly you might want to consider the architecture of your application. Ideally you should only have to load it one time. If you are loading multiple copies of it into different variables simultaneously then you are consuming a lot of memory for every duplicate instance of the image.

[GaryTexmo]

According to Microsoft, it's not a bug, it's a "feature" heh.

http://msdn.microsoft.com/en-us/library/stf701f5.aspx

See the "Remarks" section. Additionally, in my wanderings, I found a Microsoft support page saying it really was intended behaviour as well.

I suppose, in a way, it makes sense since the Image (and Bitmap) class allows you to save back to the file. The lock would prevent any external modifications to the file ensuring that the program with the image open will always have the correct copy, as well as the correct location of that image.

But would it really kill them to provide a flag saying, "Load this image into memory and release the file handle"...?

*Edit: Here's that link to a support page... http://support.microsoft.com/kb/309482
They call it a "problem" but further down they say, "This behavior is by design."

Last thing, and this is important... if the image you're loading is an animated image, you cannot close the stream as it will cause a general GDI+ exception to be thrown when the image is drawn. To get around this, load the file contents into a memory stream, close the file contents, then load the image from the memory which is then left open. Whenever you close a stream an animated image has been loaded from, you'll see the GDI+ exception. I don't know if this fits your situation, Samishii, but it's good to know about.

[tlhintoq]

Remarks
The file remains locked until the Image is disposed.

Personally, I don't think that is so much a statement saying it was INTENDED behavior - as an easy afterthought remark when they found out about the bug. By putting this on the webpage they didn't have to fix it.

After all, why would someone deliberatly keep the file locked? Or if that was a THOUGHT ABOUT feature they would have given a second parameter:

Image.FromFile(string PathToImage, bool LockAccess);

[GaryTexmo]

Again, I agree with you and that's how I would do it too, but either it's the case you describe or Microsoft actually does want it that way. As mentioned, I have my theories as to why they would want to do this, even if I don't agree with it. Unfortunately, Microsoft generally doesn't share their design decisions with the rest of us, which is too bad in the case of a framework like .NET. It would be nice to know where they are coming from once in a while.

If you caught my edit, from the second link...

This behavior is by design.

(Under the "status" section.)

Either way, it's easy enough to work around. Not add a parameter easy, but still easy ;)

[Samishii23]

More importantly you might want to consider the architecture of your application. Ideally you should only have to load it one time. If you are loading multiple copies of it into different variables simultaneously then you are consuming a lot of memory for every duplicate instance of the image.

I was going to make an user option for my application that would allow them to load the image(s) into memory for quicker performance and higher memory usage, or use straight from files to avoid a large memory usage for users that don't have great computers.

[GaryTexmo]

I believe the image is loaded into memory anyway.