After minimize/restore the EULA window the information disappeared - wix

I'm using ScrollableText control to display EULA and everything works fine except the following scenario:
When EULA dialog is displayed select some word(s) then minimize the EULA window. After restoring the window whole license information disappeared. But after selecting some area in the control the EULA text is appears.
Could somebody help me to understand the root cause of the problem.
I have tried it with 3.0.5419.0 build on WindowsXP SP3 and Windows Installer 4.5 and have the same problem.
The WIX source is following:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<?define ProductName="WixProject"?>
<?define ProductVersion="1.0.1"?>
<?define Manufacturer="WixProject"?>
<?define Language="1033"?>
<?define ProductCode="{830E8896-AD07-4fbb-8828-4165D2C84887}"?>
<?define UpcradeCode="{BA074C59-1F12-4a95-8BD8-177E18234AB3}"?>
<Product Id='$(var.ProductCode)'
Version='$(var.ProductVersion)'
Name='$(var.ProductName)'
Language='$(var.Language)'
Manufacturer='$(var.Manufacturer)'
UpgradeCode='$(var.UpcradeCode)'>
<Package InstallerVersion="200" Compressed="yes" />
<Upgrade Id='$(var.UpcradeCode)'>
<UpgradeVersion OnlyDetect="no" IncludeMaximum="no" Property="OLD_VERSION_FOUND" Maximum='$(var.ProductVersion)' />
</Upgrade>
<Media Id="1" Cabinet="media1.cab" EmbedCab="yes" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLLOCATION" Name="WixProject1">
<Component Id="ReadMeC" Guid="{3DC5A180-EC42-4466-8E4B-1BA37BFF189C}" SharedDllRefCount="yes" Win64="no">
<File Id="ReadMeF" Name="ReadMe.txt" Source="ReadMe.txt" Vital="yes" />
</Component>
</Directory>
</Directory>
</Directory>
<InstallExecuteSequence>
<FindRelatedProducts Sequence="200" />
<RemoveExistingProducts After='InstallFinalize' />
</InstallExecuteSequence>
<Feature Id="ProductFeature" Title="WixProject1" Level="1">
<ComponentRef Id="ReadMeC" />
</Feature>
<UIRef Id="WixUI_Minimal" />
</Product>
</Wix>
This is the very simple WIX file which installs only one file and uses WixUI_Minimal UI.
Even for this installer I can see the same problem.
Thanks.

The ScrollableText control is quite limited (as well as MSI UI in general). It's hard for me to point out the exact reason of such behavior, but probably one of Rob's suggestions helps (for instance, re-save your license.rtf in WordPad and try again).
It would also be interesting to know what exactly helped (when you manage to dig it out). :-)

All of my InstallShield installers don't even the minimize button enabled and I've never missed it. My WiX installers have minimize capabilities but I haven't reproduced your problem. What version of MSI do you have installed? Can you repro this on different machines with different versions?
I can reproduce this behavior using WiX's own installer. I guess I've just never tried to select some text then minimize the installer before. This is clearly a defect in MSI's internal UI and there isn't going to be anything you can do about it other then not enable the Minimize button like InstallShield does.

I have asked about this issue from the WIX developers and they say that the problem is in the Windows Installer RichEdit control.
For details please refer to the link below:
http://sourceforge.net/tracker/?func=detail&atid=642714&aid=3087369&group_id=105970

Related

How to avoid having two versions of a product installed with Windows Installer / MSI?

