I am trying to set up an installation, with sql express 2014 as a prerequisite. The installation itself works fine, but when uninstalling, the instance is not removed. I can still access it through my sql manager and find it in the registry.
This is my Chain:
<Chain>
<ExePackage
Id="Netfx4Full"
Name="dotNetFx40_Full_x86_x64.exe"
Cache="no"
Compressed="no"
PerMachine="yes"
Permanent="yes"
Vital="yes"
SourceFile="packages\dotNetFx40_Full_x86_x64.exe"
DownloadUrl="https://download.microsoft.com/download/9/5/A/95A9616B-7A37-4AF6-BC36-D6EA96C8DAAE/dotNetFx40_Full_x86_x64.exe"
DetectCondition="Net4FullVersion AND (NOT VersionNT64 OR Net4x64FullVersion)"
InstallCondition="(VersionNT < v6.0 OR VersionNT64 < v6.0) AND (NOT (Net4FullVersion OR Net4x64FullVersion))">
</ExePackage>
<PackageGroupRef Id="Sql2014Express"/>
<RollbackBoundary />
<MsiPackage Id="MainPackage" SourceFile="MyApplication.msi" DisplayInternalUI="yes" Compressed="yes" Vital="yes" />
</Chain>
This is my ExePackage:
<PackageGroup Id="Sql2014Express">
<ExePackage Id="SQL2014Expressx64"
InstallCondition="VersionNT64 AND NOT SQL2014x64InstanceInstalled"
SourceFile="packages\SQLEXPR_x64_ENU.exe"
DownloadUrl="$(var.SqlWebLink64)"
DisplayName="Installing Microsoft SQL Express 2014"
InstallCommand="/ACTION=Install /INSTANCENAME=$(var.InstanceName) /FEATURES=SQLENGINE /Q /HIDECONSOLE /SkipRules=RebootRequiredCheck /IAcceptSQLServerLicenseTerms /SQLSVCSTARTUPTYPE=Automatic /SQLSVCACCOUNT="NT AUTHORITY\NETWORK SERVICE" /AGTSVCACCOUNT="NT AUTHORITY\NETWORK SERVICE" /ASSYSADMINACCOUNTS=BUILTIN\Administrators /SQLSYSADMINACCOUNTS=BUILTIN\Administrators /BROWSERSVCSTARTUPTYPE=Disabled /ADDCURRENTUSERASSQLADMIN=true /TCPENABLED=1"
UninstallCommand="/Action=Uninstall /INSTANCENAME=$(var.InstanceName) /FEATURES=SQLENGINE /Q /HIDECONSOLE"
Cache="yes"
Vital="yes"
Compressed="no"
PerMachine="yes"
Permanent="no"/>
...
</PackageGroup>
From what i understand, the Permanent="no", should take care of removing the package on uninstall. I have even included and UninstallCommand, but this does not remove the instance either.
What am I missing here?
Let me know if any other info is required to solve this. - Thx!
Exe packages require a DetectCondition to be able to verify whether or not the package is installed. If you notice in your .net exepackage you have
DetectCondition="Net4FullVersion AND (NOT VersionNT64 OR Net4x64FullVersion)"
This tells the installer that this package is installed iff the condition is true. You have to do the same thing in your SQL exe package.
DetectCondition is
A condition that determines if the package is present on the target system. This condition can use built-in variables and variables returned by searches. This condition is necessary because Windows doesn't provide a method to detect the presence of an ExePackage. Burn uses this condition to determine how to treat this package during a bundle action; for example, if this condition is false or omitted and the bundle is being installed, Burn will install this package.
You can do this by creating some registry searches which set some variables. Try this registry search
<util:RegistrySearch
Id='MicrosoftSQLInstalledCheck'
Root='HKLM'
Key='SOFTWARE\Microsoft\Microsoft SQL Server\$(var.InstanceName)\Setup'
Win64='yes'
Value='SQLPath'
Result='exists'
Variable='MicrosoftSQLInstalled'/>
Then in your ExePackage for SQL you can put DetectCondition="MicrosoftSQLInstalled" and that will be true if the registry search found the SQLPath registry entry in the key specified.
Related
I am trying to get Wix to install https://www.silabs.com/documents/public/software/CP210x_Windows_Drivers.zip
It is basically an exe that has multiple files and folders that are required for the installation to work.
I have added this this to Bundle.wxs in the Bootstrapper.
<Fragment>
<PackageGroup Id="WindowsCP210xVCPInstallerx64" >
<ExePackage
Id="WindowsCP210xVCPInstallerx64"
Name="$(var.PackagePath)\CP210xVCPInstaller_x64.exe"
DisplayName="CP210x USB to UART Bridge Virtual COM Port (VCP) drivers"
Cache="no"
Compressed="no"
PerMachine="yes"
Permanent="yes"
InstallCondition="VersionNT64"
InstallCommand="/Q /SW /SE"
RepairCommand="/Q /SW /SE"
UninstallCommand="/U $(var.PackagePath)\CP210x_VCP_Windows\slabvcp.inf /Q"
SourceFile="CP210xVCPInstaller_x64.exe">
</ExePackage>
</PackageGroup>
</Fragment>
However when building I keep getting this error
The system cannot find the file 'CP210xVCPInstaller_x64.exe'.
At present I have just added the entire folder that contains the CP210xVCPInstaller_x64.exe and all the other files it depends on into the project.
I am trying to use a registry search in a WiX bundle to detect if the Microsoft Access Database Engine is installed and then conditionally install it based on the result:
<util:RegistrySearch Root="HKLM" Key="SOFTWARE\Microsoft\Office\14.0\Access Connectivity Engine" Result="exists" Variable="AccessDbInstalled" />
<PackageGroup Id="AccessDb">
<ExePackage
Id="AccessDb14"
Cache="no"
Compressed="yes"
PerMachine="yes"
Permanent="yes"
Vital="yes"
SourceFile="Prereqs\AccessDatabaseEngine_X64.exe"
InstallCommand="/quiet /norestart"
InstallCondition="NOT AccessDbInstalled">
</ExePackage>
</PackageGroup>
However the log shows the registry search as always failing, even though I can plainly see the key in the registry:
[77E4:51D8][2021-10-14T16:45:11]i000: Registry key not found. Key = 'SOFTWARE\Microsoft\Office\14.0\Access Connectivity Engine'
[77E4:51D8][2021-10-14T16:45:11]i000: Setting numeric variable 'AccessDbInstalled' to value 0
I have other registry searches that work fine, just not this one?!
Add Win64="yes". The search defaults to the 32-bit registry hive. You need to tell Burn you want the 64-bit registry.
I have a Wix installer which needs to use a bootstrapper. I have included an extract of the Bundle.wxs below. It shows the Chain, which is to first install .Net 4.5.2 and then depending upon whether the installer has been called with -s for silent install calls ExePackage with or without the InstallCommand with a value of /S. The "OtherInstaller" is a NSIS (nulscript installer) installer so requires a case sensitive /S to trigger it's silent install. I understand that UILevel=2 is the condition to check for for a silent install, but for some reason "OtherInstaller" is not getting called with the /S silent argument. Then after that the "MainMsiInstaller" is called.
<Chain>
<PackageGroupRef Id="NetFx452Web"/>
<ExePackage Id="OtherInstallerLoud"
SourceFile="..\..\bootstrapper\OtherInstallerFile"
InstallCondition="NOT UILevel=2"/>
<ExePackage Id="OtherInstallerSilent"
SourceFile="..\..\bootstrapper\\OtherInstallerFile"
InstallCommand="/S "
InstallCondition="UILevel=2"/>
<MsiPackage Id="MainMsiInstaller"
DisplayInternalUI="yes"
SourceFile="..\..\bin\$(var.CandleCfgName)\MainMsiInstaller.msi" />
</Chain>
Any help appreciated.
In the end a solution that worked for me (whether the best solution, or not) was to ensure that the version of burn.exe I was using was 3.11.xxxx and InstallCondition="WixBundleUILevel=2" which is a WIX variable which is available in v3.11 upwards.
So in essence...
<Chain>
<PackageGroupRef Id="NetFx452Web"/>
<ExePackage Id="OtherInstallerLoud"
SourceFile="..\..\bootstrapper\OtherInstallerFile"
InstallCondition="NOT WixBundleUILevel=2"/>
<ExePackage Id="OtherInstallerSilent"
SourceFile="..\..\bootstrapper\OtherInstallerFile"
InstallCommand="/S "
InstallCondition="WixBundleUILevel=2"/>
<MsiPackage Id="MainMsiInstaller"
DisplayInternalUI="no"
SourceFile="..\..\bin\$(var.CandleCfgName)\MainMsiInstaller.msi" />
</Chain>
I'm working on a Wix project to learn more about Wix. I'm trying to configure my Wix bundle to detect and install .NET 4.5.2 but I'm a little confused. I've seen a lot of examples where the registry is checked but I wanted to know if I can do something like this:
<Chain>
<PackageGroupRef Id="NetFx452Redist" />
<ExePackage Id="Netfx452"
Cache="no"
Compressed="yes"
PerMachine="yes"
Permanent="yes"
Vital="yes"
InstallCommand="/q /norestart"
SourceFile="$(var.ProjectDir)Resources\NDP452-KB2901907-x86-x64-AllOS-ENU.exe"
DetectCondition="NetFx452"
InstallCondition="NOT NetFx452" />
<MsiPackage Id="ShittyMsi"
SourceFile="$(var.MyInstaller.TargetDir)"
Name="$(var.MyInstaller.TargetFileName)" />
</Chain>
If I can't do this and I need to check the registry, how do I know what I need to be looking for in the registry?
You're already using <PackageGroupRef Id="NetFx452Redist" /> so you don't need to check the registry; the package group already takes care of checking the registry and setting the right attributes.
Does Burn support dual-purpose (per-user or per-machine) MSI packages which were prepared according to these Microsoft guidelines?
I tried to prepare such a package, but it looks like bootstrapper created with Burn doesn't uninstall MSI package, which was installed per-machine after raising UAC privileges by End-User.
The source code for Burn is:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle Version="1.0"
Name="AppNameHere"
UpgradeCode="GuidHere">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.HyperlinkLicense" >
<bal:WixStandardBootstrapperApplication LicenseUrl=""
SuppressOptionsUI="yes"
ThemeFile="Customization\Theme.xml"
LocalizationFile="Customization\LangHere.wxl"/>
</BootstrapperApplicationRef>
<Chain>
<PackageGroupRef Id="WindowsInstaller45"/>
<PackageGroupRef Id="NetFx40ClientRedist"/> <!-- Uzywa rozszerzenia WixNetfxExtension do zainstalowania .net -->
<PackageGroupRef Id="vcredist"/>
<MsiPackage Compressed="yes"
SourceFile="MsiFileNameHere"
DisplayInternalUI="yes">
<MsiProperty Name="UPDATEDIR" Value="[UninstallPath]"/>
<MsiProperty Name="WIXBUNDLEKEY" Value="[WixBundleProviderKey]"/>
</MsiPackage>
</Chain>
</Bundle>
<Fragment>
<util:RegistrySearch Root="HKLM" Key="SOFTWARE\Microsoft\VisualStudio\10.0\VC\VCRedist\x86" Value="Installed" Variable="vcredistkeyx86" />
<util:RegistrySearch Root="HKLM" Key="SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\VC\VCRedist\x86" Value="Installed" Variable="vcredistkeyx64" />
<PackageGroup Id="vcredist">
<ExePackage Id="vcredist_x86"
Cache="no"
Compressed="yes"
PerMachine="yes"
Permanent="yes"
Vital="yes"
SourceFile="Components\vcredist_x86.exe"
DetectCondition="(vcredistkeyx86 AND (vcredistkeyx86 >= 1)) OR (vcredistkeyx64 AND (vcredistkeyx64 >= 1))" />
</PackageGroup>
<PackageGroup Id="WindowsInstaller45">
<ExePackage Cache="no"
Compressed="yes"
PerMachine="yes"
Permanent="yes"
Vital="yes"
SourceFile="Components\WindowsXP-KB942288-v3-x86.exe"
InstallCondition="VersionNT=v5.1 AND NOT VersionNT64 AND VersionMsi < v4.5"
InstallCommand="/quiet /norestart">
<ExitCode Behavior="forceReboot"/>
</ExePackage>
</PackageGroup>
</Fragment>
</Wix>
As of WIX V3.9 the answer is a qualified "No" - Burn doesn't currently support dual-purpose per-user or per-machine MSI package.
A dual-purpose MSI package has the ALLUSERS property set to "2". When you build a WIX bootstrapper project referencing this type of MSI package you should see this type of warning:
2>D:\Robert\Documents\Visual Studio 2013\Projects\BurnTest\Bootstrapper\Bundle.wxs(18,0): warning LGHT1133: Bundles require a package to be either per-machine or per-user. The MSI 'D:\Robert\Documents\Visual Studio 2013\Projects\BurnTest\SetupProject\bin\Release\SetupProject.msi' ALLUSERS Property is set to '2' which may change from per-user to per-machine at install time. The Bundle will assume the package is per-machine and will not work correctly if that changes. If possible, remove the Property with Id='ALLUSERS' and use Package/#InstallScope attribute instead.
The build process for a WIX bootstrapper project will try and work out from the chained packages what type of burn installation to create (per-user or per-machine). The logic is convoluted because of the different places you can declare a preference for per-user or per-machine, and the potential conflicts between chained packages. But the general idea is the burn compiler will generate a per-machine installation, unless one of the chained packages is per-user, which will flip the burn installation into per-user mode. The key point is the decision to create a per-user or per-machine package is made at build time. To properly support dual-purpose MSI packages that decision would need to be moved to install time.