WIxsharp debug custom action in console
Asked Answered
C

2

4

I have a custom action project which compiles to a .dll, I want to be able to step through my custom actions, i know the package can be changed to wixsharp.bin but this dosn't seen very practical. Regardless, I still tried this method but it didn't hit my breakpoints.

Wix uses: System.Diagnostics.Debugger.Launch(); which launches the action in debug, this dosn't seem to work for wixsharp but it's expected result is what i am trying to achieve.

I have seen that debug.assert can be used for debugging and i have also seen references to #if DEBUG #endif How do i debug correctly?

    [CustomAction]
    public static ActionResult CustomAction(Session session)
    {
        Debug.Assert();
        MessageBox.Show("Hello World!" + session[IISSessions.AppPoolName], "External Managed CA");

        return ActionResult.Success;
    }
Clavius answered 18/10, 2018 at 16:13 Comment(0)
C
3

Not quite sure what was causing the problem, I deleted my bin folder and then ran a build and it now seems to be working. System.Diagnostics.Debugger.Launch() does work correctly it needs to be contained within an #if DEBUG as @Stein Åsmul stated. Once built in DEBUG run the outputed .msi, you will be prompted to open an instance of visual studio when you hit your custom action during install.

   [CustomAction]
    public static ActionResult CustomAction(Session session)
    {

    #if DEBUG
            System.Diagnostics.Debugger.Launch();
    #endif
            MessageBox.Show("Hello World!" + session[IISSessions.AppPoolName], "External Managed CA");

            return ActionResult.Success;
     }
Clavius answered 19/10, 2018 at 12:30 Comment(1)
Thanks indeed the solution is you need to delete the WixSharp project's bin folder first.Farnesol
C
2

N.B!: I don't use WixSharp, but the below should be generic. At least some of it.

Debug Custom Actions: I just follow this procedure (since I generally use native code):

  1. Compile debug binaries and include in the package.
  2. Show a message box from the custom action.
  3. Use Visual Studio to attach to the process showing the dialog.
    • You attach to msiexec.exe for native, unmanaged code, and to rundll32.exe for managed code. System context or user context process depending on how the custom action runs.
    • Set a break point in code directly after the dialog and let it be hit.
    • This should work provided your source code matches what is in your debug binaries in the package (debugging symbols).

How-To Video: There is a video from Advanced Installer showing most of the process: Debug C# Custom Actions. Very good.


A step-by-step description of how to use C# (managed) custom actions with WiX.


This issue has come up a lot lately, most recently in this question / answer, section 4.

Here is some aging but good content on the topic from installsite.org: Debugging Custom Actions.


I ran a test on your own suggestion to verify that it works too for a regular WiX setup (the #if DEBUG makes the code only apply to debug builds):

#if DEBUG
   System.Diagnostics.Debugger.Launch();
#endif

The other command you mention works as well for me:

Debug.Assert(false);

The main challenge is to make sure the right dll version makes it into the MSI. If you don't see expected behavior try to manually insert the dll version (debug or release) that you intend to run with into the MSI using Orca or another MSI editor tool - just to make sure the right binary is in there. I don't know how this is set up in WixSharp.


Message Boxes: To show a message box from a C# custom action:

Add a project reference to the System.Windows.Forms namespace and system assembly (both a project reference and a using in code in other words):

using System.Windows.Forms;

<..>

[CustomAction]
public static ActionResult TestCustomAction(Session session)
{
   MessageBox.Show("Hello from TestCustomAction");
   return ActionResult.Success;
}

Beyond using a .NET message box, you can also use MSI's built-in Win32 dialogs via the: Session.Message call to show a dialog. This is probably better for end user dialogs. I would use the above approach for debugging only.


For Reference: Debugging Custom Actions

C++ debugging:

Managed Code (in addition to above):


Some Links (for safekeeping):

Chiffchaff answered 18/10, 2018 at 18:4 Comment(1)
Thanks for your help i will look at your suggestions and reply once I have found a solution.Clavius

© 2022 - 2024 — McMap. All rights reserved.