Yes ICE validation sometimes leads to the wired, hard to interpret and difficult to deal with results. And what even more annoying that ICE errors/warnings are not even errors and shouldn't be even raised in the first place.
I suggest that you have a look at the emitted WXS file and verify that the misbehaving XML code is indeed what you need. And after that you can disable the ICE specific test(s) with light.exe command line switches.
The switch can be specified via
Note that Wix# already tries resolve some absurd ICE constrains by auto-injecting ICE required elements, which are strictly speaking unnecessary for your deployment. But it looks like in your case it isn't enough. Though may be this auto-injection in fact conflicts with your setup definition... Anyway you can also experiment by disabling auto injection via
I suggest that you have a look at the emitted WXS file and verify that the misbehaving XML code is indeed what you need. And after that you can disable the ICE specific test(s) with light.exe command line switches.
The switch can be specified via
Compiler
or Project
LightOptions field, which by default already passes some arguments for warnings disabling:staticpublicstring LightOptions = "-sw1076 -sw1079";
AutoElements.DisableAutoKeyPath
.