XmlDocument does not load deep enough when deployed.

If you're using FileSystemWatcher, then I'd have thought that monitoring the Changed event should tell you when the file has been fully written to.

Failing that, you could poll the file's GetLastWriteTime() method until it gives a changed value though I'm not sure it's really a better solution than what you're doing now :)

Think I have figured this out.
I was using a filesystemwatcher which triggered the system to read the file.
Apparently you can load the file into an XmlDocument (as well as a Linq XDocument) object without any error reported despite the fact that the file has not been fully written to disk.
During the debugging I had a breakpoint which halted the application so that the file could be fully written, so that must be why it always seemed to work during debugging.

Now to the next problem.
I am using something similar to this to find out when the file has been completely written. However throwing exceptions around does not seem like a good solution.

                for (int i = 0; i < 100; i++)
                {
                    FileStream fs = null;
                    try
                    {
                        fs = new FileStream(filePath, FileMode.Open, FileAccess.ReadWrite, FileShare.None, 100);
                        fs.Close();
                        break;
                    }
                    catch
                    {
                        AppendDebugInfo("Waiting for file to become ready.");
                        Thread.Sleep(1000);
                    }
                }


Any suggestions to how to know when a file has been completely written to disk?

I've no idea what could be causing that problem which is one of the strangest I've ever seen or heard about.

My only suggestion is to try using LINQ to XML instead of the legacy XmlDocument class:

using System.Xml.Linq;

// ...

XDocument xmlDoc = XDocument.Load(filePath);
MessageBox.Show(xmlDoc.ToString());

Yes of course =)

Douple, triple checked it.

I tried to run the same application under Windows 7 (X64) and there it worked (same xml-file).

Vista bug?

Update:
Tested with Windows 7 in a virtual environment, same problem. Extremely annoying!