So you are trying to install content into the folder:
Windows\Profiles\All Users\Documents\MyCompany\MyApp\Data ??

How are you currently deriving this location?  Just hard coding it, or reading from the registry?

Although you implicate the Sony Vaio as a potential sufferer from the Error 1320 situation, as you say it's more likely to be due to the location of the folder you are targetting being set to a non standard location. However, the operating system keeps track of the "All Users" shell folders in this location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

If you therefore read the value for the key "Common Desktop" at this registry location, you will find the exact location of the Documents folder in the All Users profile. Once you have this you can parse this into the full path you require, and use a SET DIRECTORY custom action to point your Directory Table entry associated with the components you are trying to install, to the correct path.

Hopefully, this will solve any issues with the folder locations being non standard.

Yes, the directories were created using the GUI - so the paths are hard coded.  I agree that your solution is the correct one - I just need to figure out how to do it.

 Also, this issue showed up as an issue with non-english installs, where the folder "Documents" is "Documenten". Clearly I need to figure out how to implement your solution as it is the correct solution.

I've added a Path Variable called RegistryCommonDocuments using the registry information as you suggested. It does seem like it is getting the correct info. In my case, it say the current value is "C:\Documents and Settings\All Users\Documents" which is correct.

I've added diretory table entries that use that Path Variable.  It checks out OK.

I've added the Create Folder Componets that create the folder for those new directories in the table.

I can go back to "Instalation Expert" and click on "Files".  There I see all my new directories under "RegistryCommonDocuments".  So all looks good.

However, when I run the install those directories are _not_ created.  They were created fine when I used the All_Users built in.  I'm missing a simple step, as no errors or complaints pop up.

Are you trying to create folders that are otherwise empty, or are you also trying to install files there.

Your original posting referred to problems with a Vista install, but the most recent posting refers to C:\Documents and Settings, which I would associate with an XP environment, as the Vista/Win7 equivalent is C:\Users as per your first post.

Generating a verbose log of the install may help you determine exactly what is going on, as the log will show the content of all properties and directory pointers.

Yes, I'm creating folders that the application uses to store files that should be able to be accesed by all users.

From a great deal of scowring the web, it seems that using the the correct paths, Windows does the mapping for you depending on the version of OS.

For XP:                              C:\Documents and Settings
For Vista and beyond:    C:\Users

From the apps perspective, this has worked fine on all systems I've tried so far.  And seems to be the right thing to do - although the whole thing is a bit too murky.

Thanks to your suggestion, I turned on logging and got the nature of the current problem.

From the Log:

MSI (s) (C0:14) [10:44:07:348]: Executing op: FolderCreate(Folder=C:\RegistryCommonDocuments\MyCompany\PCDock\Data\,Foreign=0,SecurityDescriptor=BinaryData)
CreateFolders: Folder: C:\RegistryCommonDocuments\MyCompany\PCDock\Data\

So, what is happening is that the path variable (RegistryCommonDocuments) that I created from the registry info was not correctly expanded, and was used leteraly.  Indeed, It did create the folders using the literal path name.

So all I need to figure out is how to indicate to the Directory table that I want it to expand RegistryCommonDocuments as a "macro" and expend it.  I've just tried the usual things which havent worked ($RegistryCommonDocuments or [RegistryCommonDocuments]).  The documentation isn't clear - or I haven't found the correct section yet.

Note:  I'm not refering to the system PATH variable (as in PATH=C:\WINDOWS\system32;C:\WINDOWS;..)
 

@EdT

EdT said:
> Once you have this you can parse this into the full path
> you require, and use a SET DIRECTORY custom action
> to point your Directory Table entry associated with the
> components you are trying to install, to the correct path.

Is this the step I'm missing to get the "path variable" to expand?  If so, I haven't figured out how to do this yet.

Thanks for your help!

How are you getting the information into RegistryCommonDocuments?  Are you using System Search, or a custom action, or what?   Are you doing this operating in the UI or Execute sequence?
Note that only public properties survive from the UI into the Execute sequence
Also, how are you trying to use this property at the moment?
Certainly, if you want to use the contents of the property as part of a path, then the format
[PROPERTYNAME] is the one to go for.

The documentation you have perhaps not yet found is the file called MSI.CHM, which is the windows installer SDK help file, and has information on various formatting syntax. If you use "Formatted" as your search string and look around hit 37 or 38 (varies with release of MSI.CHM) you will find the various property syntaxes such as [PROPERTY] and [!PROPERTY].

I'm setting the information for RegistryCommonDocuments via the "Installation Expert" panel Project Definitions -> Path Variables.
In that Panel, I added a "Registry Path Variable" and filled in the fields.  It does expand correctly (for my system) under the "Current Value" column.

To use it, I was adding an entry to the directory table then adding an entry to the "Create Folder" component.

Using path variables in the way you are trying to do this, is not going to work. First of all, path variables are not the same as properties, and secondly, their use appears to be more to do with the compilation phase to determine the location of source files, than for actually setting installation paths.
If you hit the F1 key while setting a registry path variable, the context sensitive help will give you further information including a link to "About path variables" description, or you can search the Windows Installer Editor help file.
What I believe you should do, is use system search to load the content of the registry key in question, into a public property, which you can then use in a Set Directory custom action.