I have an odd bug where my code returns a file not found exception but the file seems to be exactly where it should be. My project has some code to run a system cmdlet and look for the results of the cmdlet in an XML output file. We tell the cmdlet to put this output XML in a custom subdir of the system TEMP dir, e.g., C:\WINDOWS\TEMP\SomeFolder\output.xml. We then use the .NET XmlDocument class to open and parse the XML file.
On WinXP, this works. On my dev box, this works. On a clean Win7 test machine, it does not.
My first thought was that I'm running into Vista/Win7 File Virtualization, but our application manifest specifies that our app run as Admin -- and from what I've read, that should bypass file virtualization.
The other wrinkle is that our code likes to use UNC file paths, even if the file is local to the machine. (We have a requirement that the code in question may need to run the cmdlet on a remote machine, and therefore the output XML could be on a remote machine too.) So we try to open the XML file via \MATT-WIN7\C$\WINDOWS\TEMP\SomeFolder.xml rather than C:\WINDOWS\TEMP\SomeFolder\output.xml.
But I removed the UNC path code temporarily and a simple call to File.Exists() still says the XML file is not there, when Windows Explorer shows the file sitting exactly where I think it should be.
Is there some nuance of file virtualization that I have not read about yet?
My workaround is to move the output xml file somewhere else, but that will potentially break the "portability" of our code when it needs to run on a remote machine, because using the %TEMP% location is a location that can be resolved for remote computers pretty easily (via remote registry call to find the system environment variable).
I would prefer to leave the file where it is, and fix our code so it actually finds the file!