I am really new using WIX, my only experience to build a complete install was with INNO, and WIX has been decided the way to go for an MSI
The installation includes a bunch of examples and templates, 427 files, which seems crazy to enumerate even with an utility like HEAT.EXE
So we went for a self-extracting utility. WIX install includes this custom utility and the compressed cabinet file, and then that extracts files and folders via custom action.
Problem is when we try to delete the compressed file and the extractor utility. I haven't found the way to delete them after the extraction takes place. RemoveFile seems to not work, and deleting the file within the extraction utility fires the self-healing mechanism in every run of the application.
Leaving the files in the install is dangerous, it is 200MB and it would reset all the installed examples if user runs the self-extraction utility by accident.
If it is of use, the WIX snippet in charge of this is like that:
<Fragment>
<ComponentGroup Id="App_Files">
<Component Id="cmp_Files_Dat" Directory="INSTALLCOMMONFOLDER" Guid="{8BFED6C2-4D4F-48BB-xxxx-C171F624C90B}">
<File Id="fil_Files_Dat" Source="appfiles\files.dat" />
<RemoveFile Id="rem_Files_Dat" Name="files.dat" On="install" />
</Component>
<Component Id="cmp_UnpackFiles_exe" Directory="INSTALLCOMMONFOLDER" Guid="{5722B5E0-C6E8-4C71-yyyy-61EC0ACA0D72}">
<File Id="fil_UnpackFiles_exe" Source="appfiles\UnPackFiles.exe" Checksum="yes" />
<RemoveFile Id="rem_UnpackFiles_exe" Name="UnPackFiles.exe" On="install" />
</Component>
</ComponentGroup>
<CustomAction Id="action_UnPackFiles" FileKey="fil_UnpackFiles_exe" ExeCommand="[INSTALLCOMMONFOLDER]" Execute="commit" Return="check" Impersonate="no" />
<InstallExecuteSequence>
<Custom Action="action_UnPackFiles" After="InstallFiles" > NOT (REMOVE="ALL") </Custom>
</InstallExecuteSequence>
</Fragment>
The net result of the code above leaves the files, does not remove them.
Thanks in advance
Josep
Related
Firstly I should clarify that I am a novice and have been struggling to understand the WIX formatting, but by cobbling together examples found on-line, I now have the files installing fine so I next need to register my DLL.
I used the example here as a starting point: How to deploy a SharpShell-based shell extension via WiX? but it seems that the SharpShell tool srm.exe may not be getting called at installation.
If I manually call srm.exe as follows, it works as hoped i.e. the DLL is registered and my shell extension works.
srm install MyExtension.dll -codebase
I can also see that the registration has been successful via the Server Manager application that comes with SharpShell.
I can also manually uninstall with the following - not that this is particularly relevant to my problem but it at least confirms that the manual methods work:
srm uninstall MyExtension.dll
Here is a fragment of my WXS file. When I run the resultant MSI, the files are installed but the DLL is not being registered; confirmed via SharpShell's Server Manager. Where am I going wrong?
</Component>
<Component Id="SRMexe" Guid="C17BB61F-6471-46F9-AA87-2D14D2456632">
<File Id='srm' Name='srm.exe' DiskId='1' Source='..\MyExtension\packages\SharpShellTools.2.2.0.0\lib\srm.exe' KeyPath='yes'>
</File>
</Component>
<!-- TODO: Insert files, registry keys, and other resources here. -->
<!-- </Component> -->
</ComponentGroup>
</Fragment>
<Fragment>
<CustomAction Id="InstallShell" FileKey="srm"
ExeCommand='install "[INSTALLFOLDER]\MyExtension.dll" -codebase'
Execute="deferred" Return="check" Impersonate="no" />
<CustomAction Id="UninstallShell" FileKey="srm"
ExeCommand='uninstall "[INSTALLFOLDER]\MyExtension.dll"'
Execute="deferred" Return="check" Impersonate="no" />
<InstallExecuteSequence>
<Custom Action="InstallShell"
After="InstallFiles">
NOT Installed
</Custom>
<Custom Action="UninstallShell"
Before="RemoveFiles">
(NOT UPGRADINGPRODUCTCODE) AND (REMOVE="ALL")
</Custom>
</InstallExecuteSequence>
</Fragment>
It doesn't look like you have any references to the Fragment with the CustomAction definitions so they are not linked into your final output MSI.
Add a CustomActionRef from your Product element to create the reference.
I am new to wix msi .I am using Wix to create msi for my window service .While installing msi, a json file will be created in installation folder with application details(using .net core). This file will be modified (recreating) while upgrading msi .I want to prevent json being modified on each msi upgrade.
I have tried couple of methods. But didn't get desired result.
1.Using custom action-
<Property Id="C_TEMP" Value="C:\Temp" />
<Property Id="ROBOCOPY_EXE">robocopy.exe</Property>
<CustomAction Id="CopyToTemp" Property="ROBOCOPY_EXE" Return="ignore" ExeCommand='"[INSTALLDIR]\Configuration" "[C_TEMP]\ServerSettings" AgentDetails.json' />
<CustomAction Id="CopyFromTemp" Property="ROBOCOPY_EXE" Return="ignore" ExeCommand='"[C_TEMP]\ServerSettings" "[INSTALLDIR]\Configuration" AgentDetails.json /MOVE /IS' />
<InstallExecuteSequence>
<Custom Action="CopyToTemp" Before="InstallInitialize">Installed AND (NOT REMOVE="ALL" OR UPGRADINGPRODUCTCODE)</Custom>
</InstallExecuteSequence>
using component
<Component Id="myconfig" NeverOverwrite="yes" Permanent="yes" >
<File Id="AgentDetails.json" Name="AgentDetails.json" KeyPath="yes" Source="$(var.BasePath)\AgentDetails.json" />
</Component>
WiX newbie here. I'm curious if this approach is possible using WiX.
Problem statement...
I am packaging some SQL files that I want to execute against some parameters that the user will enter at run time. Think connection string information. One of the parameters that the user can enter is the directory where they want the DB to be installed.
Current solution (doesn't work).....
To do this i'm packaging these files using heat. When it sucks in this files one of my SQL files has some tokens in them that a custom action looks for to basically do a find replace in the file. The problem is thatwhile it is indeed doing a find replace it's doing them against the source files that heat sucked in and not the files that exist in the .msi file.
Question 1...
Within the WiX workflow is there a way that via a custom action I can do processing on the files that are stored within the .cab or .msi file? If that is possible can someone show me an example of this?
Question 2 . . .
If question 1 isn't possible the other idea I had was to break the find replace SQL piece and the file install piece into separate msi file. So the first step would be to explode all the files I need into the install directory via one msi. The next msi would execute the SQL piece as at that point the files exist on the file system for me to do editing on. Does this sound like a sane approach to the problem? It could very well be that I'm trying to work around WiX and not with WiX here.
Current code snippets
<Product>
<!-- This is where this will be installed-->
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="INSTALLFOLDER" Name="ZOLLData">
<Directory Id="SQLINSTALLFOLDER" Name="Sql" />
</Directory>
</Directory>
<!-- CUSTOM ACTION DEFINITIONS-->
<CustomAction Id="FindReplaceZEDSTextCA"
Return="check"
BinaryKey="GemstoneInPremiseInstallerCustomActions.CA.dll"
Execute="immediate"
DllEntry="FindReplaceText" />
<!-- Database Information-->
<util:User Id="SQLUser" Name="[SQLUSERNAME]" Password="[SQLPASSWORD]"/>
<sql:SqlDatabase Id="MasterDatabase" Database="master"
Server="[SQLSERVERNAME]"
User="SQLUser"/>
<InstallUISequence>
<Show Dialog="SqlConnectionDlg" After="CostFinalize" />
<Show Dialog="ProgressDlgCustom" After="SqlConnectionDlg"/>
</InstallUISequence>
<InstallExecuteSequence>
<Custom Action="FindReplaceZEDSTextCA" After="InstallFiles">
</Custom>
</InstallExecuteSequence>
</Product>
<Fragment>
<DirectoryRef Id="INSTALLFOLDER" />
</Fragment>
<Fragment>
<ComponentGroup Id="SqlComponents">
<Component Id="CreateDatabase.sql" Directory="INSTALLFOLDER" Guid="6A2C6088-9302-451C-A01B-02D618D4AC27">
</Component>
</ComponentGroup>
</Fragment>
Thanks in advance.
The problem was the my custom action was set with Execute="immediate". This should have been Execute="deferred".
We've prepared installer for our client using InstallShield technology. Installer works fine but client wants this installer in msi technology. We decided to create wrapper using WiX. Msi installer should do few things:
Extract IS installer into temp directory.
Run InstallShield setup.exe.
Remove temporary directory after IS finish.
We haven't done installer in WiX technology before, those are our problems:
We don't know how to embed directory with all it's files (installer) into msi using WiX.
We don't know how to ONLY run msi (it shouldn't install data, only run embeded IS setup.exe during installation and remove after).
We don't know how to run exe during installation.
This is *.wxs file which I've created so far:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="ISSetupPackeger" Language="1033" Version="1.0.0.0" Manufacturer="MyCompany" UpgradeCode="8804d459-2ea5-4bbc-85f7-dfc8419cafe4">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" Id="*" InstallPrivileges="elevated" />
<!-- TODO setup.exe starts but we don't want to run it using cmd -->
<CustomAction Id="LaunchInstaller" Directory="InstallerDir" ExeCommand="cmd /C setup.exe" Impersonate="yes" Return="ignore" />
<InstallExecuteSequence>
<Custom Action="LaunchInstaller" After="InstallFinalize" />
</InstallExecuteSequence>
<Media Id='1' Cabinet='data.cab' EmbedCab='yes'/>
<Feature Id="ProductFeature" Title="WixInstallerProject" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
<!-- TODO How to extract files to temp dir? Is there some TEMP constant? -->
<Directory Id="TARGETDIR" Name="SourceDir" >
<Directory Id="TempDir" Name="inst">
<Directory Id="InstallerDir" Name="Installer"/>
</Directory>
</Directory>
<!-- component group which will be installed into tempdir -->
<ComponentGroup Id="ProductComponents" Directory="InstallerDir">
<Component Id="Installer" Guid="7b8bd37f-7eda-4c3a-8155-9dae1a6bbf98">
<!-- TODO How to embed directory with all its files/subdirectories? -->
<File Id="_Setup.dll" Name="_Setup.dll" DiskId="1" Source="installer\_Setup.dll"/>
<File Id="data1.cab" Name="data1.cab" DiskId="1" Source="installer\data1.cab"/>
<File Id="data1.hdr" Name="data1.hdr" DiskId="1" Source="installer\data1.hdr"/>
<File Id="data2.cab" Name="data2.cab" DiskId="1" Source="installer\data2.cab"/>
<File Id="data2.hdr" Name="data2.hdr" DiskId="1" Source="installer\data2.hdr"/>
<File Id="ISSetup.dll" Name="ISSetup.dll" DiskId="1" Source="installer\ISSetup.dll"/>
<File Id="layout.bin" Name="layout.bin" DiskId="1" Source="installer\layout.bin"/>
<File Id="setup.exe" Name="setup.exe" DiskId="1" Source="installer\setup.exe"/>
<File Id="setup.ini" Name="setup.ini" DiskId="1" Source="installer\setup.ini"/>
</Component>
</ComponentGroup>
</Product>
</Wix>
Some alternatives:
From the files, it looks like the installer you have created with InstallShield is an InstallScript non-MSI installer. You might be able to convert it to an InstallScript MSI installer with an InstallShield converter. See this question and answer.
I read the requirement to convert to MSI differently than you do. For any kind of wrapping or converting to be worthwhile, it should take advantage of Windows Installer managing the installation of the files that are actually installed. To do that, you'd have to rewrite the installer from scratch if a conversion is not feasible. Your approach simply uses an MSI as a bundle. You should get clarification on what you want to do.
If you due go with the bundling route, WiX now offers a bootstrapper/downloader/chainer/bundler called Burn. With it, you can create a single .exe that will extract and run your existing installer. And, if you want, you can create an InstallShield response file so the existing install can be run silently. (See the InstallShield documentation for that.)
You can use a WiX Bootstrapper to embed your existing InstallShield executable. No conversion needed.
In our case the Setup.exe as built from InstallShield actually has an MSI inside. (I think this is usually the case). So then you have two options:
- you can either extract that MSI (google "extract MSI from InstallShield") and embedded it in the bootstapper using MsiPackage
- or you can embed the whole Setup.exe, using ExePackage
Passing Parameters to an MSI: easy
<MsiPackage Id="bla" SourceFile="path-to-msi>
<MsiProperty Name="PUBLIC_PROPERTY_IN_UPPERCASE" value="yourvalue"/>
</MsiPackage>
Passing parameters to an InstallShield Setup.exe: tricky
In our case Setup.exe ends up passing the parameters to the MSI anyway, use /v"the-parameters-go-here-but-you-have-to-escape-properly"
Sounds easy, but it was complicated to properly escape slashes (\), single-quotes ('), double quotes ("). Also, WiX escapes \ differently if the whole InstallArgument is enclosed in ' (single quotes) or " (double quotes). I started with single quotes because it looked easier, but ended up using double quotes. Use the install log to see what gets actually passed through each layer.
<Wix>
<Bundle>
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.HyperlinkLicense">
<bal:WixStandardBootstrapperApplication
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension"
LicenseUrl=""/>
</BootstrapperApplicationRef>
<!-- rumor has it Windows Installer needs the trailing slash for paths -->
<Variable Name="InstallPath" Value="C:\path\to\destination\on\target\machine\" Type="string" bal:Overridable="yes"/>
<Chain>
<MsiPackage Id="package_your_msi"
SourceFile="path-to-msi"
DisplayInternalUI="no"
ForcePerMachine="yes"
Compressed="yes"
After="package_some_other_msi">
<MsiProperty Name="TEST_PROPERTY_5" Value="5"/>
</MsiPackage>
<ExePackage Id="package_installshield_setup_exe"
SourceFile="C:\path\to\Setup.exe"
Compressed="yes"
PerMachine="yes">
<CommandLine InstallArgument="/s /v"/qn INSTALLDIR=\"[InstallPath] \" HOST_ADDRESS=[HostAddress] HOST_PORT=[HostPort] SCANNER_MODEL=[ScannerType]""
Condition="use_registry_values=1 AND other_cond=1"/>
</ExePackage>
</Bundle>
</Wix>
Sources:
https://social.msdn.microsoft.com/Forums/windows/en-US/1a113abd-dca1-482b-ac91-ddb0dcc5465c/is-it-possible-to-pass-commandline-arguments-to-an-installshield-executable?forum=winformssetup
http://helpnet.installshield.com/installshield22helplib/helplibrary/IHelpSetup_EXECmdLine.htm
I want my msi installer to generate a set of folders in a particular location and put a dummy file in each directory.
Currently I have the following CustomActions:
<CustomAction Id="SMC_SetPathToCmd" Property="Cmd" Value="[SystemFolder]cmd.exe"/>
<CustomAction Id="SMC_GenerateMovieFolders" Property="Cmd" ExeCommand="for /f "tokens=* delims= " %a in ([MBSAMPLECOLLECTIONS]movies.txt) do (echo %a)" />
<CustomAction Id="SMC_CopyDummyMedia" Property="Cmd" ExeCommand="for /f "tokens=* delims= " %a in ([MBSAMPLECOLLECTIONS]movies.txt) do (copy [MBSAMPLECOLLECTIONS]dummy.avi "%a"\"%a".avi)" />
These are called in the InstallExecuteSequence:
<Custom Action="SMC_SetPathToCmd" After="InstallFinalize"/>
<Custom Action="SMC_GenerateMovieFolders" After="SMC_SetPathToCmd"/>
<Custom Action="SMC_CopyDummyMedia" After="SMC_GenerateMovieFolders"/>
The custom actions seem to start, but only a blank command prompt window is shown and the directories are not generated.
The files needed for the customaction are copied to the correct directory:
<Directory Id="WIX_DIR_COMMON_VIDEO">
<Directory Id="MBSAMPLECOLLECTIONS" Name="MB Sample Collections" />
</Directory>
<DirectoryRef Id="MBSAMPLECOLLECTIONS">
<Component Id="SampleCollections" Guid="C481566D-4CA8-4b10-B08D-EF29ACDC10B5" DiskId="1">
<File Id="movies.txt" Name="movies.txt" Source="SampleCollections\movies.txt" Checksum="no" />
<File Id="series.txt" Name="series.txt" Source="SampleCollections\series.txt" Checksum="no" />
<File Id="dummy.avi" Name="dummy.avi" Source="SampleCollections\dummy.avi" Checksum="no" />
</Component>
</DirectoryRef>
What's wrong with these Custom Actions or is there a simpler way to do this?
The obvious problems are that the way these custom actions are sequenced they won't properly support managed (elevated/UAC) instals or have any concept of servicing by MSI from a repair, rollback, uninstall, upgrade perspective.
It's hard to give exact advice without knowing exactly what you are doing. I know recently I had a customer who had an SDK with some "samples" that he wanted to instal per-user. I convinced this customer to just distribute ZIP files and write a simple winforms app that could handle asking the user a few questions and extracting these files to a directory of the users choice. This way they could deploy multiple instances of the samples, play with them, delete them, whatever without stepping on MSI's toes.