1
votes

I'm trying to solve my issue with autogerating GUID for multiple components in same folder installed under AppData (per-user installation).

Before edit I had one component with 3 files. Then I've decided to use auto GUID for this component, so I have divided it into 3 component (each with one file). I thought that now I can use Component GUID with * and registry value with KeyPath=yes but it's not working. Any advice is very appreciated.

Here is code snippet:

<Directory Id='INSTALLDIR' Name='$(var.myInstallDir)'>

        <Component Id='MainExecutable' Guid='I_WOULD_LIKE_ASTERISK_HERE_ALSO_BUT_HAVE_HARD_CODED_GUID' >

          <RemoveFolder Id='RemoveINSTALLDIR' Directory='INSTALLDIR' On='uninstall' />
          <util:RemoveFolderEx On="uninstall" Property="APPLICATIONFOLDER" /> 

          <RegistryValue Root='HKCU' Key='Software\[Manufacturer]\[ProductName]' Type='string' Name='Path' Value='[INSTALLDIR]'  KeyPath='yes'/>

          <File Id='ffile1' Name='file1' DiskId='1' Source='file1'> </File>

          <Shortcut Id="startmenujfile" Directory="ProgramMenuDir" Name='$(var.myAppName)'
          Target="[SystemFolder]cmd.exe" Arguments=" /c START javaw.exe -jar [INSTALLDIR]file1.jar ."
          WorkingDirectory="INSTALLDIR"
          Icon="apsoiconmultiico" IconIndex="0" /> 

          <Shortcut Id="desktopjfile" Directory="DesktopFolder" Name='$(var.myAppName)'
          Target="[INSTALLDIR]file1.jar" Arguments=" ."
          WorkingDirectory="INSTALLDIR" 
          Icon="iconmultiico" IconIndex="0" /> 

        </Component>

        <Component Id='MainExecutable2' >
          <File Id='ffile2' Name='file2' DiskId='1' Source='file2' />
          <RegistryValue Root='HKCU' Key='Software\[Manufacturer]\[ProductName]' Type='string' Value='' KeyPath='yes'/>
        </Component>

        <Component Id='MainExecutable3' >
          <File Id='ffile3' Name='file3' DiskId='1' Source='file3' />
          <RegistryValue Root='HKCU' Key='Software\[Manufacturer]\[ProductName]' Type='string' Value='' KeyPath='yes'/>
        </Component>
      </Directory>

And error for components:

 error CNDL0230 : The Component/@Guid attribute's value '*' is not valid for this component because it does not meet the criteria for having an automatically generated guid. Components with registry keypaths and files cannot use an automatically generated guid. Create multiple components, each with one file and/or one registry value keypath, to use automatically generated guids.

Thank you

EDIT:

Thanks to @Stein Åsmul answer. I need to ask one more time..

I'm trying to solve this because we are moving from Java Web Start (jnlp) to very simple .msi file which installs only elementary files and shortcuts. Then the app itself has automatical update system which downloads all other files.

Our app can have "mupliple sets of versions" installed on same machine (like set A: "app 1 demo, app 2 test" and set B: "app 2 demo, app 2 test"). Every set and every version in the set can have different files (this is a job for update system itself).

Now the question. I'm a newbie in .msi installation so I'm not sure about many steps. I know productId, upgradecode.. but what about component GUID (in my case Component Id='MainExecutable') in enviroment with multiple sets of app installed on same machine (per-user but different directory - AppData/local/setA and AppData/local/setB) with registry KeyPath=yes? Can this component has fixed GUID for all our installations if productId is different (so hardcoded in .wxs for all installations)? Thank you for explanation.

1
To answer your secondary question that you tried to add: MSI is not suited for auto-upgrade applications that upgrade themselves in-place. MSI is a deployment technology and keeps track of all installed files and versions, an auto-upgrade system interferes with this. MSI is also not easy to use for multi-installations on the same system for design reasons and limitations. Recommend you use a different deployment technology, or change your deployment design. Are you in a corporate setting?Stein Åsmul
Yes, it's our company app. I have also tested deployment with .exe file (super easy compared to msi). But .msi can be easily deployed with AD. In case that user would do repair (but it's disabled) and install earlier version than nothing happer. Auto update system will bring back latest version. What about the second part of my edited question?user2014521
You can not auto-update an MSI installation and overwrite files on the fly without causing problems that are impossible to deal with. MSI keeps track of what was installed and repairs those files installed. Newer deployment technologies like AppV and MSIX might have what you need. I would investigate them. Check with your deployment guys if they allow AppV and / or MSIX. App-V "streams" apps in real-time to any client from a server.Stein Åsmul
As far as I understand, I can use concept of GUID = "" on component which should disable self-repair and other problems. So if I set in on component MainExecutable2, than add one file into and one RegistryValue with KeyPath='yes' (so exactly as in my question example) would it work? I was able to call candle.exe and light.exe.user2014521
Not recommended, but I have seen stuff like that used. I have even helped people package it so it worked without too many incidents. Uninstall will be a problem, as will be changed registry settings and cleanup that might cause self-repair to kick in. You will also have a hard time to determine what version is installed where? Why fight wind-mills if there are other technologies to use?Stein Åsmul

1 Answers

2
votes

Short Answer: You cannot use auto-guids for components that have the same / non-unique key path - which is the case for per-user registry key paths. Simpler approach: Install files to a per-machine location and copy them into each user-profile on application launch instead of installing them per-user via an MSI. This de-couples all user-profile files from common deployment problems (overwriting / resetting, upgrade problems, uninstall problems, etc...). Auto-Guids are possible for per-machine key paths - they are unique per component.

Per-User Key Path: HKCU\Software\Company\Product\MyKeyPath

  • Repeats for every user! => No auto-guid possible. It is not unique.
  • User 1: C:\Profiles\User1\Product\File.exe, Key path: HKCU\Software\Product\MyKeyPath
  • User 2: C:\Profiles\User2\Product\File.exe, Key path: HKCU\Software\Product\MyKeyPath

For the record, here is what would happen if you set a userprofile disk-based key-path (as opposed to a registry key path which you are supposed to use): Color illustration.

Per-Machine Key Path: C:\Program Files\Company\Product\Main.exe

  • Only one installation instance! Unique key path allows auto-guid.

Read-Only Templates: A general issue first: it is recommended that you don't install files directly into the user profile folders. Rather you should install them to your main installation folder under Program Files and then copy them in place during application launch for every user who uses the application. The files can then be copied to every user-profile on demand and on launch of the application (upgrades are possible too, if you implement it well).

Technically: You cannot use an auto-guid for components that has the same / non-unique key path. The technical reasons can perhaps be best understood by reading this old answer: Change my component GUID in wix? Essentially the key path must be unique in order to be able to create an automatic GUID, and this is not the case with per-user registry keys. The path is the same for all users - to the same registry key (even if the content is different for each user). A limitation of the MSI technology.

Note that if you install to a per-machine path you will be able to use auto-GUIDs since you can have a unique file key path for the component. This should work fine. Just move the files to a per-machine path and set an auto-guid. Upgraded files will overwrite older files and you can copy newer files over the ones in the user profile on launch - if desirable. A risky operation most of the time.


Cloud: I am fond of cloud-based approaches to download files into the user profile on-demand directly from the Internet or Intranet as an alternative to deployment via MSI. It all depends what you have access to.

More Details: There are too many pre-existing answers that revolve around the same points for there to be any value in rewriting it. Please check the below links for more details on the deployment of per-user files with MSI: