Wix Toolset - Identical MSI not reinstalling - wix

I am creating an msi installer with a basic directory installation and a single post-install custom action. The installer should support reinstall on all version ranges (newer, older, same).
Almost everything is working fine, except for performing a reinstall of an identical msi. When performing an msiexec of the same msi as is currently installed (but possibly other msiexec command line properties), the installer starts and exits but does not do anything and does not show an error in the logs.
Upgrades and downgrades are working fine (when specifying 'AllowDowngrades="yes"'). The reinstall also happens correctly when I build a new msi with the same version as currently installed. I also tried setting the AllowSameVersionUpgrades instead of the AllowDowngrades, but without luck.
Any hints on how my wxs should be configured to allow reinstall of the same msi file? Currently my MajorUpgrade looks like this:
<MajorUpgrade AllowDowngrades="no" AllowSameVersionUpgrades="yes" Disallow="no" DowngradeErrorMessage="Not allowed to downgrade." IgnoreRemoveFailure="yes" MigrateFeatures="yes" />
What I do see in the msiexec output as a difference between a normal reinstall and the same msi install failure; is the start of the installer mentioning 'FindRelatedProducts. Return Value0':
Action 14:12:52: INSTALL.
Action start 14:12:52: INSTALL.
Action 14:12:52: FindRelatedProducts. Searching for related applications
Action start 14:12:52: FindRelatedProducts.
Action ended 14:12:52: FindRelatedProducts. Return value 0.
Action 14:12:52: AppSearch. Searching for installed applications
Action start 14:12:52: AppSearch.
AppSearch: Property: NETFRAMEWORK45, Signature: NetFramework45
Action ended 14:12:52: AppSearch. Return value 1.
Action 14:12:52: LaunchConditions. Evaluating launch conditions
Action start 14:12:52: LaunchConditions.
Action ended 14:12:52: LaunchConditions. Return value 1.
Action 14:12:52: ValidateProductID.
Action start 14:12:52: ValidateProductID.
Action ended 14:12:52: ValidateProductID. Return value 1.
Action 14:12:52: CostInitialize. Computing space requirements
While a successful upgrade/downgrade msiexec log looks like this:
Action 18:27:21: INSTALL.
Action start 18:27:21: INSTALL.
Action 18:27:21: FindRelatedProducts. Searching for related applications
Action start 18:27:21: FindRelatedProducts.
FindRelatedProducts: Found application: {014FD491-292B-4BFC-BCFB-87121C11BCE9}
Action ended 18:27:21: FindRelatedProducts. Return value 1.
Action 18:27:21: AppSearch. Searching for installed applications
Action start 18:27:21: AppSearch.
AppSearch: Property: NETFRAMEWORK45, Signature: NetFramework45
Action ended 18:27:21: AppSearch. Return value 1.
Action 18:27:21: LaunchConditions. Evaluating launch conditions
Action start 18:27:21: LaunchConditions.
Action ended 18:27:21: LaunchConditions. Return value 1.
Action 18:27:21: ValidateProductID.
Action start 18:27:21: ValidateProductID.
Action ended 18:27:21: ValidateProductID. Return value 1.
I am rather new to Wix, so any hints on how to fix this or what I could try are very welcome.
Cheers.
Clarification: I do not want multiple instances of the same msi/program installed at once, however I would like to force a complete reinstall upon executing the same msi again, without manually performing an uninstall first. This to allow reconfiguration of the software through msiexec cli properties and a custom action.

The most likely cause of this is that you cannot install the same identical MSI more than once. The product is identified by its ProductCode, and if that product is already installed then there is no "install it again". The installed product will go into maintenance mode, and that is typically a repair (in the absence of the ability to add or remove features).
If you really want (say) 10 identical products installed side-by-side then they each need to be different products (as identified by ProductCode). There are the general issues of multiple identical entries in Programs&Features, possible multiple identical shortcuts, problems with objects that can be used only once (such as service names), and you may need to think about how to maintain multiple products on the same system regarding patching, upgrades and so on.
If your goal is to do an upgrade of the installed product (usually this means you have updated files) then you need a major upgrade, using the MajorUpgrade element. This will install the newer version and automatically uninstall the previous version. However it can only be the "same" MSI if your major upgrade specifies AllowSameVersionUpgrades=yes and you change the ProductCode and PackageCode, so there isn't really a way to reinstall the same MSI - it can have the same files and other content, but it needs new Product and Package code values with the major upgrade.

