à l'aide de déclaration FileStream et / ou StreamReader - Visual Studio 2012 Avertissements

Le nouveau Visual Studio 2012 est plaint d'une commune de la combinaison de code j'ai toujours utilisé. Je sais que cela semble exagéré, mais j'ai fait ce qui suit dans mon code "juste pour être sûr".

using (var fs = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
{
    using (var sr = new StreamReader(fs))
    {
        //Code here
    }
}

Visual studio est un "avertissement" moi, je suis l'élimination de fs plus d'une fois. Donc ma question est-ce, serait la bonne façon d'écrire cet être:

using (var fs = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
{
    var sr = new StreamReader(fs);
    //do stuff here
}

Ou devrais-je le faire de cette manière (ou d'une autre variante non mentionné).

var fs = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite);

using (var sr = new StreamReader(fs))
{
    //Code here
}

J'ai cherché sur plusieurs questions dans StackOverflow mais n'a pas trouvé quelque chose qui a abordé la meilleure pratique pour cette combinaison directement.

Merci!

+1: Bonne question, JUbbard80! 🙂
Avec un double à l'aide de ce genre dans VS2013, un FileStream et un StreamReader, il n'y a pas d'avertissement émis. Est-ce dû à la combinaison de FileStream et StreamReader? Ou ne VS2013 (par opposition à VS2012) reconnaître que cette double élimination est un nonissue?

InformationsquelleAutor JHubbard80 | 2012-08-17

.net c#dispose using visual-studio-2012

39

Les suivants est comment Microsoft recommande de le faire. Il est long et volumineux, mais en toute sécurité:
```
FileStream fs = null;
try
{
    fs = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite);
    using (TextReader tr= new StreamReader(fs))
    {
        fs = null;
        //Code here
    }
}
finally
{
    if (fs != null)
        fs.Dispose();
}
```
Cette méthode va toujours s'assurer que tout est disposé, qui devrait être en dépit de ce que des exceptions peuvent être jetés. Par exemple, si le StreamReader constructeur lève une exception, le FileStream serait toujours bien disposé.
- Oh que c'est à portée de main. Je ne savais pas que l'exemple utilisé dans la CA2202 (Microsoft Recommande lien) était similaire exemple de code dans ma question.
- J'ai édité l'échantillon pour correspondre à votre code.
- Merci - je suis sûr que je pourrais avoir réussi bien =P
- Bon. Vous n'auriez probablement pas ont ajouté que la virgule supplémentaire erreur de syntaxe que j'ai juste édité loin ;).
- J'ai ajouté un peu plus d'une explication, même si je pense que c'était assez clair à partir de l'exemple et du lien de "pourquoi". Si vous pensez que la réponse fournit la désinformation, il est approprié de downvote il. Sinon, il suffit d'upvote de votre choix de réponse. Cette réponse ne peut guère être de la désinformation si c'est presque mot pour mot ce que Microsoft recommande.
- Sur des tests supplémentaires. Cette réponse n'est pas claire le VS2012 avertissement avec StreamReader. Seulement StreamWriter.
- Comme il n'y a pas de consensus, je vais aller avec Microsoft pratique recommandée. Bien que je pense que c'est exagéré. Cette solution soulève encore de l'avertissement, mais comme hvd souligne, cet avertissement est pour quand IDisposable n'est pas correctement mis en œuvre. Les objets en question (FileStream, StreamReader) mettre en œuvre IDisposable correctement & l'avertissement peut être ignoré. Même si je suis d'accord avec les points soulevés par Dan, Daniel, hvd et paulsm4. Ma réponse ne génère pas d'alerte, mais il ne risque une undisposed FileStream si le constructeur streamreader déclenche une exception. Merci à vous tous pour votre aide.
- Ce modèle est ridicule. Disposer les objets plusieurs fois est généralement sans danger (je ne connais pas un seul cas où il ne serait pas). Ce code est de très mauvaise qualité et ne devrait pas être recommandée par Microsoft. Aussi, c'est pas sécurité dans le cas d'une asynchrones exception juste avant "fs = null;".
- donc merci de poster votre réponse.
- pas besoin, plusieurs réponses existent. Juste essayer d'avertir les gens parce que beaucoup seraient séduits par le statut "accepté" et le haut décompte des voix (ce qui n'est pas une chose stupide de compter sur tant que débutant, si vous n'avez pas d'autre moyen de décider). N'utilisez pas ce code.
InformationsquelleAutor Dan
15

