FileStream dans l'utilisation

Si mon fichier de flux est en cours d'utilisation (chaque fois que j'essaye de débogage, il cogne la première ligne et dit qu'elle est en cours d'utilisation), comment puis-je la force d'une libération? chaque fois qu'elle frappe ce code, j'obtiens un message me disant que quelque chose est en l'utilisant:

FileStream fileStream = File.Open(@"C:\somefile", FileMode.Open, FileAccess.Read);
byte[] buffer = new byte[fileStream.Length];
...etc.
fileStream.Close();
Qu'est-ce que le fichier en cours d'utilisation?

OriginalL'auteur PositiveGuy | 2010-02-15

  1. 18

    Apprendre à utiliser à l'aide de:

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

    La using construire assure que le dossier sera fermé lorsque vous quittez le bloc, même si une exception est levée.

    Votre problème est peut-être pas ici, mais ailleurs dans votre code. Vous aurez à passer par tous de votre code et de chercher des endroits où vous avez ouvert les fichiers, mais pas de le mettre à l'intérieur d'un using déclaration.

    OriginalL'auteur Mark Byers

  2. 4

    Pensez également à utiliser 

    File.ReadAllText(string path);

    ou

    File.ReadAllBytes(string path);

    Si vous voulez simplement lire le contenu du fichier et il n'est pas trop gros.

    OriginalL'auteur Manu

  3. 3

    La suggestion d'utiliser les using déclaration est un bon; mais il n'est pas votre seul choix. Elle tend simplement à être préféré par les développeurs pour son point de vue syntaxique "propre" look et la facilité d'utilisation.

    La principale chose (et ce using s'assure de toujours pour vous) est de s'assurer que vous appelez FileStream.Close n'importe quoi. Si vous frappez une exception, ce code peut être manqué. Donc, à tout le moins de mettre votre appel à Close dans un finally bloc.

    Personnellement, si je suis en train d'écrire toute erreur de manipulation de moi-même, je préfère try/catch/finally à try/using/catch. Dans un autre scénario, je beaucoup préférez l'utilisation de finally est là que je travaille avec plusieurs IDisposable objets, et je veux éviter de profondeur d'imbrication. Considérons le code suivant:

    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
}

    Maintenant, comparez cela à cela:

    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();
}

    Personnellement, je trouve que celle-ci soit beaucoup plus lisible.

    Évidemment, c'est une question de préférence personnelle. Ci-dessus deux exemples de code pour obtenir le même résultat.

    mais si j'utilise un aide, qui permettra de garantir qu'il va fermer, même si une exception se produit n'est-ce pas?
    Oui -- de même que de la mettre dans un finally bloc (ce qui garantit que tout ce qui est à l'intérieur de la finally fonctionnera même si une erreur a été jeté quelque part dans le try). Je l'utilise généralement using si je ne suis pas le contraire de la manipulation des erreurs moi-même; si je veux attraper une exception, même si (à l'aide de catch), je trouve ça plus propre d'utiliser try/catch/finally que try/using/catch - principalement parce que celle-ci implique un niveau supplémentaire de nidification (purement une question de préférence personnelle, bien sûr).

    OriginalL'auteur Dan Tao

  4. 0

    à l'aide de using est la bonne approche.

    Vous pouvez également spécifier le partage de fichiers.readwrite option pour ouvrir le fichier sans le verrouiller.

    OriginalL'auteur Paul Creasey