My issue got resolved through the comment from Daniel Lee - thanks for that!
The use of msiexec paramters / switches REINSTALL and REINSTALLMODE indeed allow a clean reinstall of the identical msi file, using REINSTALL=all and REINSTALLMODE=a .
REINSTALL
REINSTALL_MODE

Related

Is launch Condition shown in silent mode?

Using WixSharp to build installer,
Is LaunchCondition shown when running in silent mode? (e.g "msiexec /i /qn /quiet")
MSI GUI: MSI has many UILevels - degrees of visible GUI (more on this here). When a setup is run in silent mode, any errors from Launch Conditions will show up in the MSI log instead of a dialog.
This makes sense since you must avoid dialogs showing up when there might be nobody to dismiss them (for example in automatic package deployment systems).
Essentially you can run with basic GUI /qb or reduced GUI /qr or completely silently /qn. When you run silently no dialogs should be shown, and you should consult the log file for results:
Silent MSI installation:
msiexec /i MySetup.msi /qn /L test.log
Test Project: https://github.com/glytzhkof/WiXLaunchConditionTest (MYVALUE is defined in the Property table - change it there to 0 or 1).
Here is a sample log output:
=== Logging started: 28.10.2021 13:07:12 ===
Action start 13:07:12: INSTALL.
Action start 13:07:12: FindRelatedProducts.
Action ended 13:07:12: FindRelatedProducts. Return value 1.
Action start 13:07:12: LaunchConditions.
MSI (s) (F4:DC) [13:07:12:491]: Product: WiXLaunchConditionTest -- Value for MYFLAG must be 1 (true) or 0 (false)
Value for MYFLAG must be 1 (true) or 0 (false)
Action ended 13:07:12: LaunchConditions. Return value 3.
Action ended 13:07:12: INSTALL. Return value 3.
MSI (s) (F4:DC) [13:07:12:493]: Product: WiXLaunchConditionTest -- Installation failed.
MSI (s) (F4:DC) [13:07:12:493]: Windows Installer installerte produktet. Produktnavn: WiXLaunchConditionTest. Produktversjon: 1.0.0.0. Produktspråk: 1033. Produsent: -. Installasjonens resultatstatus: 1603.
=== Logging stopped: 28.10.2021 13:07:12 ===
Admin Rights: It should be noted that an MSI should be run from a cmd.exe with admin rights - or you get no message from the silent installer that the setup failed because of lacking admin rights (the failure is from lacking admin rights, not because of the launch conditions).
This registry script adds context menus in Windows Explorer which can open a cmd.exe in any folder with or without admin rights: https://github.com/glytzhkof/all/blob/master/HKCU_Run-CMD-Shell-Extension.reg. Just merge the registry file and then right click an empty space inside Windows Explorer in any folder. See the commands towards the bottom of the dialog:

WIX MSI: I Want to show a message to user "Product is already Installed" if user runs the installer again

