Nous avons un problème avec un serveur et nous utilisons la classe StreamWriter. Quelqu'un a-t-il expérimenté quelque chose de similaire à la question ci-dessous? Si tel est le cas, quelle était la solution pour résoudre le problème?
Process completed successfully. ... (497 more lines) Process completed successfully. Process completed s
8 Réponses :
ne peut pas reproduire cela.
Dans des conditions normales, cela ne devrait pas et ne manquera pas.
Après beaucoup de creuser par plusieurs d'entre nous, nous sommes arrivés à la conclusion que cette troncature est causée par la compression de la compression sur le contenu dynamique du site Web. Nous avons pu recréer le problème de troncature localement et il a disparu lorsque nous désactivons la compression.
Cela semble certainement être un problème de "rinçage" pour moi, même si vous dites que vous avez ajouté un appel à flush (). Le problème peut être que votre streamwriter est juste une enveloppe pour un objet sous-jacent sous-jacent.
Je n'utilise pas généralement la méthode Fichier.creaText pour créer un flux d'écriture à un fichier; Je crée habituellement mon propre filtream, puis enveloppez-le avec un streamwriter si vous le souhaitez. Quoi qu'il en soit, j'ai rencontré des situations où je devais appeler rincer sur le streamwriter et le filtream, donc j'imagine que c'est votre problème.
Essayez d'ajouter le code suivant: < Pré> xxx
Je pensais à la même chose, mais Streamwriter rinçage le flux sous-jacent dans son Dispose .
Parfois même, vous appelez Flush (), cela ne fera que faire la magie. Becus Flush () provoquera un flux d'écrire la plupart des données dans Stream, à l'exception du dernier bloc de sa mémoire tampon.
try
{
// ... write method
// i dont recommend use 'using' for unmanaged resource
}
finally
{
stream.Flush();
stream.Close();
stream.Dispose();
}
Excellente solution pour le même problème que j'avais. Merci@bonshington
J'ai fait face au même problème
après avoir travaillé pour moi
Quel est le correctif ici?
eu un problème très similaire moi-même. J'ai trouvé que si j'étais compatible Autoflush avant de faire des écrites au flux et qu'il a commencé à travailler comme prévu.
logwriter.Autoflush = true;
Cela corrige mon problème parfaitement. Pourrait simplement fixer celui que l'OP demande à la question avait.
La raison pour laquelle cela a fixé mon problème: mon réveil a été balayé [car son appelant est passé hors de portée] avant qu'il ne puisse finir de pousser ses dernières lignes.
Cela a fait le tour pour moi:
Toute explication supplémentaire améliorerait votre réponse.
Utiliser le cadre 4.6.1 et sous stress intensif, cela a toujours ce problème. Je ne sais pas pourquoi cela fait cela, bien que j'ai trouvé un moyen de résoudre ce problème très différemment (ce qui renforce mon sentiment de bug .net).
Dans mon cas, j'ai essayé d'écrire d'énormes matrices déchiquetées sur le disque (mise en cache vidéo ). Étant donné que la matrice déchiquetée est assez importante, elle devait faire beaucoup d'écrivies répétées pour stocker un grand ensemble de cadres vidéo et, malgré leur dossier non compressé et que chaque fichier de cache a obtenu exactement 1000 images, les fichiers en espèces enregistrés avaient toutes les tailles différentes. P >
J'ai eu le problème lorsque j'ai utilisé ce p> Cependant, lorsque je lui ai fourni un type d'encodage, tous les fichiers enregistrés ont une taille égale et le problème a été passé. P> using (FileStream fs = new FileStream(generateLogfileName(), FileMode.OpenOrCreate))
{
using (StreamWriter sw = new StreamWriter(fs,Encoding.Unicode))
{
// all data written correctly, no data lost.
}
}
Dans mon cas, c'est ce que j'ai trouvé avec le fichier de sortie
Case 1: sans rinçage () et sans fermeture () Longueur de caractère = 23,371 776 Cas 2: Avec flush () et sans fermeture () longueur du caractère = 23,371,201 Cas 3: Lorsqu'il est fermé à proximité longueur de caractère = 23,375 887 (obligatoire) Ainsi, afin d'obtenir un résultat approprié , toujours besoin de fermer l'instance de l'écrivain.
Non lié à votre problème, mais l'appel à fermer est redondant ... Le Streamwriter sera éliminé à la fin de l'utilisation de l'utilisation de l'utilisation de
Oui, a mis à jour le poteau et supprimé cette ligne. Merci!
Personne n'écrirait une méthode de journalisation comme celle-ci. Il écrase les lignes enregistrées précédemment. À quoi ressemble le code vraiment ?
Êtes-vous capable de le reproduire avec ce petit morceau de code que vous avez posté? Vous n'êtes-vous pas-dans l'application réelle - accédant au flux de plusieurs threads?