Wixsharp: RegValue for PerUser install causes error ICE57

[mgkeeley]

When using a RegValue for a PerUser install (and writing to the HKCU hive), an error is produced:

Error ICE57: Component 'Registry.1' has both per-user and per-machine data with a per-machine KeyPath.

This is due to Compiler.GetTopLevelPermanentDir() - this always returns a perMachine location. For perUser projects, perhaps the Compiler should use the first found directory (as it did previously).
Or another solution might be to use the first found directory in the project, and if that doesn't exist, use the well-known directory.

XElement topLevelDir = GetTopLevelDir(product) ?? GetTopLevelPermanentDir(product, regVal.Win64);

Here is an example setup to reproduce the error:

var project = new Project("MyProduct",
               new Dir(@"%LocalAppDataFolder%\My Company\My Product", new File(@"readme.txt")),
               new RegValue(RegistryHive.CurrentUser, @"Software\My Company\My Product", "LICENSE_KEY", "123456")
            );
project.InstallScope = InstallScope.perUser;
project.BuildMsi();

WixSharp 1.9.4
Wix 3.11.1

[oleg-shilo]

Thank you Michael.

I will have a look it but doe to some competing priorities with this and the other projects I will not be able to do it promptly. :o(

Do you have any work around or you are blocked?

[oleg-shilo]

BTW, thanks for such an informative feedback :o)

[mgkeeley]

I have a rather messy workaround in WixSourceGenerated, essentially moving all the RegistryValue nodes to our install directory node, but there are some issues with keypath etc.
I am not sure about the reason for the change from using GetTopLevelDir to GetTopLevelPermanentDir (https://github.com/oleg-shilo/wixsharp/commit/371290e8#diff-e6e1f43734f6e4674db49c1fcc308e60L2297); but maybe as it currently doesn't work for perUser, as a quick fix, this could be reverted to the old behaviour for perUser installs?

[oleg-shilo]

OK, I had a look at the problem. It is a difficult one to have an elegant solution for :o(

---

First of all I found that your sample exhibits the same behavior regardless of project.InstallScope value.

---

Next, "GetTopLevelPermanentDir vs. GetTopLevelDir".
The idea was that GetTopLevelPermanentDir works slightly better than GetTopLevelDir because the registry key in this case belongs to a permanent system dir but not to a user dir.

It is still shocking tough to enclose a system wide entity that has nothing to do with a file system into a directory. But the containment is slightly better ("wider") in this case.

GetTopLevelDir(product) ?? GetTopLevelPermanentDir(product, regVal.Win64) does help but only in your specific case. If it is a no directory pure registry setup then the ICE57 error is back.

---

You can address this problem by disabling another WixSharp work around that is having a side effect in this case:
```C#
AutoElements.DisableAutoKeyPath = true;

var project = new Project("MyProduct", ...

```

Now, the final argument. :o)
ICE57 is an excellent example of over-engineering. It has no practical value for the user. MSi/WiX actually recognizes that by... ignoring this very error and generating a perfectly working msi. Thus it's kind of FYI error. A warning to be more precise.

Thus you can simply ignore the error or disable it via the candle/light switches.

[mgkeeley]

Thanks for your analysis; I see the problem. I had thought that you couldn't install to a per-user registry location in a per-machine install; but that isn't true - why shouldn't you be able to do that? (I mean, you probably shouldn't... but who knows what requirements someone has...)

One other quick thought I had was to use TempFolder instead of ProgramFilesFolder for the registry entries. A quick test with that seems to work; but I am not sure about assuming the temp folder will always be there.... maybe it wouldn't matter even if it was created. There is no ICE warning if you install a HKLM registry entry in a perUser install in this scenario; but of course the install fails.

We will disable the warning for now in our setups.