I am creating an MSI installer, during testing the same if I am running the installer for the first time the installer works as expected. But when I accidentally run the installer, it uninstalled my files.
So, for that, I had modified the condition and added Remove="All" in the condition of the actions.
Which is working fine, but I want to show a message to the User that the product is already installed.
So, for that, I added the below piece of code:
<Upgrade Id='<<Upgrade Code>>'>
<UpgradeVersion OnlyDetect='yes' Property='SELFFOUND'
Minimum='1.0.1' IncludeMinimum='yes' Maximum='1.0.1' IncludeMaximum='yes' />
<UpgradeVersion OnlyDetect='yes' Property='NEWERFOUND'
Minimum='1.0.1' IncludeMinimum='no' />
</Upgrade>
<CustomAction Id='AlreadyUpdated' Error='[ProductName] is already installed.' />
.....
.....
.....
.....
.....
<InstallExecuteSequence>
<Custom Action='AlreadyUpdated' After='FindRelatedProducts'>SELFFOUND</Custom>
</InstallExecuteSequence>
But when running this, the installer is still running for the second time and not giving the message.
On checking the logs, could see that the "FindRelatedProducts" skipped with the below message:
MSI (c) (F4:1C) [06:18:04:806]: Doing action: FindRelatedProducts
MSI (c) (F4:1C) [06:18:04:806]: Note: 1: 2205 2: 3: ActionText
Action 6:18:04: FindRelatedProducts. Searching for related applications
Action start 6:18:04: FindRelatedProducts.
MSI (c) (F4:1C) [06:18:04:806]: Skipping FindRelatedProducts action: not run in maintenance mode
Action ended 6:18:04: FindRelatedProducts. Return value 0.
and
MSI (s) (18:14) [06:18:05:500]: Running ExecuteSequence
MSI (s) (18:14) [06:18:05:500]: Doing action: FindRelatedProducts
MSI (s) (18:14) [06:18:05:500]: Note: 1: 2205 2: 3: ActionText
Action 6:18:05: FindRelatedProducts. Searching for related applications
Action start 6:18:05: FindRelatedProducts.
MSI (s) (18:14) [06:18:05:507]: Skipping FindRelatedProducts action: already done on client side
Action ended 6:18:05: FindRelatedProducts. Return value 0.
The condition in AlreadyUpdated custom action also does not satisfy.
MSI (s) (18:14) [06:18:05:737]: Doing action: PublishProduct
MSI (s) (18:14) [06:18:05:737]: Note: 1: 2205 2: 3: ActionText
Action 6:18:05: PublishProduct. Publishing product information
Action start 6:18:05: PublishProduct.
PublishProduct:
MSI (s) (18:14) [06:18:05:752]: Re-publishing product - installing new package with existing product code.
Action ended 6:18:05: PublishProduct. Return value 1.
MSI (s) (18:14) [06:18:05:752]: Skipping action: AlreadyUpdated (condition is false)
Is there any way to achieve this requirement? Am I doing something wrong?
Custom Action Complexity: First a word on custom actions and their complexity. Please read the first paragraphs here:
Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?
Wrong Conditioning: This basically means your conditions are incorrect so the custom actions run in installation modes where they should not. There are many installation modes you should test in when you try to use complex conditions (or any condition for that matter): 1. fresh install, 2. repair, 3. modify, 4. self-repair, 5. patching, 6. uninstall, 7. major upgrade invoked uninstall, etc...
In your case some custom actions run on maintenance run as well as during fresh / first installation. This is a very common problem. The solution is either to eliminate the custom actions by improving the setup, or to improve conditions so they actually work in any installation mode. Obviously.
Condition Debugging: Conditions are hard to get right. I like to test them using message boxes. The bottom section here shows how you can do so: How to execute conditional custom action on install and modify only? - then you run the setup in different modes and look for the dialog boxes. When they show up the condition on the custom action is true.
Complex Conditions:
Here is an answer on why old custom actions are used for a new setup: Wix Tools update uses old custom actions.
There is also an answer listing some values for common properties in different installation modes: How to add a WiX custom action that happens only on uninstall (via MSI)?
Installshield has this PDF of common conditions (some of which are Installshield-specific): https://resources.flexera.com/web/pdf/archive/IS-CHS-Common-MSI-Conditions.pdf
Unexpected Behavior: A special note on the properties UPGRADINGPRODUCTCODE and WIX_UPGRADE_DETECTED. Please read this: Run Wix Custom action only during uninstall and not during Major upgrade - these quirks affect how many times a custom action runs during a major upgrade scenario. Some very surprising effects here for people. Use your message box debugging?
Links:
wix installer update process and confirmation dialog
Wix custom uninstallation action - how to run before msi removing files
Installing driver using cutomAction DriverPackageInstall in wix installer
WIX CustomAction conditions
Failed to get MSI property in UPGRADINGPRODUCTCODE, WIX_UPGRADE_DETECTED
Reboot on install, Don't reboot on uninstall