I have written and am maintaining a number of Wix installation source files which I use to build MSI files for distribution of my application.
I have not explicitly programmed for any kind of upgrading, updating, reinstallation or anything of the kind -- there is a single feature that consists of a number of components with stable GUIDs and I have observed that at least a clean installation does what I expect it to.
However, I (and anyone in possession of the MSI files I distribute) may seemingly install distinct versions of my application side-by-side using their respective (distinct) MSI files. Which isn't a problem in itself, except that I obviously use the same folder as installation target -- "%ProgramFiles(x86)%\Foobar" -- to install the application (version regardless) in. Meaning that in effect there is always ever one version that ends up being installed.
I would argue that Windows Installer behaves correctly in so far that it updates files from whichever MSI package it installed last. One interesting side-effect of this is that if the last MSI was of earlier version, the files in the application folders would be overwritten with the copies from that earlier version.
But none of that seems to be the actual problem to me. I want to fix the disparity between what is actually installed (a single application version) and what Windows tracks as installed -- in my case two records of two distinct application versions.
Since I install the application in a folder that doesn't depend on the version being installed, tracking multiple application versions by Windows is a mistake.
So I guess my question is, how do I fix this so that only one version is shown (reflecting reality) or what's the idiomatic approach in these kind of cases? I deliberately did not overspecify my Wix source code, hoping in return that Windows Installer would use some built-in intelligence to figure everything out on its own. But I may need to add some explicit upgrade or uninstall-previous-version-first instructions, I suppose.
My minified Wix source code (file "foobar.wxs") would look like this:
<?xml version="1.0" encoding="utf-8" ?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
<Product Name="Foobar" Manufacturer="ACME Inc." Id="*" UpgradeCode="ae9a7d6d-6c2d-446a-97d9-9dbe829d2ea8" Language="1033" Codepage="1252" Version="!(wix.PRODUCT_VERSION)">
<Package Id="*" Languages="1033" SummaryCodepage="1252" Compressed="yes" InstallerVersion="200" />
<Icon Id="foobar" SourceFile="!(wix.APPPATH)/foobar.ico" />
<Property Id="ARPPRODUCTICON" Value="foobar" />
<Property Id="ARPCOMMENTS" Value="Gives you full foobar powers" />
<MediaTemplate EmbedCab="yes" CompressionLevel="high" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="DesktopFolder" />
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLDIR" Name="Foobar" FileSource="!(wix.APPPATH)">
<Component>
<File Id="foobar.exe" Name="foobar.exe" />
</Component>
<!-- There are other components like above (assets) -->
</Directory>
</Directory>
<Directory Id="ProgramMenuFolder">
<Directory Id="foobar_menu" Name="Foobar">
<Component Id="foobar_shortcut" Guid="e80a6b95-a145-453a-b327-65a977e741fe">
<Shortcut Icon="foobar" Id="foobar_shortcut" Name="Foobar" Target="[foobar]foobar.exe" />
<Shortcut Directory="DesktopFolder" Icon="foobar" Id="foobar_desktop_shortcut" Name="Foobar" Target="[foobar]foobar.exe" />
<RegistryValue KeyPath="yes" Root="HKMU" Key="Software\[Manufacturer]\[ProductName]" Type="string" Value="" />
<RemoveFolder Id="remove_foobar_menu" On="uninstall" />
</Component>
</Directory>
</Directory>
<Directory Id="CommonAppDataFolder">
<Directory Id="app_data_foobar" Name="foobar">
<Component Guid="" Id="app_data_config_folder">
<CreateFolder />
</Component>
<Component Guid="" Id="app_data_config_folder_log_file">
<File Name="foobar.log" Source="foobar.log.template">
<!-- Add write access permission to the log file to members of "Users" group. -->
<!-- PermissionEx Sddl="D:AR(A;;GWGR;;;BU)" / -->
<!-- Bug with Windows Installer, can't use PermissionEx/MsiLockPermissionsEx table. See https://stackoverflow.com/questions/55145282/how-to-include-inherited-permissions-when-specifying-permissions-for-a-file-inst -->
<util:PermissionEx Append="yes" GenericWrite="yes" User="Users" />
</File>
</Component>
</Directory>
</Directory>
</Directory>
<Feature Id="foobar">
<ComponentGroupRef Id="foobar" />
<ComponentRef Id="foobar_shortcut" />
<ComponentRef Id="app_data_config_folder" />
<ComponentRef Id="app_data_config_folder_log_file" />
</Feature>
</Product>
</Wix>
I am compiling the object file with the following Windows Command Prompt line:
candle.exe -ext WixUtilExtension -out %TEMP% foobar.wxs
And then generating the MSI file with:
light.exe -ext WixUtilExtension -spdb "-dAPPPATH=%apppath%" "-dPRODUCT_VERSION=%version%" -out %TEMP%\foobar-%version%.msi %TEMP%\foobar.wixobj
(using Wix 3.11.1.2318)
Upgrade Code: As long as you have set an upgrade code (which identifies a bunch of related products) you can use a major upgrade element to indicate products that are to be uninstalled as part of a new MSI's installation.
MajorUpgrade Element: Just inject a MajorUpgrade element for default treatment of major upgrades into your existing WiX source. It is a sort of "magic element" doing a lot for you making a number of (usually good) assumptions. There are older and more flexible ways to do it - if you need more detailed control (for legacy purposes usually - auto-magic does not cover all bases):
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
The above is the standard use for all WiX files created in Visual Studio.
Note: I will try to tune up this answer shortly with more links, but give that a go first?
First link: Using Visual Studio to make WiX files. The Hello WiX and Visual Studio-type of scenario.
Major Upgrade Suggested Reading: A few things to know about major upgrades. All WiX markup essentially revolves around the compiled MSI's Upgrade table. It is there that major upgrade logic is configured. Custom actions could also affect things, and a few other things such as launch conditions perhaps.
WiX Documentation: How To: Implement a Major Upgrade In Your Installer
Major Upgrade - Common Problems: WIX does not uninstall older version
Major Upgrade - Manual Configuration: Adding entries to MSI UpgradeTable to remove related products (using old-style Upgrade elements)
Further:
Major Upgrades - How-To & Concept: Doing Major Upgrade in Wix creates 2 entries in Add/Remove Programs

