Почему XmlTextReader не работает при вызове неподдерживаемой Stream.Length?

-1

У меня есть XmlTextReader, и я передаю его в System.Net.ConnectStream. Если я вхожу в отладчик, я вижу, что ConnectStream не поддерживает свойство Length, и это вызывает исключение NotSupportedException.Почему XmlTextReader не работает при вызове неподдерживаемой Stream.Length?

Теперь я подкласса Stream и передаю экземпляр моего класса. Мой класс также бросает NotSupportedException на get() accessor Length, но на этот раз все мои модульные тесты терпят неудачу с NotSupportedException.

Документация XmlTextReader не говорит, она требует второстепенной длины потока, и это явно может использовать один, который не - что происходит?

(Это .NET 3.5 Client)

источник

2015-10-29 sebf

Что возвращает ваш «Stream.CanSeek»? Было бы полезно, если бы вы могли предоставить краткую, но полную программу, демонстрирующую проблему. –

Вы пробовали XmlDocument. Супер прост в использовании, если вы не используете большие куски XML. –

@JonSkeet - Мой поток возвратил CanSeek как истинный (который он может в данных, которые он уже имеет - он просто не знает, сколько данных он может получить), в отличие от ConnectStream. Если я изменю это на false, XmlTextReader отлично работает. Спасибо за указатель! Если вы добавите это в качестве ответа, я соглашусь с ним. – sebf

Если а Stream возвращает истину от CanSeek, он предположил, что Length, SetLength, Position и Seek все поддерживаются. Некоторый код может протестировать CanSeek и использовать результат, чтобы оптимизировать его поведение - как, кажется, здесь. Когда вы вернетесь true от CanSeek, но затем отбросьте исключение в Length, это нарушит не-ужасно хорошо документированный договор Stream.

Если вы не можете поддержать недвижимость Length, то лучше всего вернуть false из CanSeek.

источник

2015-10-29 20:30:29

Почему XmlTextReader не работает при вызове неподдерживаемой Stream.Length?

ответ

Смежные вопросы