title: Looping through a text file using StreamReader causes a "Cannot access a disposed object."
body: <p>I have the following basic code to read a text file from a StreamReader:</p>
  
  <pre><code>Using sr As New StreamReader(FileData)
    Dim line As String = String.Empty
    Do
      'Error occurs on the next line after looping 
      'past the *last* line in the file...sometimes
      line = sr.ReadLine()
      'Some code here to parse and process the line
    Loop Until (line Is Nothing) OrElse (line = String.Empty)
  End Using
  </code></pre>
  
  <p>I tried changing the Do Loop to <code>Do While Not sr.EndOfStream</code> I tried checking <code>If sr.ReadLine IsNot Nothing</code> and a few other things but I keep getting the <strong><em>Cannot access a disposed object. Object name: 'SslStream'</em></strong> error <em>after</em> all 105 lines have <em>successfully</em> been read and processed. This code has been working for a couple of years, but there seems to be some issue with certain files (recently) that is causing this problem.</p>
  
  <p>I opened the file and I didn't see anything out of the ordinary. No extra blank lines, funny characters or anything of the like. Just a normal file with 105 properly formatted lines. So even know there is something about this file causing the error, I need to obviosly handle this programatically.</p>
  
  <p>What can I do to prevent the <code>sr.ReadLine()</code> line of code from throwing that exception that I have not yet tried?</p>
  
  <p><strong>UPDATE</strong> Upon reading the last line of the file, the 'EndOfStream' property on the StreamReader goes immdeatly to: <strong>EndOfStream: {"Cannot access a disposed object.
  Object name: 'SslStream'."}</strong> It never toggles to 'True'. This makes checking for this condition problematic.</p>
  
  <p>I think I have figured out why this issue only occurs sometimes: if I add in a blank line to the file at the end, none of this ever occurs. It is only when the last line of the file contains data. Still, I should be able to handle this programatically. Telling the vendor supplying the file to always add a blank line at the end should not be the solution.</p>