ICE03: Invalid Language Id. Solution without suppressing the retrieval of file information

I have a Setup Project for WiX v3 in Visual Studio. When building I am getting the same error on two different files. I would like to avoid this error without suppressing the retrieval of file information. Ideally I want to solve this with changes to the xml to make it easier for my coworkers to make changes in the future.
ICE03: Invalid Language Id; Table: File, Column: Language
The problem with both files is that they have a language of 1252. Both are dll's from the mid 90's and published by someone else.
I have read that I can pass -sh to light.exe to suppress retrieval of file information. Or I can skip ICE03 when running light. I would rather not do that since I could miss other errors.
I have tried setting the language to 0 on the product. I have also tried setting the default language on the files themselves. There is more language related markup I tried but I didn't have any luck.
In the xml have included only the two files that are causing the error. As well as any supporting xml incase it is of interest.
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="MyProject" Language="1033" Version="1.0.0.0" Manufacturer="My Company" UpgradeCode="8156a540-97a9-4d3d-b345-9a6d8b833be9">
<Package InstallerVersion="200" InstallScope="perMachine" Platform="x86"/>
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate/>
<Property Id="INSTALLLOCATION" Value="C:\"/>
<SetDirectory Action="SetInstallDir" Id="INSTALLDIR" Value="[INSTALLLOCATION]"/>
<Feature Id="ProductFeature" Title="MyProject" >
<ComponentGroupRef Id="Run32Components" />
</Feature>
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="INSTALLDIR">
<Directory Id="RRSDIR" Name="RRS">
<Directory Id="RUN32DIR" Name="RUN32">
</Directory>
</Directory>
</Directory>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="Run32Components" Directory="RUN32DIR">
<Component Id="PICS2.DLL_Component" Guid="{855DFCC8-50B1-4213-81BA-68878EB31486}">
<File Id="PICS2.dll" Name="PICS.dll" Source="RUN32\PICS2.DLL" />
</Component>
<Component Id="PICSCCRW.DLL_Component" Guid="{A1859D86-1556-497D-8254-118823BF92FB}">
<File Id="PICSCCRW.DLL" Name="PICSCCRW.DLL" Source="RUN32\PICSCCRW.DLL"/>
</Component>
</ComponentGroup>
</Fragment>
</Wix>
16-Bit Windows Modules: These two DLL files appear to be 16-bit Windows modules, and as such the language set seems to be a code page
and not a language code at all. I will forward to the WiX guys. Just ignore the whole problem I would say, should be fine - barring the madness of installing 16-bit components :-).
Leaving the below for future reference - just in case. Real answer
ends here.
Preliminary Links: While at it, let me lob you some links to related, pre-existing answers. I assume you have found at least one of them already:
wix installer ice03 Invalid Language Id.
Wix toolset license agreement multi-languages issue
As seen in the latter answer you might have a session toying with code pages for the whole package. There are probably better fixes than that though.
Ad-Hoc Sample: Always impossible to add something that you haven't tested and have it work, but just so it is clearer without compiler variables, LCIDs set in Product and Package elements:
<Product Id="*" Name="MyApp" Language="1041" Version="1.0.0"
Manufacturer="MyCompany" UpgradeCode="PUT-GUID-HERE">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine"
Languages="1041" SummaryCodepage="932" />
LCID:
LCID
VbsEdit LCID Chart
CodePage:
Creating a Database with a Neutral Code Page
https://en.wikipedia.org/wiki/Code_page
https://en.wikipedia.org/wiki/Windows_code_page
Other Links:
wix incorrect font used during installation on Windows XP