Visual studio est un "avertissement" moi, je suis l'élimination de fs plus d'une fois.

Vous êtes, mais c'est très bien. La documentation pour IDisposable.Disposer lit:

Si un objet Disposer méthode est appelée plus d'une fois, l'objet doit ignorer tous les appels après la première. L'objet ne doit pas lever une exception si son Disposer méthode est appelée plusieurs fois.

Sur cette base, l'avertissement est faux, et mon choix serait de laisser le code tel qu'il est, et de supprimer l'avertissement.

InformationsquelleAutor
6

Comme Dan la seule réponse qui ne semble travailler avec StreamWriter, je crois que ce pourrait être la réponse acceptable.
(Dan réponse sera toujours donner le cédé deux fois en garde StreamReader - Daniel Hilgarth et exacerbatedexpert mentionne, StreamReader dispose la filestream)
```
using (TextReader tr = new StreamReader(new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite)))
{
    string line;
    while ((line = tr.ReadLine()) != null)
    {
        //Do work here
    }
}
```
Ceci est très similaire à Daniel Hilgarth réponse, modifié pour appeler dispose via l'Utilisation de la déclaration sur le StreamReader comme il est maintenant clair StreamReader va appeler dispose sur FileStream (Selon tous les autres postes, la documentation de référence)

Mise à jour:

J'ai trouvé ce post. Pour ce qu'il vaut.
Ne l'élimination streamreader fermer le flux de données?
- Pas certain à propos de la gestion des exceptions, cependant. Je pense que toutes les exceptions qui allait se passer dans le constructeur FileStream et, par conséquent, ne pas le faire à l'initialisation de StreamReader. Donc dans ce cas je n'ai pas à vous soucier d'un undisposed FileStream en raison d'une exception dans le StreamReader. J'ai peut-être tort, bien sûr...
- Le using (f(x)) { } déclaration est vraiment compilé comme y = f(x); using(y) { }. Donc, toute exception levée par l'initialiseur de la using instruction de ne pas déclencher l'implicite finally déclaration. La meilleure façon de contourner ce problème est de concevoir des constructeurs à l'exception de sécurité et de propreté-ressources après un lancer, qui, je crois, le Stream classes.
- Comme je l'ai dit, je pense que mon exemple est exagéré, et dans le cas de la StreamReader classe, je pense que le ci-dessus est tout à fait bien, mais si vous utilisiez une autre classe autre que StreamReader, ou qu'ils changent la mise en œuvre dans le futur tel qu'il est possible que le constructeur lance une exception après l'intérieure IDisposable dépendance a été instancié, puis l'intérieur IDisposable ne seraient pas disposés. J'ai encore le droit de vote à l'exemple que j'ai posté est le plus sûr.
- Dan - votre exemple en jette toujours visual studio avertissement, c'est pourquoi je l'ai enlevé car la réponse. Il ne va pas jeter l'avertissement avec StreamWriter. Juste StreamReader comme streamreader dispose de l'objet interne et VS2012 sait que.
- Le code que vous utilisez aujourd'hui doit émettre un avertissement, quelque chose comme CA2000.
- Selon la documentation, vous avez raison. Il le devrait. Cependant je l'ai juste testé. En utilisant à la fois mon code et le code de la CA2000 doc (qui n'a pas échappé à la barre oblique inverse, heh). Il ne soulève pas CA2000. Bizarre. Je vais tenter de regarder plus loin avant que je marque ce comme réponse.
- Puis-je demander quel a été le résultat de votre enquête?
InformationsquelleAutor JHubbard80
2

