FR: Access to 32/64bit registry keys in Custom Actions (using .NET3.5)

[GilesBathgate]

.NET 3.5 is the recommended CLR for wixsharp setup projects, however support for accessing both the 64bit and 32bit windows registry was not added until .NET version 4.0

Fortunately, backwards compatible access can be achieved using the following from StackOverflow:
https://stackoverflow.com/questions/26217199/what-are-some-alternatives-to-registrykey-openbasekey-in-net-3-5

I've tidied up the code and provided example use here:
https://gist.github.com/GilesBathgate/326de8355ebc829061de5840e39b043b

It would be really handy to have this available as a feature in WixSharp to save having to implement this manually in custom actions.

[GilesBathgate]

@oleg-shilo What are the limitations regarding using .NET >= 4 I understand that the project templates add a ValidateAssemblyCompatibility call, but it seems removing this call and setting the project to .NET4.7 the installer still works...

[oleg-shilo]

Hi Giles,

The recommendation for using .NET3.5 is truly superficial. It's not based on any application field evidence. It is rather reflection of early stage of Wix# when .NET3.5 was still dominant and targeting the older CLR version was simply a safer choice in terms of probability of any compatibility issues.

I do not longer believe that v3.5 is a good recommendation choice and after your this very prompt will change the recommendation to .NET4.

And... the very current implementation of the ValidateAssemblyCompatibility actually already reflects the new recommendation:

public static void ValidateAssemblyCompatibility(Reflection.Assembly assembly)
{
    //this validation is no longer critical as Wix# MAnagedSetup now fully supports .NET4.0
    //if (!assembly.ImageRuntimeVersion.StartsWith("v2."))
    //    try
    //    {
    //        var msg = string.Format("Warning: assembly '{0}' is compiled for {1} runtime, which may not be compatible with the CLR version hosted by MSI. "+
    //                                "The incompatibility is particularly possible for the Embedded UI scenarios. " +
    //                                "The safest way to solve the problem is to compile the assembly for v3.5 Target Framework.",
    //                                assembly.GetName().Name, assembly.ImageRuntimeVersion);
    //        Debug.WriteLine(msg);
    //        Console.WriteLine(msg);
    //    }
    //    catch { }
}

[oleg-shilo]

I have just removed the ValidateAssemblyCompatibility calls completely.

Do you still think upgrading the recomendation to v4.0 automatically resolves registry 32/64bit roaming challenge?

[GilesBathgate]

Yes using NET4 makes this FR redundant.

[oleg-shilo]

• The VS Templates have been upgraded to .NET4.0 (https://marketplace.visualstudio.com/items?itemName=OlegShilo.WixSharpProjectTemplates)
• The runtime recomendation on Wiki has also been updated (https://github.com/oleg-shilo/wixsharp/wiki/Building-MSI-%E2%80%93-Step-by-step-tutorial)

All done now.

[GilesBathgate]

I am having difficulty Debugging using System.Diagnostics.Debugger.Launch() with .NET4. Do you experience this, is there a workaround?

[oleg-shilo]

No not really. I will be debugging your #704 so will tell you if I have the same problem.

[oleg-shilo]

Just wanted to check with you. Your work around for #704, why did you opt for messageRecord[2] while the original solution was doing messageRecord[1]:

. . .
string message = null;

bool simple = true;
if (simple)
{
    for (int i = messageRecord.FieldCount - 1; i > 0; i--)
    {
        message = messageRecord[i].ToString();
    }
}

Don't get me wrong, I do realize that the original solution looks quite questionable. That's why I need to debug it.

[oleg-shilo]

OK, when I started debugging I remembered a few tricks...

• First, your debugger will need to be elevated.
• Second, place in your code Debug.Assert(false);.
• Resist temptation to click 'Retry' in the assertion box 😄
• Use debugger "Attach to process". Select msiexec that has an assertion text as a title.
• You are done

Any other way my debugger fails to load the correct debug symbols.