Windows Installer Error 1316. Installer looks for wrong filename

I'm trying to implement the following self-update mechanism for my application: If an update is available, my application downloads the (WiX generated) MSI package and writes it to its AppData folder with an arbitrary name. The application then initiates the update process by calling
msiexec /fvomus "<ArbitraryName>.msi" /qn /L "<ArbitraryName>.msi.log" REINSTALL=ALL REINSTALLMODE=vomus
With this I get an error 1316 and the installation then terminates with error status 1603.
The original filename of the MSI is CCWirelessServer.msi, but as I said before, my application writes the installer package with an arbitrary name, for example ba17b82d-0ab8-4fc9-aea8-62830042d49f.msi. Now what I noticed is that Windows Installer is for some reason looking for a CCWirelessServer.msi file and not for the correct temporary filename. You can see this in the log below.
Why is Windows Installer not using the filename I provided via command line? Is it a problem with my command line arguments or with the installer package?
Here is the log:
=== Logging started: 24.02.2014 09:16:30 ===
Action start 09:16:30: INSTALL.
Action start 09:16:30: FindRelatedProducts.
Action ended 09:16:30: FindRelatedProducts. Return value 0.
Action start 09:16:30: ValidateProductID.
Action ended 09:16:30: ValidateProductID. Return value 1.
Action start 09:16:30: CostInitialize.
Action ended 09:16:30: CostInitialize. Return value 1.
Action start 09:16:30: FileCost.
Action ended 09:16:30: FileCost. Return value 1.
Action start 09:16:30: CostFinalize.
Action ended 09:16:30: CostFinalize. Return value 1.
Action start 09:16:30: MigrateFeatureStates.
Action ended 09:16:30: MigrateFeatureStates. Return value 0.
Action start 09:16:30: InstallValidate.
Action ended 09:16:30: InstallValidate. Return value 1.
Action start 09:16:30: RemoveExistingProducts.
Action ended 09:16:30: RemoveExistingProducts. Return value 0.
Action start 09:16:30: InstallInitialize.
Action ended 09:16:30: InstallInitialize. Return value 1.
Action start 09:16:30: ProcessComponents.
Action ended 09:16:30: ProcessComponents. Return value 1.
Action start 09:16:30: UnpublishFeatures.
Action ended 09:16:30: UnpublishFeatures. Return value 1.
Action start 09:16:30: RemoveRegistryValues.
Action ended 09:16:30: RemoveRegistryValues. Return value 1.
Action start 09:16:30: RemoveShortcuts.
Action ended 09:16:30: RemoveShortcuts. Return value 1.
Action start 09:16:30: CAUninstallAsService.
Action ended 09:16:30: CAUninstallAsService. Return value 1.
Action start 09:16:30: RemoveFiles.
Action ended 09:16:30: RemoveFiles. Return value 1.
Action start 09:16:30: InstallFiles.
Action ended 09:16:30: InstallFiles. Return value 1.
Action start 09:16:30: CAInstallAsServiceRollback.
Action ended 09:16:30: CAInstallAsServiceRollback. Return value 1.
Action start 09:16:30: CAInstallAsService.
Action ended 09:16:30: CAInstallAsService. Return value 1.
Action start 09:16:30: CreateShortcuts.
Action ended 09:16:30: CreateShortcuts. Return value 1.
Action start 09:16:30: WriteRegistryValues.
Action ended 09:16:30: WriteRegistryValues. Return value 1.
Action start 09:16:30: RegisterUser.
Action ended 09:16:30: RegisterUser. Return value 0.
Action start 09:16:30: RegisterProduct.
MSI (s) (4C:50) [09:16:30:406]: Product: Wireless Server -- Error 1316. A network error occurred while attempting to read from the file: C:\ProgramData\MyCompanyName\Wireless Server\Updates\CCWirelessServer.msi
Error 1316. A network error occurred while attempting to read from the file: C:\ProgramData\MyCompanyName\Wireless Server\Updates\CCWirelessServer.msi
Action ended 09:16:30: RegisterProduct. Return value 3.
Action ended 09:16:30: INSTALL. Return value 3.
MSI (s) (4C:50) [09:16:30:419]: Windows Installer reconfigured the product. Product Name: Wireless Server. Product Version: 1.0.0.0. Product Language: 1033. Manufacturer: MyCompanyName. Reconfiguration success or error status: 1603.
=== Logging stopped: 24.02.2014 09:16:30 ===
Edit 1:
Just to verify that the problem is with the arbitrary filename I tried write the update package with the original filename of the installer, and it works!
Trying to change the filename of the MSI and performing a minor upgrade is not supported. See:
Windows Installer Best Practices
Keep package names and package codes consistent.
The .msi file can be given any name that helps users identify the
package, but the name should not be changed without also changing the
product code.
•Give your .msi file a user-friendly name that enables the user to
identify the contents of the Windows Installer package.
•The product code is the principal identification of an application
and must change whenever there is a comprehensive update to the
application. For information, see ProductCode and Changing the Product
Code. Changing the name of the application's .msi file is considered a
comprehensive change and always requires a corresponding change of the
product code to maintain consistency.
•The package code is the primary identifier used by the installer to
search for and validate the correct package for a given installation.
No two nonidentical .msi files should ever have the same package code.
If a package is changed without changing the package code, the
installer may not use the newer package if both are still accessible
to the installer. The package code is stored in the Revision Number
Summary Property of the Summary Information Stream.
•Note that letters in product code and package code GUIDs must all be
uppercase.
Changing the Product Code
The product code must be changed if any of the following are true for
the update:
•Coexisting installations of both original and updated products on the
same system must be possible.
•The name of the .msi file has been changed.
•The component code of an existing component has changed.
•A component is removed from an existing feature.
•An existing feature has been made into a child of an existing
feature.
•An existing child feature has been removed from its parent feature.
Why does changing the name of your MSI file require a Major Upgrade?

