Schroedingers Cat
Schroedingers Cat

Reputation: 3129

Wix Custom action - debugging

I am trying hard to debug a custom action in a wix installation. The action itself starts like this:

    [CustomAction]
    public static ActionResult CheckFiles(Session session)
    {
        Log("starting");
        var db = session.Database;
        try
        {
            var data = new CustomActionData();
            var present = db.OpenView("SELECT 'Id' FROM CivicaDBTable");
...

The "log" call is an attempt to write a message to a log file (using File.WriteAllText). I have also tried every other method I can find - messageboxing, attaching to the process and putting break points in, trying to force a debug connection - none of which seem to do anything.

However, I do know that the action is running - the log shows this:

MSI (s) (64:68) [11:30:59:511]: Doing action: CheckFiles
MSI (s) (64:68) [11:30:59:512]: Note: 1: 2205 2:  3: ActionText 
Action 11:30:59: CheckFiles. 
Action start 11:30:59: CheckFiles.
MSI (s) (64:CC) [11:30:59:527]: Invoking remote custom action. DLL:     C:\Windows\Installer\MSI9F06.tmp, Entrypoint: CheckFiles
MSI (s) (64:3C) [11:30:59:528]: Generating random cookie.
MSI (s) (64:3C) [11:30:59:529]: Created Custom Action Server with PID 13880 (0x3638).
MSI (s) (64:E8) [11:30:59:546]: Running as a service.
MSI (s) (64:E8) [11:30:59:547]: Hello, I'm your 32bit Impersonated custom action server.
SFXCA: Extracting custom action to temporary directory: C:\Users\STEVE~1.CLO\AppData\Local\Temp\MSI9F06.tmp-\
SFXCA: Binding to CLR version v4.0.30319
Calling custom action SQL Processing!SQL_Processing.CustomActions.CheckFiles
Action ended 11:30:59: CheckFiles. Return value 1.

So the evidence is that the action is called, and the install succeeds, but I am not seeming to get any information out of it. I Need to have some form of insight into what it is doing to process any further - Once I am certain that the Action processing is giving me what I need, I can code and test the rest of the processing. But I need this part to work in this environment.

Upvotes: 1

Views: 2396

Answers (3)

Sunil Agarwal
Sunil Agarwal

Reputation: 4277

2 options

First, to debug the code, add Debugger.Break() in method. Compile in Debug mode and start installation. When the method will be called, Visual studio will prompt to debug. You can then easily debug where its failing.

Second, install using msiexec with log enabled (/l*v). Then use WILogUtl (Tool is part of Windows SDK) to read the log file and check the issue)

Upvotes: 0

Hille
Hille

Reputation: 4196

Not knowing the exact circumstances any more, I recall that when I failed to debug / log a custom action just writing the log message to a dummy property helped. Property changes are visible in the msi log, so write s.th. like

session["LOG_PROP"] = "CA beg ...";
// ...
session["LOG_PROP"] = "CA end ...";

and call msiexec with verbose logging turned on, e.g.

msiexec /i product.msi /lv log.txt

Upvotes: 1

PhilDW
PhilDW

Reputation: 20780

Use Session.log - that will write your debug information to the MSI log file, that should help trace what's going on. Plain message box calls out of user code tend not to work if the CA is running with the system account (is it deferred?) because of shatter attacks. Writes to text files can fail for similar reasons (because, for example, you're writing to a user profile location that the system account doesn't have).

Upvotes: 1

Related Questions