Problem mit Arraygröße und ASCII-File

Computer: Software & Programmierung .NET & C#
#1

Hallo, in einem Teil meines Programms wird die Anzahl der Zeileneinträge einer ASCII-Datei ermittelt:

string geleseneZeile = sr.ReadLine();
string[] geteilteZeile = geleseneZeile.Split((Trennzeichen).ToCharArray());
X = geteilteZeile.Length;

mit: sr = StreamReader-Objekt
Trennzeichen ist eigentlich immer „\t“

Auf meinem Heimcomputer funktioniert das ohne Probleme, aber auf dem Firmenrechner spuckt der für X immer 350 statt den richtigen 388 aus. Und wenn ich dann alle Zeilen durchgehe bis sr.EndOfStream, um auch die Anzahl aller Zeilen Y zu ermitteln,

while (!sr.EndOfStream)
{
sr.ReadLine(); Y++;
}

bekomm ich 277 statt 288 ! Weiß jemand, was hier schief läuft?
Danke schonmal

Bastian

#2

Hi!

Weiß jemand, was hier schief läuft?

Ich habe grad nur eine Vermutung: kann es sein, dass du unterschiedliche Framework-Versionen zuhause und im Büro hast?
Es gibt offensichtlich irgendwelche Unterschiede in der Implementierung der Split-Methode, guckst du hier: (2.0) http://msdn.microsoft.com/de-de/library/b873y76a%28V…
und hier (3.5) http://msdn.microsoft.com/de-de/library/b873y76a.aspx

Auch bei Readline könnte sich ja was geändert haben…

Versuche es mal auf eine .NET-Version zu bringen…

Gruß,
Andreas

#3

Hallo Andreas,

hatte zwar noch keine Gelegenheit, die Frameworks zu checken, aber hab einfach mak ein Debigging gestartet. Die ReadLine()-Funktion vom StreamReader-Objekt liest nur einen string ein, der 350 Werte umfasst, die durch „\t“ getrennt sind.

Hab mal in der MSDN gesucht:
http://msdn.microsoft.com/de-de/library/system.io.st…

http://msdn.microsoft.com/de-de/library/system.io.st…

Beide Funktionen sollen ja das gleiche machen. Wenn es der Fehler mit dem falschen Framework sein sollte, gibts da ne einleuchtende Erklärung für? Ist man mit der einfachen Read-Methode auf der sicheren Seite?

Gruß

Bastian

#4

Hi

Die
ReadLine()-Funktion vom StreamReader-Objekt liest nur einen
string ein, der 350 Werte umfasst, die durch „\t“ getrennt
sind.

Irgendwie stimmt da was nicht. Ist der String 350 Zeichen lang, müssen ja „\t“ beim Split entfernt werden und X dementsprechend kleiner sein. Überprüf doch mal nochmal dein Code vom ersten Posting. Aber gut, wenn er nur 350 liest, ist Split vermutlich in der Tat unschuldig.

Beide Funktionen sollen ja das gleiche machen.

Das stimmt schon mal nicht ganz:
3.5:Eine Zeile ist eine Folge von Zeichen, die mit einem Zeilenvorschub ("\n") oder einem Wagenrücklauf ("\r") endet, oder mit einem Wagenrücklauf, auf den ein Zeilenvorschub ("\r\n") folgt.
2.0: Eine Zeile ist eine Folge von Zeichen, die mit einem Zeilenvorschub ("\n") oder einem Wagenrücklauf endet, auf den ein Zeilenvorschub ("\r\n") folgt.

Sollten also im Stream „\r“ vorkommen, auf die kein „\n“ folgt, würde das neue ReadLine mehr Zeilen lesen bzw. bei „\r“ die Zeile abbrechen, wo 2.0er aber bis zum Ende lesen würde.
Ob dein Fehler auch damit zusammenhängt, kann man so natürlich nicht sagen… Vor allem, dann müsste ja bei 350 Zeichen mehr Zeilen gelesen werden und nicht auch noch weniger. (Also 350 Zeichen 288 Zeilen oder 388 Zeichen 270 Zeilen) ist aber anscheinend ja nicht der Fall… schon etws merkwürdig.

Gruß,
Andreas

#5

Hallo,

hab jetzt endlich rausgefunden, dass auf dem Firmenrechner die StreamReader-Klasse aus .net 3.5 und auf meinen PC die aus 2.0 verwendet wird, also danke für den Tipp.

Ist aber - zumindest aus meiner Sicht - keine Fortschritt von 2.0 auf 3.5. Muss dann wahrscheinlich doch auf die Read-Methode zurückgreifen.

Gruß

Bastian