'Error -2147467259: failed to create SQL database' in WiX

I want to create a database in the installation process using WiX 3.6. I followed many tutorials, but I think there is something I am doing wrong.
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"
xmlns:sql="http://schemas.microsoft.com/wix/SqlExtension">
<Product Id="{A704CA9E-2833-4276-A8A8-148F1047332F}" Name="DbInstallerTest" Language="1033" Version="1.0.0.0" Manufacturer="Microsoft" UpgradeCode="2de42bd8-acc2-48bf-b3c6-09745d3a2ea4">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate />
<Feature Id="ProductFeature" Title="DbInstallerTest" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="DbInstallerTest" />
</Directory>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<Component Id="CMPDbInsatller"
Guid="{1749E57D-9CE4-42F8-924C-2A2E368B51E4}">
<CreateFolder Directory="INSTALLFOLDER"/>
<util:User Id="SqlUser"
Name="sa"
Password="Abc123#"/>
</Component>
<Component Id="cmp2"
Guid="{C3596364-61A0-4628-9153-1BA11DB4B778}">
<CreateFolder Directory="INSTALLFOLDER"/>
<sql:SqlDatabase Id="Id_db"
Database="TestDatabase1"
Server="(local)\SQLExpress"
CreateOnInstall="yes"
User="SqlUser"
DropOnUninstall="yes">
</sql:SqlDatabase>
</Component>
</ComponentGroup>
</Fragment>
</Wix>
The above code gives the following error.
Error -2147467259: failed to create SQL database: TestDatabase1. error detail: Unknown error.
Here is the log content,
=== Logging started: 2/18/2013 11:00:59 ===
Action 11:00:59: INSTALL.
Action start 11:00:59: INSTALL.
Action 11:00:59: FindRelatedProducts. Searching for related applications
Action start 11:00:59: FindRelatedProducts.
Action ended 11:00:59: FindRelatedProducts. Return value 1.
Action 11:00:59: LaunchConditions. Evaluating launch conditions
Action start 11:00:59: LaunchConditions.
Action ended 11:00:59: LaunchConditions. Return value 1.
Action 11:00:59: ValidateProductID.
Action start 11:00:59: ValidateProductID.
Action ended 11:00:59: ValidateProductID. Return value 1.
Action 11:00:59: CostInitialize. Computing space requirements
Action start 11:00:59: CostInitialize.
Action ended 11:00:59: CostInitialize. Return value 1.
Action 11:00:59: FileCost. Computing space requirements
Action start 11:00:59: FileCost.
Action ended 11:00:59: FileCost. Return value 1.
Action 11:00:59: CostFinalize. Computing space requirements
Action start 11:00:59: CostFinalize.
Action ended 11:00:59: CostFinalize. Return value 1.
Action 11:00:59: MigrateFeatureStates. Migrating feature states from related applications
Action start 11:00:59: MigrateFeatureStates.
Action ended 11:00:59: MigrateFeatureStates. Return value 0.
Action 11:00:59: ExecuteAction.
Action start 11:00:59: ExecuteAction.
Action start 11:01:01: INSTALL.
Action start 11:01:01: FindRelatedProducts.
Action ended 11:01:01: FindRelatedProducts. Return value 0.
Action start 11:01:01: LaunchConditions.
Action ended 11:01:01: LaunchConditions. Return value 1.
Action start 11:01:01: ValidateProductID.
Action ended 11:01:01: ValidateProductID. Return value 1.
Action start 11:01:01: CostInitialize.
Action ended 11:01:01: CostInitialize. Return value 1.
Action start 11:01:01: FileCost.
Action ended 11:01:01: FileCost. Return value 1.
Action start 11:01:01: CostFinalize.
Action ended 11:01:01: CostFinalize. Return value 1.
Action start 11:01:01: MigrateFeatureStates.
Action ended 11:01:01: MigrateFeatureStates. Return value 0.
Action start 11:01:01: InstallValidate.
Action ended 11:01:01: InstallValidate. Return value 1.
Action start 11:01:01: RemoveExistingProducts.
Action ended 11:01:01: RemoveExistingProducts. Return value 1.
Action start 11:01:01: InstallInitialize.
Action ended 11:01:01: InstallInitialize. Return value 1.
Action start 11:01:01: ProcessComponents.
Action ended 11:01:01: ProcessComponents. Return value 1.
Action start 11:01:01: UnpublishFeatures.
Action ended 11:01:01: UnpublishFeatures. Return value 1.
Action start 11:01:01: UninstallSqlData.
Action ended 11:01:02: UninstallSqlData. Return value 1.
Action start 11:01:02: RemoveFiles.
Action ended 11:01:02: RemoveFiles. Return value 0.
Action start 11:01:02: RemoveFolders.
Action ended 11:01:02: RemoveFolders. Return value 1.
Action start 11:01:02: CreateFolders.
Action ended 11:01:02: CreateFolders. Return value 1.
Action start 11:01:02: ConfigureUsers.
Action start 11:01:02: CreateUserRollback.
Action ended 11:01:02: CreateUserRollback. Return value 1.
Action start 11:01:02: CreateUser.
Action ended 11:01:02: CreateUser. Return value 1.
Action ended 11:01:02: ConfigureUsers. Return value 1.
Action start 11:01:02: InstallFiles.
Action ended 11:01:02: InstallFiles. Return value 1.
Action start 11:01:02: InstallSqlData.
Action start 11:01:19: CreateDatabase.
Action ended 11:01:19: CreateDatabase. Return value 1.
Action ended 11:01:19: InstallSqlData. Return value 1.
Action start 11:01:19: RegisterUser.
Action ended 11:01:19: RegisterUser. Return value 1.
Action start 11:01:19: RegisterProduct.
Action ended 11:01:19: RegisterProduct. Return value 1.
Action start 11:01:19: PublishFeatures.
Action ended 11:01:19: PublishFeatures. Return value 1.
Action start 11:01:19: PublishProduct.
Action ended 11:01:19: PublishProduct. Return value 1.
Action start 11:01:19: InstallFinalize.
CreateDatabase: Error 0x80004005: failed to create to database: 'TestDatabase1', error:
unknown error
Error 26201. Error -2147467259: failed to create SQL database: TestDatabase1, error detail:
unknown error.
MSI (s) (94!44) [11:01:47:973]: Product: DbInstallerTest -- Error 26201. Error -2147467259:
failed to create SQL database: TestDatabase1, error detail: unknown error.
CustomAction CreateDatabase returned actual error code 1603 (note this may not be 100%
accurate if translation happened inside sandbox)
Action ended 11:01:47: InstallFinalize. Return value 3.
Action ended 11:01:48: INSTALL. Return value 3.
Action ended 11:01:48: ExecuteAction. Return value 3.
Action ended 11:01:48: INSTALL. Return value 3.
=== Logging stopped: 2/18/2013 11:01:48 ===
MSI (c) (C0:94) [11:01:48:208]: Product: DbInstallerTest -- Installation failed.
MSI (c) (C0:94) [11:01:48:209]: Windows Installer installed the product. Product Name:
DbInstallerTest. Product Version: 1.0.0.0. Product Language: 1033. Manufacturer: Microsoft.
Installation success or error status: 1603.
What am I doing wrong here?
We chased this error around for a week before finally resolving it by going into the SQL Server Configuration Manager → SQL Server Network Configuration → Protocols for MSSQLSERVER (for us, the default instance) → Enabling Named Pipes and TCP/IP protocols.
I was also facing this exact issue, and I browsed a lot of forums to get that solved. This was the only thing which worked for me. On my computer, SQL Server Express Edition database creation failed with
-2147467259: failed to create SQL database:
After days of hacking I finally found the solution! All you need to do
is use .\sqlexpress instead of localhost\sqlexpress or
127.0.0.1\sqlexpress in your connection string. I think (and I might be terribly wrong here) when you use .\sqlexpress in connection string
installer uses Shared Memory instead of Named Pipes or TCP/IP.
Source: Solution to -2147467259: failed to create SQL database
Err 26201 is more useful. You should also see more information in the event logs.
Your code indicates that you are using mixed mode on the SQL instance and authenticating as a SQL login. This indicates that the problem is likely that your SQL service account doesn't have permissions to create the MDF and LDF files in the default locations.
See this thread for more info:
Error 26201. Error -2147467259: failed to create SQL database
So I am also getting an error in my WiX installer logs also, however slightly different.
Environment:
WebServer = Windows 2008 R2
SQLServer = Windows 2008 32-bit with SQL Server 2008 R2 Standard
Mixed Mode Authentication
Default SQL Instance
Error:
ExecuteSqlStrings: Entering ExecuteSqlStrings in
C:\Windows\Installer\MSI1EC7.tmp, version 3.6.3303.0
ExecuteSqlStrings: Error 0x80004005: failed to connect to database:
'DatabaseNameBla'
Error 26203. Failed to connect to SQL database.
(-2147467259 DatabaseNameBla ) MSI (s) (20!30) [10:16:32:225]:
Product: Bla Services -- Error 26203. Failed to connect to SQL
database. (-2147467259 DatabaseNameBla )
Research:
Instance DB seems to have only 1.6 GB left on the hard drive. << this might be bad...
My user is sysadmin
Access Through SQL Management Tools has no problems with the same user.
SLQ Logs have nothing in them to assist with the error. Just noise.
My Solution:
VM has a D drive with 50 GB free
New Database Instance on D Drive
New Instance Set to Mixed Mode
Reinstalled. Success!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Summary:
So after hours of trying to figure out what the deal was. In the instance of this error, it was related to the hard drive free space size. Since the SQL Server was in production we were unable to expand the C drive to see if that fixed the default instance.

