VirtualStore not working on Vista x64

Question

I have a little tray application that wants to write to its own folder under the Program Files directory. I know this is not an ultimate design and I will fix it, but first I want to understand how this works.

Running this on a 32-bit Vista machine it writes the files to the VirtualStore and it works just like it should.

But when installing this on a Vista 64-bit machine I immediately get hit with an UnauthorizedAccessException for trying to write to the directory within Program Files (and Program Files (x86)).

The VirtualStore redirect does not seem to work on Vista 64-bit. Any ideas?

It's a C# app written in Visual Studio 2008 and I use a FileStream obj to persist the stream to disk.

Answer 1

So I actually got this working by compiling all projects to target platform x86. So x64 does not work with VirtualStore on Vista 64 and neither does compiling to "Any CPU". And I had to set it for the entire solution (in the Configuration Manager), just setting it for each individual project didn't work.

Time to rewrite it using AppData folder or IsolatedStorage. Thanks for all the help!

Answer 2

Have more info about error ?
Do you use sysinternals tools for monitor execution/access errors ?
Take a look Event viewer for error too.

Answer 3

I'd just fix it now. You should never have been writing your stuff to that directory anyway, it violates the guidelines. Your product won't work when there's multiple users logged on to the server at the same time, even pre-VISTA.

Vista 64-bit will detect that you're a 32-bit app and will automagically redirect your attempts at modifying "Program Files" to "Program Files x86". In fact, it totally makes you believe you're running on a 32-bit system (see here).

I suspect there's extra protection in this emulation layer from programs trying to change things under Program Files. Or maybe the ACLs are set better under Vista 64-bit (or the emulation layer which is more likely).

Bottom line: don't do what you're doing, Microsoft has been telling us not to do that for a long time now.