I'm using a dll to install a driver that's packaged inside the msi. When I schedule the custom-action for after InstallFinalize it succeeds, but if I schedule it either 1) after InstallFiles 2) after InstallFiles, execute=deferred, 3) after InstallFiles, execute=deferred, impersonate=no, or 4) before InstallFinalize it fails with "file not found" for the .inf file.
I've read This SO post and this page, but still don't understand how I get my driver to be installed.
If I use after InstallFinalize then if for some other reason an error is returned it's too late to abort the installation and it's botched.
According to this answer to the question you linked, you should schedule it after InstallFiles and make it deferred.
Enable verbose logging during your installation, and you'll be able to see when files are copied to the hard drive and when your custom action is called.
After InstallFinalized, your installation is already complete.
Related
When I run my WiX MSI installer it takes too long to get executed, when I checked the log, I found that the MSI create a Windows RestorePoint,
Question is : how to disable this, at least on testing environment, because it waste much time when testing.
MSIFASTINSTALL: You can use the MSIFASTINSTALL property. You can set it in the property table or via command line:
msiexec.exe /i MySetup.msi MSIFASTINSTALL=1
Other values you can try are 3 (no restore point and simple costing) and 7 (no restore point, simple costing and fewer progress messages).
See this previous answer as well: How can I speed up MSI package install and uninstall?
I have a Type 2 Custom Action which is executing an executable file with parameters.
I need to execute this CA before InstallWelcome dialog because it is used to collect some information to pre populate a dialog later.
So I sequenced this CA after CostFinalize action in the InstallUISequence but the installer fails to execute it with an error like below.
If I move the CA in the InstallExecuteSequence sequence it is executed as expected. (As explained in a later comment this is not true, it fails also in this sequence).
Does anyone have any idea what might happened?
Maybe useful information: If same executable is used in a Type 18 Custom Action (the executable is installed with the application's binaries) it is executed without problem.
<CustomAction Id='RunEXE' BinaryKey='EditCfg.exe.CA.ID' ExeCommand='[INSTALLFOLDER][SEPARATOR][CONFIG_FILE_NETWORK_LOCATION][SEPARATOR][USER_NAME][SEPARATOR][PASSWORD][SEPARATOR][WIX_UPGRADE_DETECTED][SEPARATOR][CHECKED_RULE][SEPARATOR][CERTIFICATE_LOCATION]' Execute='immediate' Impersonate='no' Return='check' />
<Binary Id='EditCfg.exe.CA.ID' SourceFile='path_to_the_exe_file'/>
MSI (c) (14:04) [15:18:36:452]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1722
Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action RunEXE, location: C:\Users\yyyyy\AppData\Local\Temp\MSIC8A9.tmp, command: param1§param2§param3§§param5§§param7
The 1722 error indicates that the exe returned a non-zero exit code. If this is expected, you can alter the Return attribute to use ignore instead of check. But if it's not expected, you probably need to figure out what that return code indicates, as odds are high that it's some sort of failure.
Here are a couple things that might cause failures:
The exe file may have some dependencies. Putting just the exe in the binary table doesn't carry its dependencies with it, so attempts to load and run the exe may fail, even before it gets to the exe's main code, depending on the kind of dependency.
When executed as a file installed with the product, the file may not exist in the specified location as of the time the custom action executes. During installation, new files do not show up until a deferred/in-script action after InstallFiles (or regular scheduling after InstallExecute); during uninstallation they often disappear by RemoveFiles. Maintenance can be a combination of those. However, a missing exe would likely result in a 1721 error instead of a 1722 error.
Regardless, note that exe custom actions cannot communicate useful data back to the Windows Installer session, so it will be difficult to leverage any data it finds (or creates) in the UI without the help of additional DLL-based actions or system searches. If you also add a DLL-based action, you may find it more friendly to launch the exe from that action (or even fully incorporate what it does into the dll), as you can log better diagnostics than the generic ones you've seen here.
I have a WIX installer that acts as a content installer for users. It's supposed to install these files in a specific directory. Unfortunately when I run it I get the following error: "The system cannot open the device or specified file." This then gives me error code 2755 after canceling the install (retry does not work).
I've looked through other questions with similar issues, and it does not appear to be an encryption problem on temp, the install folder, or the MSI installer itself - these all appear fine. This also isn't a problem with the C:\Windows\Installer folder being read-only.
I've never had a problem with a WIX installer before. What other things can I try to get this working?
For me the problem solved when the installer run as administrator.
I was seeing all of the following errors when installing my 3.5 GB .msi generated by WiX:
DEBUG: Error 2709: The specified Component name ('cmpF7216C180B7A7119CC61FDB3BD209D5D') not found in Component Table.
DEBUG: Error 2755: Server returned unexpected error 110 attempting to install package D:\...\setup.msi.
The system cannot open the device or specified file
Turning off EmbedCab made them all go away:
<Wix>...
<Product>...
<MediaTemplate EmbedCab="no" />
I unfortunately now have 30 cab files to deal with, but at least the install succeeds.
I created an installer project for Win XP using VS 2013.
While trying to install it, I got an error:
"DIRCA_CheckFX. Return value 3."
I visited this article in StackOverFlow: DIRCA_CHECKFX Return Value 3 - VS 2013 Deployment Project.
I did the Suggestion that I read there - to replace the "dpca.dll" - and it works great !
But only at machines that I didn't install the bad msi before.
While trying to install the new version of msi on a machine that has the bad version, I got an error that this program is already installed.
But while trying to uninstall the program - I got the error of : "DIRCA_CheckFX. Return value 3."
My question Is - How to Unistall the bad Version Of my installer and prevent this error?
thanks.
The root cause of this is the perhaps silly choice to do a check for the .NET Runtime when uninstalling the product. I suppose it's possible that someone uninstalled the .NET FW and that you are running uninstall custom actions that require it, and maybe that happened to you, but it seems unnecessary to me IMO.
If I were to have this problem, there are two solutions:
If you have that exact same MSI file, same version, ProductCode, identical in every way, then open it with Orca and go to the InstallExecuteSequence table. Go to the DIRCA_CheckFX call and set a condition of False, save the MSI file. Then install that MSI file with a command line msiexec /i [path to new MSI] REINSTALL=ALL REINSTALLMODE=vomus and this will do an update in place of the installed product, including the call to DIRCA_CheckFX that is now suppressed. Uninstall should work.
In the absence of the proper MSI file, troll through the Windows\installer folder looking at the cached MSI files. Hovering the mouse over each should get you to your cached MSI for the broken product. Again, edit with Orca as above to suppress the call on DIRCA_CheckFX.
I have made a change to a custom action in my msi file to not attempt to stop a windows service if the service is stopped or stop pending. However, after re-caching the msi using msiexec /fv mymsi.msi, when running the major upgrade to the next version (which also has the corrected service stopping custom action) the verbose logging is showing that the old custom action code is still being run even though the cached msi was updated. I even ran a binary comparison of the cached msi against the one that was used in the re-caching.
What am I doing wrong here.
If the old custom action is still running it means one of two things:
The new MSI logic is not correct and is still running the custom action.
The recache/reinstall did not work.
To re-cache/reinstall make sure your MSI is basically identical (same ProductCode/Upgradecode etc) to the old MSI except with the updated custom action. Then do:
msiexec /fv new.msi /l*v log.txt
That will overwrite the old MSI and do a repair using the new MSI (and give you a log file in case anything goes wrong).
In my case it was a cached copy of my MSI in %windir%\Installer and corresponding keys in the system registry (found them by GUID in HKLM and HKCR).