tags:

views:

166

answers:

4
+3  Q: 

FileStream in use

If my file stream is in use (every time I try to debug, it hits that first line and says it's in use), how can I force a release? every time it hits this code, I get a message saying something is using it:

FileStream fileStream = File.Open(@"C:\somefile", FileMode.Open, FileAccess.Read);
byte[] buffer = new byte[fileStream.Length];
...etc.
fileStream.Close();
+8  A: 

Learn to use using:

using (FileStream fileStream = File.Open(@"C:\somefile", FileMode.Open, FileAccess.Read))
{
    ...
}

The using construct ensures that the file will be closed when you leave the block even if an exception is thrown.

Your problem might not be here, but somewhere else in your code. You'll have to go through all your code and look for places where you have opened files but not put it inside a using statement.

Mark Byers
+4  A: 

Consider also using

File.ReadAllText(string path);

or

File.ReadAllBytes(string path);

If you simply want to read the contents of the file and it's not too big.

Manu
A: 

using using is the correct approach.

You can also specify the fileshare.readwrite option to open the file witout locking it.

Paul Creasey
A: 

The suggestion to utilize the using statement is a good one; but it isn't your only choice. It just tends to be preferred by developers for its syntactically "clean" look and ease of use.

The main thing (and what using always ensures for you) is to make sure that you are calling FileStream.Close no matter what. If you hit an exception, this code might be missed. Therefore at the very least put your call to Close in a finally block.

Personally, if I'm writing any error handling myself, I prefer try/catch/finally to try/using/catch. Another scenario in which I much prefer using finally is where I'm working with multiple IDisposable objects, and I want to avoid deep nesting. Consider the following code:

try {
    using (DisposableObject obj1 = GetDisposableObject()) {
        // do something

        using (DisposableObject obj2 = GetAnotherDisposableObject()) {
            // do something else

            using (DisposableObject obj3 = GetYetAnotherDisposableObject()) {
                // do even more things

                // this code is now quite nested
            }
        }
    }

} catch (SomeException ex) {
    // some error-handling magic
}

Now compare that to this:

DisposableObject obj1 = null;
DisposableObject obj2 = null;
DisposableObject obj3 = null;

try {
    obj1 = GetDisposableObject();
    // do something

    obj2 = GetAnotherDisposableObject();
    // do something else

    obj3 = GetYetAnotherDisposableObject();
    // do even more things

    // this code doesn't have to be nested

} catch (SomeException ex) {
    // some error-handling magic

} finally {
    if (obj3 != null) obj3.Dispose();
    if (obj2 != null) obj2.Dispose();
    if (obj1 != null) obj1.Dispose();
}

Personally, I find the latter to be much more readable.

Obviously, this is a personal preference. The above two code samples achieve the same result.

Dan Tao
but if I use a using, that will guarantee it's going to close even if an exception occurs won't it?
CoffeeAddict
@coffeeaddict: Yes -- same as putting it in a `finally` block (which guarantees that whatever's inside the `finally` will run even if an error was thrown somewhere in the `try`). I generally use `using` if I'm not otherwise handling any errors myself; if I want to catch an exception, though (using `catch`), I find it cleaner to use `try`/`catch`/`finally` than `try`/`using`/`catch`--mainly because the latter involves an additional level of nesting (purely a personal preference, of course).
Dan Tao