.NET v3.5 dependency
While indeed it seems that even WiX v4.0 has that problem unsolved I am not sure it's that simple as WiX internal bug. I have tested the "CustomUISequence" sample as it is on a fresh Win10 (en-gb_windows_10_multiple_editions_version_1511_updated_apr_2016_x86) and the sample works just fine. It means that Wix# default .NETv3.5 dependencies are successfully remapped to the v4.5 at run time
Judging from the error stack you provided it seems like it is one of the user assemblies (not WiX infrastructure) is failing to load. Meaning that this assembly has some extra dependency in your case but not in case of the "CustomUISequence" sample. Thus if you can identify what API call from your code is upsetting the deployment you can potentially solve the problem by using an alternative (remappable) API. Though it may not be possible for various reasons...
WixSharp UI Dialog
I think it might be related to the fact that the "Id1" property is being set at different stages of the execution sequences in these two tests. And in fact they are two different execution sequences: Load at UIExecute and BeforeInstall at InstallExecute. This is the complicated nature the MSI runtime architecture.
I cannot completely exclude that there is some defect in the code but you presented a very convincing test case where you are using WiX functionality directly (Session[...]) without any Wix# interface and clearly it doesn't work as expected. I cannot offer you any work around except using the code version that works. But I will try to reproduce it in my environment and see if I can get more information about it.
While indeed it seems that even WiX v4.0 has that problem unsolved I am not sure it's that simple as WiX internal bug. I have tested the "CustomUISequence" sample as it is on a fresh Win10 (en-gb_windows_10_multiple_editions_version_1511_updated_apr_2016_x86) and the sample works just fine. It means that Wix# default .NETv3.5 dependencies are successfully remapped to the v4.5 at run time
Judging from the error stack you provided it seems like it is one of the user assemblies (not WiX infrastructure) is failing to load. Meaning that this assembly has some extra dependency in your case but not in case of the "CustomUISequence" sample. Thus if you can identify what API call from your code is upsetting the deployment you can potentially solve the problem by using an alternative (remappable) API. Though it may not be possible for various reasons...
WixSharp UI Dialog
I think it might be related to the fact that the "Id1" property is being set at different stages of the execution sequences in these two tests. And in fact they are two different execution sequences: Load at UIExecute and BeforeInstall at InstallExecute. This is the complicated nature the MSI runtime architecture.
I cannot completely exclude that there is some defect in the code but you presented a very convincing test case where you are using WiX functionality directly (Session[...]) without any Wix# interface and clearly it doesn't work as expected. I cannot offer you any work around except using the code version that works. But I will try to reproduce it in my environment and see if I can get more information about it.