Oui, la bonne façon serait d'utiliser votre première alternative:
```
using (FileStream fs = new FileStream(filePath, FileMode.Open,
                                      FileAccess.Read, FileShare.ReadWrite)) 
{ 
    TextReader tr = new StreamReader(fs); 
    //do stuff here 
} 
```
La raison est la suivante:

L'élimination de la StreamReader ne dispose que de la FileStream donc, c'est en fait la seule chose que vous devez éliminer.

Votre deuxième option (juste à l'intérieur "à l'aide") n'est pas une solution car elle permettrait de quitter le FileStream undisposed si il y a une exception dans le constructeur de la StreamReader.
- J'aurais pensé qu'il était important de disposer de l'objet StreamReader juste au cas où cet objet a des éléments qui doivent être éliminés en tant que bien. Il peut simplement être connu (par l'intermédiaire de la réflexion, d'autres) que StreamReader ne dispose que de la FileStream, mais aussi le quotidien d'un situation similaire à la pratique, je ne peux pas le prédire. Lorsque le lecteur est passé à un argument de type chaîne, j'imagine qu'il crée et dispose de la filestream il crée lui-même à l'interne. Lorsqu'il est passé d'un filestream je suppose qu'il ne dispose pas de l'objet qu'il a reçu comme un arg car il ne sait pas si le flux continuera à être utilisé à l'extérieur.
- Votre hypothèse est fausse. StreamReader, en effet, disposer le Flux a été adoptée, c'est ce qui est à l'origine de votre avertissement en premier lieu. Vous avez vu juste même si, à l'aide de mon code peut être problématique si (1) la classe ne change jamais sa mise en œuvre et (2) vous passez votre base de code de cette nouvelle version. Si vous voyez cela comme un problème avec l'alternative prévue par Dan. Je n'aurais jamais utiliser ces encombrants code dans un scénario simple comme ça car il n'ajoute pas n'importe quel avantage.
- Juste assez. Il semble étrange qu'il prend possession de l'élimination d'un objet créé et passé à l'extérieur, cependant. Je sais que c'est très sanglant peu probable que je voudrais l'utiliser à l'extérieur dans ce contexte spécifique, mais je me dis que si je l'ai créé à l'extérieur que je devrais être responsable du choix quand il doit être éliminé. Merci encore pour votre aide. Je dirais à la fois vos réponses sont tous les deux corrects dans leur propre chemin. Accepter une réponse à un tirage au sort.
- D'accord, je l'aurais mis en œuvre StreamReader différemment, trop. Ce comportement bizarre, en fait, a me piquer dans le passé, comme je l'ai été prise en ObjectDisposedExceptions lors de l'accès au stream je n'avais pas encore éliminés après l'élimination de la StreamReader qui l'a utilisé...
- Aha. Soins à élaborer?
- Vous avez besoin d'apprendre à lire correctement. Je l'ai écrit jetez la FileStream. Celui qu'il a été passé. Le contexte de cette question a été un FileStream transmis dans un StreamReader...
InformationsquelleAutor Daniel Hilgarth
1

C'est parce que la façon dont vous avez utilisé StreamReader dispose le ruisseau quand il est éliminé. Donc, si vous mettez le flux de trop, c'est être disposé à deux reprises. Certains considèrent cela comme une faille dans StreamReader - mais c'est qu'il ya aucun-le-moins. Dans VS 2012 (.NET 4.5) il y a une option dans StreamReader de ne pas disposer de la rivière, avec un nouveau constructeur: http://msdn.microsoft.com/en-us/library/gg712952
- Je vous recommande également d'utiliser l'étendue constructeur pour éviter ce massif de tracas. Il y a tellement de choses qui peuvent mal se passer entre le moment où le flux est attribué pour le lecteur et le point, il sait qu'il doit disposer du passé dans le flux, ce qui pourrait empêcher le flux provenant de l'aliénation à tous. Dans ce cas, Microsoft fait une erreur en permettant à l' StreamReader d'aller au-delà de sa responsabilité. Il provient probablement de la mentalité de toujours disposer IDisposable ressources, mais la valeur par défaut dans ce cas devrait être le contraire, et l'option étendue devrait être de jeter si demandé.
- Là où cela devient plus évident est le MemoryStream objet. Très probablement, vous NE voulez PAS qu'elle a disposé de la même après qu'il est lu. Surtout utilisé dans les tests unitaires, mais il n'prouver un point.
InformationsquelleAutor exacerbatedexpert
1

Deux solutions:

Un) en qui Vous avez confiance Réflecteur ou de la Documentation et vous savez *Reader et *Writer va fermer le sous-jacent *Stream. Mais attention: il ne fonctionne pas en cas de levée d'une Exception. Ce n'est pas la méthode recommandée:
```
using (TextReader tr = new StreamReader(new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite)))
{
    //Code here
}
```
B) Vous ignorez l'avertissement que de la documentation états The object must not throw an exception if its Dispose method is called multiple times. C'est la méthode recommandée, car il est à la fois une bonne pratique de toujours utiliser using, et la sécurité en cas de levée d'une Exception:
```
[SuppressMessage("Microsoft.Usage", "CA2202:Do not dispose objects multiple times")]
internal void myMethod()
{
    [...]
    using (FileStream fs = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
    using (TextReader tr = new StreamReader(fs))
    {
        //Code here
    }
}
```
InformationsquelleAutor Cœur
0