Doing Major Upgrade in Wix creates 2 entries in Add/Remove Programs

I've followed the official Major Upgrade guide and I seem to be missing something.
Here is my MCVE:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Codepage="1252" Language="1033" Manufacturer="Bla Corporation"
Name="Bla" UpgradeCode="PUT-GUID-HERE" Version="31.00.0000">
<Package Comments="Contact: Refael Sheinker, refael.sheinker#bla.com." Description="Bla"
InstallerVersion="500"
Compressed="yes"
InstallScope="perMachine"
Keywords="Installer,MSI,Database" Languages="1033" Manufacturer="Bla Corporation" Platform="x64" />
<Media Id="1" Cabinet="my_application.cab" EmbedCab="yes" />
<MajorUpgrade AllowDowngrades="no"
AllowSameVersionUpgrades="no"
Disallow="no"
IgnoreRemoveFailure="no"
MigrateFeatures="yes"
Schedule="afterInstallInitialize"
DowngradeErrorMessage="A later version of [ProductName] is already installed" />
<Property Id="WIXUI_INSTALLDIR" Value="APPLICATIONROOTDIRECTORY" />
<UIRef Id="WixUI_InstallDir" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFiles64Folder">
<Directory Id="PROGRAMFILESSUBDIR" Name="Bla">
<Directory Id="APPLICATIONROOTDIRECTORY" Name="BlaInternal" />
</Directory>
</Directory>
</Directory>
<DirectoryRef Id="APPLICATIONROOTDIRECTORY">
<Component Id="tenlira.ini" Guid="*">
<File Id="tenlira.ini" Source="..\ConfigurationFile\x64\tenlira.ini" KeyPath="yes" />
</Component>
</DirectoryRef>
<Feature Id="MainApplication" Title="TenLira" Level="1">
<ComponentRef Id="tenlira.ini" />
</Feature>
</Product>
</Wix>
All it does is simply installing a single file as an example. So far, so good. Now, all I do is add another Component and File and off course the corresponding ComponentRef in Feature. I specifically leave the Version as is: 31.00.0000. What I expected is that the new installer will not perform a Major Upgrade, but it does. Why? Also, there is now 2 entries in Add/Remove Programs.
Please help me find out what am I missing here. Thanks. Refael.
UPDATE:
Posting the question got me to reread the documentation again and I discovered that the AllowSameVersionUpgrades thingy in the MajorUpgrade element should be set to yes. This time there is only one entree in the Add/Remove Programs, but it still performs Major Upgrade. Why?
UPDATE: Here is a list to help debug failing major upgrades by identifying the most common problems: Common causes of failed major upgrades
Major Upgrade - "The Old, Manual Way"
I guess you are hitting an oddity that may not be handled entirely as expected by the WiX MajorUpgrade element by combining the auto-generated product GUID, the AllowSameVersionUpgrades set to yes and keeping the version number the same.
I can't see any obvious way to set the MinInclusive attribute in WiX's MajorUpgrade element - I could be mistaken, there might be a way I am unaware of. For what it is worth, I am not too keen on allowing "same version upgrades".
However, you could try to "use the old way" to author the Upgrade table using the "older elements" Upgrade and UpgradeVersion. The MajorUpgrade element is essentially a "convenience" feature to set up your major upgrades easily, and I believe it works for most users. Bob Arnson has a blog explaining the introduction of the MajorUpgrade element. This blog also shows a sample of how to do things "manually" with the "older elements" Upgrade and UpgradeVersion (do check it out).
I made a quick mock-up that might do what you want, it is just a "rough draft" - can't make any guarantees. I use preprocessor defines to set some variables that can be referenced in the WiX source file - as a C++ developer this is a piece of cake for you so I won't waste time explaining it - the source should make sense:
<?define MyProductVersion = "31.00.0000" ?>
<?define MyProductCode = "PUT-GUID-HERE" ?>
<?define MyUpgradeCode = "PUT-GUID-HERE" ?>
<!--Recommendation: set a path variable that you can redirect at will to a new release folder (new build output folder): -->
<!-- <?define MyBasePath = "C:\Projects\MyApp\Release\31.00.0000\" ?> -->
<!-- SAMPLE:
<Component Win64="yes" Feature="MainApplication">
<File Source="$(var.MyBasePath)\myapp.exe" />
</Component> -->
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="$(var.MyProductCode)" Codepage="1252" Language="1033" Manufacturer="Bla Corporation"
Name="Bla" UpgradeCode="$(var.MyUpgradeCode)" Version="$(var.MyProductVersion)">
<Package Comments="Contact: Refael Sheinker, refael.sheinker#bla.com." Description="Bla"
InstallerVersion="500"
Compressed="yes"
InstallScope="perMachine"
Keywords="Installer,MSI,Database" Languages="1033" Manufacturer="Bla Corporation" Platform="x64" />
<Media Id="1" Cabinet="my_application.cab" EmbedCab="yes" />
<!-- Major upgrade -->
<Upgrade Id="$(var.MyUpgradeCode)">
<!-- Downgrade Protection -->
<UpgradeVersion Minimum="$(var.MyProductVersion)" OnlyDetect="yes" IncludeMinimum="yes" Property="DOWNGRADE_DETECTED" />
<!-- Major Upgrade Configuration -->
<UpgradeVersion IncludeMinimum="no" Maximum="$(var.MyProductVersion)" IncludeMaximum="no" MigrateFeatures="yes" Property="UPGRADE_DETECTED" />
</Upgrade>
<!-- Major Upgrade: Schedule RemoveExistingProducts -->
<InstallExecuteSequence>
<!-- Potential scheduling (after): InstallValidate, InstallInitialize, InstallExecute, InstallExecuteAgain, InstallFinalize -->
<RemoveExistingProducts After="InstallInitialize" />
</InstallExecuteSequence>
<!--Launch Condition: Abort setup if higher version found-->
<Condition Message="!(loc.NewerVersionDetected)">
NOT DOWNGRADE_DETECTED
</Condition>
<Property Id="WIXUI_INSTALLDIR" Value="APPLICATIONROOTDIRECTORY" />
<UIRef Id="WixUI_InstallDir" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFiles64Folder">
<Directory Id="PROGRAMFILESSUBDIR" Name="Bla">
<Directory Id="APPLICATIONROOTDIRECTORY" Name="BlaInternal" />
</Directory>
</Directory>
</Directory>
<DirectoryRef Id="APPLICATIONROOTDIRECTORY">
<Component Id="Test.ini" Guid="PUT-GUID-HERE" Win64="yes" Feature="MainApplication">
<CreateFolder Directory="APPLICATIONROOTDIRECTORY" />
<IniFile Id="SomeSetting" Action="addLine" Directory="APPLICATIONROOTDIRECTORY" Key="Setting1" Name="Test.ini" Section="MySection" Value="Some Setting" />
<IniFile Id="OtherSetting" Action="addLine" Directory="APPLICATIONROOTDIRECTORY" Key="Setting2" Name="Test.ini" Section="MySection" Value="Other Setting" />
</Component>
</DirectoryRef>
<Feature Id="MainApplication" Title="TenLira" Level="1">
<!--<ComponentRef Id="tenlira.ini" />-->
</Feature>
</Product>
</Wix>
Now the !(loc.NewerVersionDetected) has to be explained. This is a localized string (for delivering your setup in different languages). To use it, right click your WiX project in Visual Studio and go: Add New Item... => Localization File => Add. As the localization file is added, your output MSI will also now go into a en-us folder under your main output location (Debug or Release).
In the localization file, add:
<?xml version="1.0" encoding="utf-8"?>
<WixLocalization Culture="en-us" xmlns="http://schemas.microsoft.com/wix/2006/localization">
<String Id="NewerVersionDetected">A later version of [ProductName] is already installed.</String>
</WixLocalization>
And you should now be able to add new strings to this file and easily translate your whole setup using such language files.
Also add the WiX GUI extension. Right click "References". Add Reference... => Browse to WixUIExtension.dll => Double click this file, and press OK. Normal folder to find the file is: C:\Program Files (x86)\WiX Toolset v3.11\bin.
INI-Files
I just want to mention that INI files should ideally be installed via the IniFile table (entries are treated as atomic key-value pairs allowing advanced merging of keys and values for existing INI files), and not via the File table (the file is treated as a regular file either overwriting the whole existing file or leaving it in place - not enforcing any new values). The WiX element corresponding to the MSI IniFile table is naturally the IniFile element.
An ad-hoc sample:
<Component Id="Test.ini" Guid="PUT-GUID-HERE" Win64="yes" Feature="MainApplication">
<CreateFolder Directory="APPLICATIONROOTDIRECTORY" />
<IniFile Id="SomeSetting" Action="addLine" Directory="APPLICATIONROOTDIRECTORY" Key="Setting1" Name="Test.ini" Section="MySection" Value="Some Setting" />
<IniFile Id="OtherSetting" Action="addLine" Directory="APPLICATIONROOTDIRECTORY" Key="Setting2" Name="Test.ini" Section="MySection" Value="Other Setting" />
</Component>
Links:
Adding entries to MSI UpgradeTable to remove related products
It does a major upgrade because both MSIs have the same UpgradeCode and you have now specified AllowSameVersionUpgrades, so it does the upgrade where it didn't before.
Your build generates a new ProductCode every time, so each MSI is a new product, so you will get it installed twice if it doesn't do an upgrade and once if it does. You may have some assumption about the way upgrades work that you haven't spelled out.
I had the same problem where Version is same, but the Id is different creating multiple entries in Add/Remove programs.
My simple fix was to set AllowSameVersionUpgrades="yes".
<MajorUpgrade AllowSameVersionUpgrades="yes" DowngradeErrorMessage="A newer version of $(var.ServiceName) is already installed." />

