Looks like any C:\ folder is part of the virtualization, however it seems that the virtualization only takes effect if permissions to the folder remain unchanged (so that all users cannot write to that folder). If you are supporting existing code that uses the Program Files folder and you want to keep it this way then you can change the folder permissions during the install process using an install helper project. This way the UAC virtualization does not take effect, but this is not considered best practice. Also if you have existing Vista or Win7 users that were using virtualization and they install a newer version of your software which changes the permissions, then they will no longer be reading the virtual folder and they will complain that they cannot see their old data any more. My experience with the Virtualization is that it does not always seem to apply, possibly because users may have disabled UAC. Many users do this because it is easy to change, avoids the popup messages and makes their computer like win-XP, so then there is the problem of what database folder is being used. Hence the best practice is to use the CommonApplicationData folder as David says ... as long as you don't already have existing UAC-disabled users running on the Program Files folder. TIA Phil. _____
From: [email protected] [mailto:[email protected]] On Behalf Of PhilB Sent: Monday, 8 February 2010 7:58 AM To: 'ausDotNet' Subject: RE: Environment.GetFolderPath(Env.... - using a C: drive folder Are there any known problems with creating a specific folder on C: drive and copying in the database and xml files into that folder? This way the folder can easily be marked for sharing at some future date (if required) either by local or remote users. Also regardless of the Windows version, the database is always located in the same known folder. If the application was MyProg then the deployment could create a specific folder C:\MyProgData\ folder and copy in the database. >From then on the application would use the data from the new folder and if the users wanted to share that folder, then this would be easily achieved. I can only assume that the Windows lock-down and the Program Files Virtualization does not apply to this folder as it is outside the defined lockdown zone. TIA Phil. _____ From: [email protected] [mailto:[email protected]] On Behalf Of David Kean Sent: Sunday, 7 February 2010 12:32 PM To: ausDotNet Subject: RE:Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)Issue? You shouldn't be writing to Program Files - this is locked down by Windows. It's 'tricking' your app into thinking that its writing to Program Files, but it's redirecting the write to the virtual store. What information are you modifying in program files? _____ From: [email protected] [[email protected]] on behalf of Anthony [[email protected]] Sent: Saturday, February 06, 2010 4:40 PM To: 'ausDotNet' Subject: RE: Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)Issue? Yes From: [email protected] [mailto:[email protected]] On Behalf Of David Kean Sent: Saturday, 6 February 2010 3:33 AM To: ausDotNet Subject: RE: Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)Issue? Anothony: Are you writing to Program Files? _____ From: [email protected] [[email protected]] on behalf of [email protected] [[email protected]] Sent: Thursday, February 04, 2010 5:38 PM To: [email protected] Subject: RE: Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)Issue? Really? That doesn't sound right to me. I thought if your app works fine as a 64-bit version for 64-bit hosts then you compile one version of your app with the target as "Any CPU". It will run as a 64-bit or 32-bit app depending on the host. If you use the correct system calls for folder paths etc then it will just work. No need to compile a 64-bit and and 32-bit version. _____ From: [email protected] [mailto:[email protected]] On Behalf Of Ian Thomas Sent: Friday, 5 February 2010 9:23 AM To: 'ausDotNet' Subject: RE: Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)Issue? Really, you should compile a 64-bit version for your 64-bit host systems and a 32-bit version for 32-bit hosts. On a 64-bit system, registry and program files etc are virtualized so that a 32-bit app "sees" what appears to be a 32-bit Windows. Refer to (amongst many others) Raymond Chen ("Old New Thing" blog). However (and it has been said many times before) you shouldn't be storing your app's working or data files in that location. _____ Ian Thomas Victoria Park, Western Australia _____ From: [email protected] [mailto:[email protected]] On Behalf Of Anthony Sent: Friday, 5 February 2010 8:32 AM To: 'ausDotNet' Subject: Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)Issue? Iam using some code....Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles) which apears to return the same path when i use it on an application deployed by Clickonce or run through VS 2008 But i have noticed that it stores any files physically on the computer(Windows 7) under c:\Users\anthony\AppData\Local\VirtualStore\Program Files (x86)\test When i resolve the address in code the address is c:\Program Files (x86)\test I think this has been spoken about but what should i use to be able to store file on any computer in a consistent way? Is your <http://www.intellixperience.com/signup.aspx> website being IntelliXperienced? regards Anthony (*12QWERNB*) Is your website being IntelliXperienced? No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2664 - Release Date: 02/05/10 03:35:00 This email is intended for the named recipient only. The information it contains may be confidential or commercially sensitive. If you are not the intended recipient you must not reproduce or distribute any part of this email, disclose its contents to any other party, or take any action in reliance on it. If you have received this email in error, please contact the sender immediately and delete the message from your computer.