Compte tenu de toutes les absurdités de cette (parfaitement légitime!) question généré, ce serait ma préférence:
```
FileStream fs = null;
TextReader tr= null;
try
{
    fs = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite);
    tr= new StreamReader(fs);
    //Code here
}
finally
{
    if (tr != null)
        tr.Dispose();
    if (fs != null)
        fs.Dispose();
}
```
Les liens ci-dessous illustrent parfaitement légal de la syntaxe. OMI, cette "aide" de la syntaxe est de loin préférable à imbriquée "à l'aide". Mais je l'avoue -, il ne pas résoudre la question d'origine:
- http://blogs.msdn.com/b/ericgu/archive/2004/08/05/209267.aspx
- .NET - Remplacement imbriquée à l'aide des états avec la seule aide de déclaration
À mon humble avis...
- Je viens de réaliser que vous reconnaissez ce fait maintenant, mais pour souligner pour les futurs lecteurs) cette question a été lancé sur visual studio 2012 mises en garde. Le code ci-dessus soulèvent encore de cet avertissement. Pour référence, j'ai copier/coller le code ci-dessus dans un programme de test pour vérifier l'avertissement se produit encore: "CA2202 Ne jetez pas les objets plusieurs fois l'Objet 'fs' peuvent être éliminés plus d'une fois [...]. Pour éviter de générer un Système.ObjectDisposedException vous ne devriez pas appeler dispose de plus d'une heure sur un objet." C'est parce que VS2012 sait streamreader est l'élimination de la filestream
- Donc je suppose que votre solution est "try/finally: DANS; l'aide:" À" 😉 Correct?
- Votre empilées, qui utilise encore de ne pas corriger l'avertissement et à insulter les autres ne vous donne pas de crédibilité
- 1) "empilés de l'usage" (2 lignes + 1 jeu de bretelles) ne sont qu'une option. L'OMI a beaucoup plus agréable que de stupides, inutiles "imbrication" (avec les extra-accolades). 2) "imbrication" et "empilement" de générer à la fois le même IL en byte code. Nous sommes tous d'accord sur ça 🙂 3) dans la mesure où il ne résout pas l'avertissement (et je l'ai dit comme beaucoup), je ne vous embêtez pas avec le stupide "à l'aide" à tous. Je venais de tout faire avec un (un seul!) essayer/débarrasser de bloc.
InformationsquelleAutor paulsm4

Vous devez vous connecter pour publier un commentaire.