John,

We have given this a little thought and we decided there are a number of our customers who will implement Vista's UAC to it's fullest at some point in the next year. With that in mind, we decided to stop writing to the Application directory, and to move the data and user's settings to the Documents and AppData (or Local_AppData) folders.

It was a bit of a pain switching this stuff but redoing our Installation scripts was harder than actually changing the program code since user's are already allowed to choose the data locations. Basically, it came down to not wanting to explain to any of our larger customers that they would have to make an exception in our case because our software did not play well with UAC. I'm sure IT depts will have to make many exceptions but I expect that over time, playing nicely with UAC will be a selling point and will make it easer for them to let our software on their systems. If I sell just one installation because I play nicely with UAC it will be worth the small amount of time it took.


If you're interested, this explains UAC and what can and can not be written to. It's a Best Practices Doc for Vista.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/AccProtVista.asp

Here's a little bit that was the deciding factor(s) for us:

The following was taken from the above Best Practices document:

Locating of Per-User Application Settings

For Windows Vista, the application settings that need to be changed at run time should be stored in one of the following locations.

Documents and Settings\{user}\Application Data (roaming)
Documents and Settings\{user}\Local Settings\Application Data (non-roaming)
Documents and Setting\All Users\Application Data (shared)
Documents saved by the user should be stored in the My Documents folder.

Note that a user's My Documents folder is no longer stored under Documents and Settings. In Windows Vista, a new root directory on the file system called Users now contains the profiles for users of the machine.

Because these directories have changed, developers are encouraged to use CSIDLs to locate the path to specific well-known directories in a system-independent way. For more information, see the MSDN article on CSIDLs.

An application needs write access to the file system. When running under a managed desktop, an application only has write permission to the following folders and their children.

Users\{user}\
Documents and Settings\All Users\Application Data
Note Non-administrators cannot write to Documents and Settings\All Users.
C:\Documents and Settings\All Users>echo foo > foo.txt
Access is denied.
C:\Documents and Settings\All Users>cd "Application Data"
C:\Documents and Settings\All Users\Application Data>echo foo > foo.txt
C:\Documents and Settings\All Users\Application Data>

Applications should not assume that they can write to other locations, such as the following:

c:\windows
c:\windows\System32
Program Files\{application}
C:\{application}

Note This will work if the user created the folder—which they can, by default.
An application is trying to specifically create C:\Documents and Settings\Profiles\{user} is not allowed since the user can only create folders under C:\Users\{user}. The location chosen appears to be confused based on where Microsoft has stored the My Documents folder on previous versions of the operating system.

Application settings that need to be changed at run time should be stored in one of the following locations.

Documents and Settings\{user}\Application Data (roaming)
Documents and Settings\{user}\Local Settings/Application Data (non-roaming)
Documents and Setting\All Users\Application Data (shared)
Documents saved by the user should be stored in the My Documents folder.

All paths should not be hard-coded but should use the Environment.GetFolderPath() function.

Application Defaults to Saving in a Protected Directory

Some applications allow users to save or export data to their local machine. Often, the dialog box defaults to places like C:\, which does not allow write permission when running as a non-administrator.


Jim



>We recently installed Vista RC1 and tested an application that we distribute and immediately ran into problems. Naturally, the UAC (User Access Control) is the problem that we did not anticipate or even know about until we installed Vista.
>
>For those that are familiar with the problems that UAC can cause, it appears that you should be developing your apps to run for "standard users" instead of "administrators". In the XP world, seems like everyone was an administrator and Vista is going to change this.
>
>In short, no more writing to the "Program Files" or "Windows" folder; and no more registry changes UNLESS you want to logon as an administrator to do this.
>
>We've decided to try and modify our apps so that they will run in XP or Vista without any special code or even knowing if they are in Vista. Here is what we determined.
>
>I know Rick Strahl (correct me if I'm wrong here Rick) suggested using
>SYS(2023) to determine the folder to your application system files. Currently, these are being stored in the application folder in Program Files... which is a big no-no under Vista.
>
>In our testing, SYS(2023) did not give us consistent results. In XP, on one occasion it was returning the C:\ folder. Conceivably, this was due to a setting in the config.fpw or an application config.??? file. We decided that this was too difficult to control because what is returned by SYS(2023) could be changed by a setting in the config.??? file.
>
>After reviewing the environmental variables that exist in both Windows XP and Vista, it looks like the ones that will give us what we are looking for is either the APPDATA or USERPROFILE environmental variable.
>
>The following shows an example of what we would do if using the APPDATA variable to determine where our applications system files should be created.
>
>In Win XP, Appdata returns ...
>
>C:\Document and Settings\UserName\ApplicationData
>
>In Vista, it returns
>
>C:\Users\UserName\AppData\Roaming
>
>(Note: We'd probably strip off the "Roaming" so as not to run into problems with roaming profiles, and append on "Local" to save in the Local application data folder.)
>
>To this we would create a folder for our application and store our application files that the user creates when running the application in that folder.
>
>
>Here is an example of how this would work:
>
>User name is: John
>Application Prefix is: JJF
>
>If running in XP we would save our application system files in:
>
>C:\Document and Settings\John\ApplicationData\JJF
>
>
>If running Vista, we would save our application system files in:
>
>C:\Users\John\AppData\Local\JJF
>
>
>If anyone else has given any serious thought to this, I'd sure love to hear your comments.