WIX Toolset - uninstalling .exe file

I wrote Wix Setup program, that wraps PyTangoArchiving-7.3.2.win-amd64.exe file into into PyTangoArchivingInstaller.msi package.
The installation procces is correct I think, in control pannel -> Programs I can see two additional programs installed:
PyTangoArchiving-7.3.2.win-amd64.exe - the program I wanted to install and
my wrapper - PyTangoArchivingInstaller.
But when I try to uninstall the application, only wrapper is being uninstalled and whole program (PyTangoArchiving-7.3.2.win-amd64.exe ) is still there, I have to uninstall it manually from Control Panel.
Can sb help me with this?
Here is my code:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="PyTangoArchivingInstaller" Language="1033" Version="1.0.0.0" Manufacturer="test" UpgradeCode="PUT-GUID-HERE">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<WixVariable Id="WixUILicenseRtf" Value="$(var.ProjectDir)\License.rtf"/>
<Property Id="WIXUI_INSTALLDIR" Value="INSTALLLOCATION"/>
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate EmbedCab="yes"/>
<UIRef Id="WixUI_InstallDir"/>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id='TempFolder'>
<Directory Id="INSTALLLOCATION" Name="MyApp" >
<Component Id='MyComponent' Guid='*'>
<File Id="mysetup_exe" Source="PyTangoArchiving-7.3.2.win-amd64.exe" />
</Component>
</Directory>
</Directory>
</Directory>
<Feature Id="MainApplication" Title="Main Application" Level="1">
<ComponentRef Id="MyComponent" />
</Feature>
<CustomAction Id="run_setup" FileKey="mysetup_exe" ExeCommand="/SP- /SILENT /SUPPRESSMSGBOXES /LANG=English
/NOCANCEL /DIR="[INSTALLLOCATION]""
Execute="deferred" Impersonate="no"
Return="check" />
<InstallExecuteSequence>
<Custom Action="run_setup" Sequence='5401'>NOT Installed</Custom>
</InstallExecuteSequence>
</Product>
</Wix>
As a general comment, you shouldn't usually be running another exe from inside your MSI, especially if it is an install that shows up in add/remove programs. You should instead use a bootstrapper to chain together multiple installs and this is the preferred way to do what you are trying to do.
Since you run your setup_exe from a custom action, you also need a corresponding custom action to uninstall it.
It would basically be the same format as the one you use to install except with the uninstall command line arguments, whatever they may be.
You will need to schedule your uninstall custom action before the "RemoveFiles" standard action so that the setup exe still exists when you try to run the custom action. You should also condition this custom action with REMOVE~="ALL" AND NOT UPGRADINGPRODUCTCODE.
This approach will run into problems when you try to support upgrades with/without upgrades to the packaged exe install. It is highly suggested you use either the wix burn bootstrapper (bit of a learning curve) or one of the other available bootstrappers for multiple install installations. These would more robustly and correctly support two installs along with upgrades and uninstalls.

