I'm trying to close a process before uninstallation using Wix. I've confirmed that it works as long as there's a visible window, but if there isn't a visible window (which is the case most of the time with this app since it's a system tray app), the uninstaller just hangs, and eventually continues with the uninstallation, leaving the process running.
According to this forum post, it seems like Wix has had trouble closing minimized apps in the past, so I wonder if this is related?
Any suggestions as to what else I can do to make sure the process gets shut down? Is there any way I can try and capture the message in my app using the Win32 api maybe?
Here's the CloseApplication declaration:
<util:CloseApplication Id="CloseApp" CloseMessage="yes" Target="App.exe" RebootPrompt="yes" />
And here's the custom action:
<Custom Before="InstallInitialize" Action="WixCloseApplications">REMOVE = "ALL"</Custom>
It looks like you are scheduling the WixCloseApplications custom action before the installation transaction. The way the custom action works, is it scheduled a deferred action that actually closes the applications. It can't do that work unless it happens during the transaction (After="InstallInitialize").
The fix is probably pretty easy. Remove the Custom/#Action="WixCloseApplications" element.
At first, don't forget to reference WixUtilExtension.dll assembly.
Also check if Wix element contains definition of UtilExtension namespace:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
I've noticed that you should change your custom action to be executed before InstallInitialize.
<Custom Before="InstallInitialize" Action="WixCloseApplications">REMOVE = "ALL"</Custom>
If you apply those changes and CloseApplications extension doesn't work, try logging installation process using
msiexec /i MyApplication.msi /l*v MyLogFile.txt
I also faced this problem.
Changing the Before attribute to "InstallValidate" worked for me.
<Custom Before="InstallValidate" Action="WixCloseApplications"/>
Related
I have a simple Wix project and I want to add the custom action that will run no matter what the result of the install is - success, error, cancel etc.
I've tried CustomAction with Execute="rollback" - it doesn't seem working.
In order to check if my custom actions are called on error I've added this custom action to generate an error (it returns ERROR_INSTALL_FAILURE from the DLL):
<CustomAction Id="TestBad" BinaryKey="testDll" DllEntry="TestBad" HideTarget="yes" Impersonate="no" Execute="immediate" Return="check"/>
and didn't find even one way to call the custom action on error.
Is there any way to do this?
EDIT
I've forgot to mention that I need it to run at the end of install process - I want to know the result of the installation process.
My first question is about the error below :
Module [Path/Name of dll].dll failed to register. HRESULT -2147024769. Contact your support personnel.
I can continue the installation but i want to get rid of this error if possible.
The second question is about the following error :
Error 1001. Exception occured when initializing the installation.
System.IO.FileNotFoundException: could not load file or assembly 'file:///C:\Windows\SysWOW64\files' or one of it's dependencies. The system cannot find the file specified.
I saw in different site and thread that the cause was the custom Action (in the value : /target=”[TARGETDIR]” -> /target=”[TARGETDIR]\”) but I can't found where is the error in my custom action. Here are the custom action realized using Designer for Wix Toolset :
<CustomAction Id="DIRCA_TARGETDIR" Property="TARGETDIR" Value="[ProgramFilesFolder][Manufacturer]\[ProductName]" Execute="firstSequence" />
<CustomAction Id="_FB3FF635_EF79_4863_91BD_70A0A11955B2.Uninstall" Execute="deferred" BinaryKey="InstallUtil" DllEntry="ManagedInstall" adx:VSName="Primary Output from Project" />
<CustomAction Id="_FB3FF635_EF79_4863_91BD_70A0A11955B2.Uninstall.SetProperty" Property="_FB3FF635_EF79_4863_91BD_70A0A11955B2.Uninstall" Value="/installtype=notransaction /action=uninstall /LogFile= /targ="[TARGETDIR]\" /usr=[ALLUSERS] /usr2=[MSIINSTALLPERUSER] /CommonProjAppData="[PROJCOMMONDATA]\" "[#_F521D169_ECD0_42B5_87F7_C2D8B6F9CA54]" "[VSDFxConfigFile]"" adx:VSName="Primary Output from Project" />
<CustomAction Id="_BE73DAD9_3524_4376_B45C_148B5871465B.Install" Execute="deferred" BinaryKey="InstallUtil" DllEntry="ManagedInstall" adx:VSName="Primary Output from Project" />
<CustomAction Id="_BE73DAD9_3524_4376_B45C_148B5871465B.Install.SetProperty" Property="_BE73DAD9_3524_4376_B45C_148B5871465B.Install" Value="/installtype=notransaction /action=install /LogFile= /targ="[TARGETDIR]\" /usr=[ALLUSERS] /usr2=[MSIINSTALLPERUSER] /CommonProjAppData="[PROJCOMMONDATA]\" "[#_F521D169_ECD0_42B5_87F7_C2D8B6F9CA54]" "[VSDFxConfigFile]"" adx:VSName="Primary Output from Project" />
<CustomAction Id="CA_CreateConfig" BinaryKey="ADXDPCADLL" DllEntry="GetConfig" />
Thanks for helping.
You're basically going in the wrong direction. You've converted a Visual Studio setup to WiX but you're trying to carry that VS custom action framework into WiX. The VS framework that calls managed code custom actions involves calling a C++ binary that then tries to load a NET runtime then use reflection to get into your assembly, instantiate classes and call methods. Apart from the fact that the InstallUtil Dll is transparent, undocumented and architecture dependent (you need either the 64-bit version or the 32-bit version) and therefore impossible to debug in cases like this, nobody actually bothers to propagate all this stuff into the WiX world because there are much better alternatives. For example if you're using installer classes to install services you don't need them at all. See ServiceInstall and ServiceControl. For generic custom action calls into managed code use the DTF managed code custom action framework.
I'm using wix installer (version 3), I have an msi of version 1.99 and another msi of version 2.00. My app has the ability to do import and export of the DB by calling it with some arguments. I'm trying to perform a major upgrade, and trying to call custom actions before and after the upgrade.
Now, the custom action code works just fine. The problem is, that the code that should run BEFORE the old version is removed, is running AFTER it is removed, and thus cannot activate the app and produce the backup files.
In short: How do I time the custom actions to do their work before the removal of the old version?
This is how I call them:
<CustomAction Id="doExport"
Return="check"
Execute="immediate"
BinaryKey="ImportExportBinary"
DllEntry="BeforeInstall" />
<CustomAction Id="doImport"
Return="check"
Execute="immediate"
BinaryKey="ImportExportBinary"
DllEntry="AfterInstall" />
<InstallExecuteSequence>
<Custom Action="doExport" Before="InstallInitialize"> NOT Installed</Custom>
<Custom Action="doImport" After="InstallFinalize"> NOT Installed</Custom>
</InstallExecuteSequence>
EDIT:
Here is the major upgrade code:
<MajorUpgrade AllowDowngrades="no"
Schedule="afterInstallFinalize"
DowngradeErrorMessage='Cannot downgrade!'
AllowSameVersionUpgrades='yes' ></MajorUpgrade>
I've tried playing a bit with "Execute" attribute of the CustomAction element, without any results.
First, do your upgrade creating a verbose log to make sure your custom actions are working and being called. You've marked them immediate, so they run before anything changes on the system and so will be called before the old product is removed. When you say "the code works just fine" you probably mean when you run it from your interactive account. But that's not happening. Your code is running out of an msiexec.exe process, the working directory is not what you expect, your code may not be looking in the right place for the files, it will not be elevated and so may not be able to do what it thinks it can. There are many opportunities for your code to not work as expected.
If you ever marked them as deferred I can see why doExport might not work. Without seeing your MajorUpgrade element I can't be sure, but the default scheduling for RemoveExistingProducts is afterInstallValidate. Your custom action is before InstallInitialize, so the actual sequence in the MSI file could easily be InstallValidate, RemoveExistingProducts, doExport, InstallInitialize.
and RemoveExistingProducts that does the uninstall of the old version is before your custom actions.
So if you want to use execute deferred, try Before="RemoveExistingProducts" on your doExport, or use Schedule in your MajorUpgrade to afterInstallInitialize and keep your doExport before InstallInitialize.
I tryied the same thing, and it took me long to find a way for it to work.
You can use
<Custom Action="doExport" Before="RemoveExistingProducts"></Custom>
The option RemoveExistingProducts refers to the action of uninstalling the existing version of your product, so you have to execute the action before the existing version is removed.
I did not find this option in this list: https://learn.microsoft.com/en-us/windows/win32/msi/suggested-installexecutesequence
But it seems to work, and executes before the list of options described in the link.
About the options which should go inside the <Custom></Custom> tag, I am not sure, but I hope it helps to start the code at the right moment.
I'm in a kind of misery. I got an installer installing and starting a tray icon app (common .exe)
This is working properly, but now i want to stop that app before this UI telling the user to close the app manually comes up, because during the deinstall routine, my tray icon is removed but the process is still running.
I applied this custom action to close the app before uninstall (or even during)
<CustomAction Id="CloseTrayApp" ExeCommand="-exit" FileKey="TrayApp" Execute="immediate" Return="asyncNoWait" />
<InstallExecuteSequence>
<Custom Action="CloseTrayApp" Before="InstallValidate" />
</InstallExecuteSequence>
But the "close all running apps" dialog still pops up, but i thought that this will solve my issue.
I already tried to use the CloseAction but i got into a hurry using it because of error while compiling the stuff. It says that the WixUtils namespace may be missing but i double checked that it is there:
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"
How can I avoid the dialog window poping up and trigger this custom action to be executed?
You also have to add a reference to WixUtilExtension.dll. If you are using Visual Studio / Votive you just right click add reference and select the DLL from [ProgramFilesFolder]Windows Installer XML v3.5\bin. Otherwise you have to make the extension available to the compiler and linker:
candle.exe yourfile.wxs -ext %full path to WixUtilExtension.dll%'
light.exe yourfile.wixobj -ext %full path to WixUtilExtension.dll% –out yourfile.msi yourfile.wixout'
More information can be found at:
Using Standard Custom Actions
Please note that the CloseApp custom action has a limitation that it won't "terminate" your application. It will only politely send your app a WM_CLOSE message and it's up to your trayapp to receive and process that message with a shutdown.
I've got a custom action I've defined for my installer. The installer doesn't seem to be running.
Here's the lines in the WXS file that define the custom action:
<CustomAction Id="GetConfigProperties" BinaryKey="GetPropertiesDLL" DllEntry="GetPropertiesFromConfigFile" />
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallInitialize" />
<Custom Action="NewerVersionDetected" After="FindRelatedProducts">NEWERVERSIONDETECTED</Custom>
<Custom Action="GetConfigProperties" After="FindRelatedProducts"></Custom>
. . .
</InstallExecuteSequence>
<Binary Id="GetPropertiesDLL" SourceFile="$(var.LPRCore Installer CBP Helper.TargetDir)\LPRCore Installer CBP Helper.CA.dll" />
I've checked the MSI with Orca and the appropriate entries are in the MSI's tables.
Here's an excerpt of the code in the CustomActions.cs file:
[CustomAction]
public static ActionResult GetPropertiesFromConfigFile(Session session) {
// Output a start message to the install log
session.Log( "Begin GetPropertiesFromConfigFile" );
. . .
return ActionResult.Success;
}
There are a few other session.Log statements in the code at places where I wanted to see what was going on.
Now, I have logging enabled. When I look at the log file in Notepad, I see no messages from my calls to session.Log. I see no references to GetConfigProperties either. It appears that the custom action is not executing at all. What have I done wrong?
It turns out that the custom action wasn't running because:
It was scheduled to run in the wrong place. My fault, I needed to put it in the InstallUISequence section, not the InstallSequence section.
I was aborting the install before the action could run.
When I put the custom action into the InstallUISequence section and in the right place, everything ran fine.
Thanks for trying.
Tony
In case you don't see any entries of GetConfigProperties custom action in your log file, most likely the reason is that InstallExecutesequence element resides in a separate Fragment, which is not included into the package. To include the contents of the Fragment into the package, you should reference any element in it from inside the Product element.
For instance, you can add the following line to the Product element:
<CustomActionRef Id="GetConfigProperties" />
I think you are missing condition on which custom action should run. Either give some condition <Custom Action="GetConfigProperties" After="FindRelatedProducts">NOT INSTALLED AND NOT REMOVE</Custom> or if you want to make it default then put 1 as condition
<Custom Action="GetConfigProperties" After="FindRelatedProducts">1</Custom>