WiX Action Sequence

I was looking for list of actions and their sequence when running a WiX setup. Somehow the official website doesn't seem to provide any information.
The basic problem is that I want to schedule my custom actions correctly. Typically I need to register a DLL with regsvr32.exe, and this can only be done once the files are copied to the harddrive. However the custom action
<Custom Action="RegisterShellExt" After="InstallFiles">
failed with the error message "file not found".
What I've done then is analizing the log of my MSI with WiX Edit, and I've found that the Action InstallFiles exists more than once. And effectively the files are written only the second time it appears. So I changed my custom action to the following :
<Custom Action="RegisterShellExt" Before="InstallFinalize">
Here is the sequence I've extracted from the logs of my MSI:
Action start 15:16:49: INSTALL.
Action start 15:16:49: PrepareDlg.
Action start 15:16:49: AppSearch.
Action start 15:16:49: LaunchConditions.
Action start 15:16:49: ValidateProductID.
Action start 15:16:49: DIRCA_NEWRETARGETABLEPROPERTY1.5D429292039C46FCA3253E37B4DA262A.
Action start 15:16:50: CostInitialize.
Action start 15:16:50: FileCost.
Action start 15:16:50: CostFinalize.
Action start 15:16:50: WelcomeDlg.
Action 15:16:51: LicenseAgreementDlg. Dialog created
Action 15:16:53: CustomizeDlg. Dialog created
Action 15:16:55: VerifyReadyDlg. Dialog created
Action start 15:16:56: ProgressDlg.
Action start 15:16:56: ExecuteAction.
Action start 15:16:58: INSTALL.
Action start 15:16:58: AppSearch.
Action start 15:16:58: LaunchConditions.
Action start 15:16:58: ValidateProductID.
Action start 15:16:58: CostInitialize.
Action start 15:16:59: FileCost.
Action start 15:16:59: CostFinalize.
Action start 15:16:59: InstallValidate.
Action start 15:17:00: InstallInitialize.
Action start 15:17:08: ProcessComponents.
Action 15:17:09: GenerateScript. Generating script operations for action:
Action ended 15:17:09: ProcessComponents. Return value 1.
Action start 15:17:09: UnpublishFeatures.
Action start 15:17:09: RemoveShortcuts.
Action start 15:17:09: RemoveFiles.
Action start 15:17:09: InstallFiles.
Action start 15:17:10: CreateShortcuts.
Action start 15:17:10: RegisterUser.
Action start 15:17:10: RegisterProduct.
Action start 15:17:10: PublishFeatures.
Action start 15:17:10: PublishProduct.
Action start 15:17:10: ConfigureInstaller.
Action start 15:17:10: InstallFinalize.
Action 15:17:10: ProcessComponents. Updating component registration
Action 15:17:12: InstallFiles. Copying new files
Action 15:17:21: CreateShortcuts. Creating shortcuts
Action 15:17:21: RegisterProduct. Registering product
Action 15:17:23: ConfigureInstaller. [[note: CustomAction]]
Action 15:17:22: PublishFeatures. Publishing Product Features
Begin CustomAction 'ConfigureInstaller'
Action 15:17:28: RollbackCleanup. Removing backup files
Action ended 15:17:28: InstallFinalize. Return value 1.
Action start 15:17:28: RegisterShellExt. [[note: CustomAction]]
Action ended 15:17:33: INSTALL. Return value 1.
Action start 15:17:35: ExitDialog.
Does anyone know an official listing?
The short answer - you should make you custom action deferred and schedule after InstallFiles (if it relies on installed file, which I think it does).
The long answer - you should get acquainted with in-script execution term. Read more about it on MSDN. When you see the InstallFiles the first time in the log file, it's when immediate actions run and deferred actions are written and scheduled to the installation script. The second time is when it actually executes (and installs files). If you make your action deferred, you'll see the same behavior for it in the log file.
This might sound not very clear, but it can't until you read more about the way it is designed to work.
For registering DLLs, it is best to avoid self-registration.
We use the HEAT command to generate a WiX fragment which does the registration for us.
Use
heat file myfile.dll -o myfile.wxs
The advantage of this is that the registry entries are installed and removed correctly and there are no problems with whether the file has been installed or not at the time the registration is done.