CSIDL_COMMON_APPDATA or CSIDL_COMMON_DOCUMENTS

I am trying to get my app Vista compliant and am not sure where to put app data. My software uses about 10 files and produces other files. After reading some say CSIDL_COMMON_APPDATA others say CSIDL_COMMON_DOCUMENTS
I know my exe goes to Program Files. Which is correct ?

Not just Vista compliant, but XP and 2000 compliant too ;)

You can find the list of CSIDL special folders (with descriptions) here: http://msdn.microsoft.com/en-us/library/bb762494.aspx

The _Documents folders are for files that you want the user(s) to see (in the "My Documents" or "Shared Documents" folders).
The _AppData folders are for files they shouldn't see (but can if they have permissions, and know what they are doing).

The _Common_ folders apply to all users on that particular computer.


Note that for single-user AppData you have two choices - CSIDL_LOCAL_APPDATA which is fixed to that particular machine, and the roaming version CSIDL_APPDATA which will be available to them on any computer on the network they log in to.

Quote:

---

Originally Posted by si_the_geek

Not just Vista compliant, but XP and 2000 compliant too ;)

You can find the list of CSIDL special folders (with descriptions) here: http://msdn.microsoft.com/en-us/library/bb762494.aspx

The _Documents folders are for files that you want the user(s) to see (in the "My Documents" or "Shared Documents" folders).
The _AppData folders are for files they shouldn't see (but can if they have permissions, and know what they are doing).

The _Common_ folders apply to all users on that particular computer.


Note that for single-user AppData you have two choices - CSIDL_LOCAL_APPDATA which is fixed to that particular machine, and the roaming version CSIDL_APPDATA which will be available to them on any computer on the network they log in to.

---

thanks for the info
Looks like i have to make decision, because down the road i plan making a network version.
I don't see why vb even has App.path, don't seem you can use it for anything

There are several valid purposes for it, such as having multiple instances of your program on the same computer and determining which of them was run.

Unfortunately finding special folders isn't as easy, and it isn't made particularly clear that you should be using them.

Quote:

---

Originally Posted by isnoend07

I don't see why vb even has App.path, don't seem you can use it for anything

---

Another important consideration is the intended market for VB when it was an active product. The main target was for pre-NT Windows OSs and small personal projects and in-house applications.

The special folders came along late in Windows, and were only encouraged beginning with Windows 2000. By then VB6 had been out for a long time, and since VB7 had been dropped we never saw intrinsic support for these kinds of things in the language or "runtime extended" components (as they're called now).

VB5 and 6 did come in an Enterprise Edition, but the additions focused on application life cycle management, MTS/DTC (later COM+), and Web-oriented features.

VB was never intended to be used for creating shrink-wrapped software products any more than .Net languages are. Microsoft always viewed this as the domain of C++.

So even in VB.Net it isn't obvious when and how to deal with special folders. The only real assistance added in .Net was a set of Framework wrappers for the API calls. If you check both the official manuals for VB6 and any VB.Net version you'll find no specific mention of dealing with special folders. This is left as a topic within documents discussing Windows Application Guidelines related to 3rd party commercial software development and in the Windows SDK.