How to make certain a Wix installer will override (upgrade) an older version and won't allow a downgrade

I've tried most of the answers on the topic in this forum and other forums, but I still have this problem.
I want to update a bundle version and when I build and install the installer, it should upgrade a previous installation and not create two records in "Programs and Files".
I'm using the following code in Product.wxs.
<Product Id="*" Name="SetupProject1" Language="1033" Version="1.0.0.0" Manufacturer="miro" UpgradeCode="5ba49b49-25c4-47c0-82da-12bf5310af58">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade AllowDowngrades="no" AllowSameVersionUpgrades="yes" IgnoreRemoveFailure="no" DowngradeErrorMessage="loc.NewerVersionInstalled" Schedule="afterInstallInitialize"/>
<MediaTemplate />
<Feature Id="ProductFeature" Title="SetupProject1" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="SetupProject1" />
</Directory>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<!-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -->
<Component Id="ProductComponent">
<File Id="file_Exefile" Source="..\ConsoleApplication1\bin\Debug\ConsoleApplication1.exe">
</File>
</Component>
</ComponentGroup>
</Fragment>
I am even considering writing my own update logic based on the Installer Processes and their ProductVersion properties, but there are too many cases to consider.
Can you tell me what is wrong with this Product.wxs ,so I can fix it.
Thanks.
Best regards,
Evgeni Dyulgerov
There are several things that could be preventing a major upgrade. You appear to have the correct MajorUpgrade logic, but:
It would be better if you incremented your product version in the first three fields, that's more normal for a major upgrade.
It's not obvious that your current UpgradeCode is the same as the older product's, so check that it is.
If the previous product's install scope was perUser the major upgrade will not work because cross-context major upgrades aren't allowed by Windows Installer.
Do the install taking a verbose log and look at all occurrences of FindRelatedProducts. There will be more than one, but see if the one in the upgrade install finds a previously installed product.
You have to add an upgrade section to your product section.
<Upgrade Id='5ba49b49-25c4-47c0-82da-12bf5310af58'>
<UpgradeVersion OnlyDetect='no' Property='ISUPGRADE'
Minimum='0.0' IncludeMinimum='yes'
Maximum='1.0.0.0' IncludeMaximum='no' />
</Upgrade>
Checkout Upgrades and Modularization on Firegiant
Also the WiX Documentation chm (in your Start Menu) is very helpful.