Error in WixSharp_Load_Action

Jun 14, 2016 at 10:03 AM
Good day.
Can someone help with this.
2 win 10X64, on first all installations correct, on another always same error
ActionStart: Действие 11:39:53: WixSharp_Load_Action.
Info: Начало действия 11:39:53: WixSharp_Load_Action.
Info: SFXCA: Extracting custom action to temporary directory: C:\Users\PC\AppData\Local\Temp\MSI8002.tmp-\
Info: SFXCA: Binding to CLR version v4.0.30319
Info: Calling custom action WixSharp!WixSharp.ManagedProjectActions.WixSharp_Load_Action
Info: WixSharp aborted the session because of the error:
System.NullReferenceException: Ссылка на объект не указывает на экземпляр объекта.
в WixSharp.ManagedProject.GetHandler(String info)
в WixSharp.ManagedProject.InvokeClientHandler(String info, SetupEventArgs eventArgs)
в WixSharp.ManagedProject.InvokeClientHandlers(Session session, String eventName, IShellView UIShell)
Info: CustomAction WixSharp_Load_Action returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Wix 3.11.0.504
WixSharp.1.0.38.0
Jun 14, 2016 at 1:57 PM
Edited Jun 14, 2016 at 1:58 PM
So, it's happens if net framework 3.5 is not installed on the system. Is any way to rebuild installation so it's can use only 4.5 or higher ?
Jun 14, 2016 at 2:41 PM
Have a look at the extension method SetNetFxPrerequisite. This is how it's done in the CustomUIDIalog sample for .NET3.5:
project.SetNetFxPrerequisite("NETFRAMEWORK35='#1'", "Please install .NET 3.5 first.");
The exact condition property name and value can be found here: http://wixtoolset.org/documentation/manual/v3/customactions/wixnetfxextension.html
Though this article is very hard to read after WiX team reworked the documentation layout.

If I am not mistaken you can just use predefined condition for this:
project.SetNetFxPrerequisite(Condition.Net45_Installed, "Please install .NET 4.5 first.");
Where the value of Condition.Net45_Installed is a magic number evaluation (NETFRAMEWORK45 >= '#378389')
Jun 14, 2016 at 3:16 PM
Edited Jun 14, 2016 at 3:19 PM
Thanks for reply, but question, is any way to create msi whom don't need framework 3.5 for work (but can work with 4.5 or higher)
Core of Win# falls with error if 3.5 isn't in system

"Info: Calling custom action WixSharp!WixSharp.ManagedProjectActions.WixSharp_Load_Action
Info: WixSharp aborted the session because of the error:
System.NullReferenceException: object reference not set to an instance of an object"

But installing 3.5 on Win 10.... i can, but it's not nicely.
Can you help with it ?
Jun 15, 2016 at 2:49 AM
Running .NET 3.5 compiled assembly on OS with only .NET 4.5 installed is a common deployment challenge and this is my understanding that you can always solve it by modifying the app.config file. In case of Wix# you set it as this:
project.CustomActionConfig = "<location of app.config>";
Though in as most likely you are not specifying it Wix# uses the default app.config as follows:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v4.0.30319"/>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"/>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
        <supportedRuntime version="v2.0.50727"/>
        <supportedRuntime version="v2.0.50215"/>
        <supportedRuntime version="v1.1.4322"/>
    </startup>
</configuration>
And this app config should actually handle your case. That is why I am not entirely sure it's a compatibility issue as such. May be somehow absence of v3.5 triggers some other problem. Right now I don't have clean win10 to test it but I will try to find one. Will keep you informed.
Jun 15, 2016 at 10:38 AM
Edited Jun 15, 2016 at 8:29 PM
It's look like Wix problem
https://github.com/wixtoolset/issues/issues/3872
WixTasks.dll from version (WiX Toolset v3.10.2) also has a reference to Microsoft.Build.Utilities, Version=2.0.0.0, Microsoft.Build.Framework, Version=3.5.0.0
Because if i try your code it give same error until i install 3.5 on target system
Jun 15, 2016 at 10:58 AM
Edited Jun 15, 2016 at 11:00 AM
One more question
Using WixSharp UI Dialog
Var project = new ManagedProject(SetupFileName,
    ….
    new Property(new Id(“Id1”), “ 123 ”),
    ….
    New ExeFileShortcut (new Id(“id2”),”name”,”[Id1]”,””)
Why if I changed value of “Id1” in
project.BeforeInstall += Project_BeforeInstall;
private void Project_BeforeInstall(SetupEventArgs e)
{
    e.Session["Id1"] = “ 456 ”;
}
It’s changed in variable and in installed shortcut and all install correct, but if I try to change it, as example in (or an any other place)
void InstallDirDialog_Load(object sender, EventArgs e)
{
    MsiRuntime.Session[“Id1”] = “ 456 ”;
}
and doing something like this
private void Project_BeforeInstall(SetupEventArgs e)
{
    MessageBox.Show(e.Session["Id1"]);
}
It show “456”, but then it’s install, shortcut value will be “ 123 ” ?
Jun 16, 2016 at 6:55 AM
.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.
Jun 16, 2016 at 12:34 PM
.NET v3.5 dependency
Thanks for advice to check another API. It's was falling at code, that don't used in project but just was there, and has reference to dll that uses 3.5
Jun 16, 2016 at 2:15 PM
Great! It makes perfect sense now. :)