Windows Installer Deferred execution - how can we log the custom actions running in deferred mode?
Asked Answered
A

2

1

In my MSI , I have added 2 custom actions to execute in deferred. I cant see these 2 custom actions in the verbose log to see whether these have executed or not. I can see for all other standard and custom actions executed in immediate mode, but not for deferred. Is this expected behavior ? Please help

Algernon answered 20/8, 2019 at 11:1 Comment(4)
Make sure you use the most verbose form of logging, which is: MSIEXEC /i xxxx.msi /L*V C:\temp\yourlog.log etc etc....Outcrop
I have used same , but I couldn't find deferred custom actions executed or not.Algernon
Please let us know what tool you use to build the MSI, and what language you use for your custom action? Is it VBScript? If it is VBScript please see the link to the PDF below in my answer and read the section on VBScript (direct link to article). If it still doesn't work, maybe you can put sources on github.com for a quick look? I think I have an answer that shows basic WiX markup for a VBScript custom action, I will dig it up shortly.Speech
I messed up the first answer, too many links and details. Please see new answer with link to a sample project on github.comSpeech
P
1

WiX & VBScript: Here are some answers showing how you can use VBScript custom actions in MSI properly - combine that with the logging approach shown below and you should find all information in your log that you write there:


UPDATE: Most likely your setup has aborted before the custom action was invoked? Or your custom action crashed and returned no error? Normally you will see entries in the log along the lines of:

"Invoking remote custom action"
"Created Custom Action Server with PID DECVAL (0xHEXVAL)."
"Hello, I'm your 32bit Impersonated custom action server."

Etc... Very cosy that last variant. "Howdy doody 32bit server".


Comprehensive Logging: Please enable verbose logging with extra debugging information and use buffer-less log writing. The latter is to avoid lost buffer when custom actions crash. The log file is written directly instead of in batches and this slows down installation dramatically. I would recommended this logging variant for your case:

msiexec.exe /i C:\Path\Your.msi /L*vx! C:\Your.log

Tip: Search for "value 3" in the log file to find errors as explained by Rob Mensching (Wix & Orca author).


MSI Logging: Some more information about msiexec.exe logging in general:

WiX MSI Logging: When you use WiX's Visual Studio integration, you can create a new Custom Action project and you can use the built in logging they provide from within the custom action:

[CustomAction]
public static ActionResult CustomAction1(Session session)
{
   session.Log("Begin CustomAction1");

   return ActionResult.Success;
}

C++: The above is for a managed code C# custom action, there is a template (at least there used to be) for C++ as well. I much prefer the latter for minimal dependencies.


Custom Action Logging: Your custom action can write to the log file as follows: MSI Tip: Writing to the Log File from a Custom Action. This is done via custom action code - you might do this already?


Links:

Pevzner answered 20/8, 2019 at 12:4 Comment(3)
Hi Stein.. thanks for sharing your views. Please find my comments: Stein : Most likely your setup has aborted before the custom action was invoked? Sandy: No Stein : your custom action crashed and returned no error? Sandy: No. MSI Installed successfully and deferred custom action was executing without any issues (I have put vbscript msgbox which worked well)Algernon
Hi Sandy. Did you see the PDF I link to above with the logging approach from within the custom action code? Are you using managed code custom action with the logging available in the WiX template projects? I am not sure what tool you are using to make the MSI.Speech
That VBScript could be a test custom action, or do you use only VBScript? There are cases when VBScripts crash and then the MSI just continues, giving the appearance that the custom action ran but it didn't. It is also possible to save the VBScript in the wrong encoding so it doesn't run. Try saving the script file in ANSI encoding (essentially ASCII with code pages - avoid weird characters still I'd say).Speech
P
0

Github.com: Adding a new answer since the old one got messy. There is a sample project here that you can try: https://github.com/glytzhkof/all. VBScriptWriteToLog in either zip or file form (same files). This project will show a sample of how to log directly to the MSI log file from VBScript.

Snippets: Here are some extracted, key markup:

<Binary Id='CA.vbs' SourceFile='CA.vbs' />
<CustomAction Id='CA.vbs' VBScriptCall='' BinaryKey='CA.vbs' Execute='immediate' Return='ignore' />

<InstallExecuteSequence>
  <Custom Action='CA.vbs' After='InstallInitialize'>NOT Installed AND NOT REMOVE~="ALL"</Custom>
</InstallExecuteSequence>
  • Deferred / Immediate: Just change Execute='immediate' to Execute='deferred' to run deferred rather than immediate.
  • ANSI Encoding: Make sure the VBScript file is saved with ANSI text encoding.
  • Condition: That MSI condition for the custom action sequencing should make it run on fresh install and not on uninstall (or major upgrade). It is sort of a normal "relic" that I left in there.

Testing: After installation search the MSI log file for "Calling LoggingTestVBS...". If it is not there, chances are you have the wrong log file. Please see below for simplest logging command.

Express Logging: Simplest possible logging from cmd.exe.

msiexec.exe /i C:\Path\Your.msi /L*v C:\Your.log
Pevzner answered 21/8, 2019 at 13:36 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.