J'ai essayé après les règles de l'analyse de code sur cette méthode: Ajout de tout le Oui, j'ai lu d'autres messages sur ce sujet et j'ai essayé de l'appliquer,
Mais à la fin, je reçois toujours le même message. Essayez {} finaly {} bloque, mais c'était toujours hurler Sur moi que je ne respecte pas la règle 2202.
Tout le monde peut me donner une main avec cela?
4 Réponses :
Débarrassez-vous de ces deux lignes, ils ne sont pas nécessaires:
cs.FlushFinalBlock(); cs.Close();
Et déplacer myPassword = convert.tobase64string (ms.toarray ()); à la portée parent, pour vous assurer que CS a été rincé!
Obtenir toujours la règle 2202 sur ms .
Après le Documentation sur ce sujet devrait conduire à ce code:
Obtenir toujours la règle 2202 sur CS et ms
@DeMentic Qu'en est-il de si vous l'avez fait, mais si vous vous êtes débarrassé du cs.close () ? c'est-à-dire une combinaison de nos réponses
Même une combinaison des codes ne fonctionnera pas, je reçois toujours le 2202 sur le ms
Avec la nouvelle modification, ms et CS jette 2202. J'ai essayé tout ce genre de choses à la maison ... mais je ne pouvais pas comprendre pourquoi ça continue ...
Pour vous débarrasser de l'avertissement CA2202 pour Le problème CA2202 pour CS , supprimez simplement l'appel à son Fermer méthode.
ms est un peu plus complexe. L'avertissement est de recadrer parce que cryptostream a l'effronterie pour éliminer le flux qu'il a reçu via est constructeur, ce qui signifie qu'il y a un appel inapproprié à MS.Close () que vous pouvez 't éviter. La bonne nouvelle est que cette disposition intempestive n'a pas d'effets secondaires dans votre cas, et il en va de même pour la double disposition, vous pouvez donc gifler en toute sécurité sur un SuppressmessageAbute et ignorer le problème. (Pour les cas où vous avez besoin d'avoir réellement passé le flux pour survivre à sa disposition non acquise par quelque chose comme cryptostream , la technique habituelle consiste à utiliser une sous-classe de flux dont la disposition peut être empêchée par son code instanciateur.)
Je n'aime pas vraiment supréter aucune "erreurs", peut-être que je devrais refacturer mon code?
La documentation sur cet alerte d'analyse ( http://msdn.microsoft.com /en-us/library/ms182334.aspx ) donne cet exemple similaire à celui de la manipulation de flux: mais cela donne toujours l'erreur. Ce qui suit résoudra l'erreur: p> La raison est simple; Si l'écrivain disposera toujours du ruisseau pour vous. Seulement dans le scénario, l'auteur n'est pas créé avec succès si vous disposez du flux vous-même. Mais je dois admettre que j'aime beaucoup plus la syntaxe suivante, et si vous créez une mémoire Mémoire au lieu d'un filtream, les chances d'une exception survenant sont petites et je préférerais supprimer la ca. Veuillez noter que vous pouvez empiler à l'aide de déclarations, un «niveau de nidification» supplémentaire n'est souvent pas nécessaire. P> using (Stream stream = new FileStream("file.txt", FileMode.OpenOrCreate))
using (StreamWriter writer = new StreamWriter(stream))
{
// Use the writer object...
}
Vous aimez creuser des tombes? ;) Si le flux n'est pas créé avec succès, il n'est pas nécessaire de le disposer .. Suppression, comme je l'ai commenté dans la réponse ci-dessus, ce n'est pas quelque chose que j'aime faire. J'ai réussi à corriger le code en réactivant mon code.