469,282 Members | 2,257 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,282 developers. It's quick & easy.

How to close this XML file after reading?

I'm using
XDocument document = XDocument.Load (XmlReader.Create (file));

to load in contents of a XML-file for parsing.
However, i noticed that the file seems to be
locked by the process and i can't save changes
made to it in VS until it ends.

How can i close the file?

--
Regards
Konrad Viltersten
----------------------------------------
May all spammers die an agonizing death;
have no burial places; their souls be
chased by demons in Gehenna from one room
to another for all eternity and beyond.
Sep 3 '08 #1
8 21191
On Wed, 03 Sep 2008 15:23:25 -0700, K Viltersten <tm**@viltersten.com>
wrote:
I'm using
XDocument document = XDocument.Load (XmlReader.Create (file));

to load in contents of a XML-file for parsing.
However, i noticed that the file seems to be
locked by the process and i can't save changes
made to it in VS until it ends.

How can i close the file?
Assuming that the entire file is parsed in the Load() method, you could
pass it a TextReader instance instead of the filename. Then you've got
access to the i/o object directly and can close it yourself.

It does seem like the XDocument class itself ought to have a Dispose() or
Close(), or maybe just close the source file immediately after parsing. I
might be missing something here. :)

Pete
Sep 3 '08 #2
"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
On Wed, 03 Sep 2008 15:23:25 -0700, K Viltersten <tm**@viltersten.com>
wrote:
>I'm using
XDocument document = XDocument.Load (XmlReader.Create (file));

to load in contents of a XML-file for parsing.
However, i noticed that the file seems to be
locked by the process and i can't save changes
made to it in VS until it ends.

How can i close the file?
You need to close the reader:

XDocument document;
using (var reader = XmlReader.Create(file))
{
document = XDocument.Load(reader);
}
Assuming that the entire file is parsed in the Load() method, you could
pass it a TextReader instance instead of the filename. Then you've got
access to the i/o object directly and can close it yourself.
He's not passing the filename as it is - he's passing XmlReader already.
It does seem like the XDocument class itself ought to have a Dispose() or
Close(), or maybe just close the source file immediately after parsing. I
might be missing something here. :)
XDocument.Load(string) does close the file after loading it.
XDocument.Load(XmlReader), which is used in this case, obviously doesn't.
Sep 4 '08 #3
Peter Duniho <Np*********@nnowslpianmk.comwrote:
I'm using
XDocument document = XDocument.Load (XmlReader.Create (file));

to load in contents of a XML-file for parsing.
However, i noticed that the file seems to be
locked by the process and i can't save changes
made to it in VS until it ends.

How can i close the file?

Assuming that the entire file is parsed in the Load() method, you could
pass it a TextReader instance instead of the filename. Then you've got
access to the i/o object directly and can close it yourself.

It does seem like the XDocument class itself ought to have a Dispose() or
Close(), or maybe just close the source file immediately after parsing. I
might be missing something here. :)
I think it's the XmlReader which needs to be disposed:

XDocument document;
using (XmlReader reader = XmlReader.Create(file))
{
document = XDocument.Load(reader);
}
....

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
Sep 4 '08 #4
On Wed, 03 Sep 2008 22:18:42 -0700, Pavel Minaev <in****@gmail.comwrote:
He's not passing the filename as it is - he's passing XmlReader already.
I don't know how you know that. Nor do I know why anyone would name a
variable referring to an XmlReader "file" (sounds a lot more like a
filename to me). But if that helps the OP, great.
>It does seem like the XDocument class itself ought to have a Dispose()
or
Close(), or maybe just close the source file immediately after
parsing. I
might be missing something here. :)

XDocument.Load(string) does close the file after loading it.
I'll take your word that a version of the XDocument.Load(string) method
does, but based on a previous, recent thread (StreamReader not returning
last line of text) where current behavior is obviously different from
earlier versions, I don't see how you know for sure that the OP is using a
version of .NET in which XDocument.Load(string) closes the file.
XDocument.Load(XmlReader), which is used in this case, obviously doesn't.
How do you know that XDocument.Load(XmlReader) is being used? There are
three single-parameter overloads, and even if it's known that for all
versions of .NET Load(string) closes the file, there's still
Load(TextReader) which I would think would behave a lot more like
Load(XmlReader) with respect to closing the input source when done (i.e.
not doing that).

Pete
Sep 4 '08 #5
On Wed, 03 Sep 2008 22:28:34 -0700, Jon Skeet [C# MVP] <sk***@pobox.com>
wrote:
[...]
>It does seem like the XDocument class itself ought to have a Dispose()
or
Close(), or maybe just close the source file immediately after
parsing. I
might be missing something here. :)

I think it's the XmlReader which needs to be disposed:
Well, yes...or the TextReader. My second paragraph was more about what
the class should have in it, as opposed to what it actually does have in
it. :)
Sep 4 '08 #6
"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...
On Wed, 03 Sep 2008 22:18:42 -0700, Pavel Minaev <in****@gmail.comwrote:
>He's not passing the filename as it is - he's passing XmlReader already.

I don't know how you know that.
Well, er... let me just repost it:

XDocument.Load(XmlReader.Create(file));
Sep 4 '08 #7
On Wed, 03 Sep 2008 22:55:04 -0700, Pavel Minaev <in****@gmail.comwrote:
>>He's not passing the filename as it is - he's passing XmlReader
already.

I don't know how you know that.

Well, er... let me just repost it:

XDocument.Load(XmlReader.Create(file));
Huh.

I must be too tired. I read that line a _least_ a dozen times, several
times before I replied, and several more after reading your reply, trying
to glean what sort of secrets you were able to extract from the first post.

Heck, even now, having seen your quote, I'm still having trouble picking
out the XmlReader in the original post.

Sigh...
Sep 4 '08 #8
Peter Duniho <Np*********@nnowslpianmk.comwrote:
On Wed, 03 Sep 2008 22:28:34 -0700, Jon Skeet [C# MVP] <sk***@pobox.com>
wrote:
[...]
It does seem like the XDocument class itself ought to have a Dispose()
or
Close(), or maybe just close the source file immediately after
parsing. I
might be missing something here. :)
I think it's the XmlReader which needs to be disposed:

Well, yes...or the TextReader. My second paragraph was more about what
the class should have in it, as opposed to what it actually does have in
it. :)
But I don't think it should really be up to the XDocument to dispose of
anything in this case. It's not allocating the resources, nor wrapping
them in a permanent way, so I think it's entirely reasonable for the
caller to still "own" them and have to dispose of them.

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
Sep 4 '08 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Xah Lee | last post: by
2 posts views Thread by Brian Ward | last post: by
3 posts views Thread by Jofio | last post: by
2 posts views Thread by Sabin Finateanu | last post: by
7 posts views Thread by John Dann | last post: by
2 posts views Thread by fool | last post: by
3 posts views Thread by Archestic | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.