I would like my MSI to self-delete after the installation process is complete. How can I achieve this? Anyway to do it in WIX only? Do you have to create a custom action?
For those wondering, this installer is generated on the fly and bundled to a specific configuration. After the installation is complete, the MSI file has no use anymore (the user must download a new installer with a fresh configuration to reinstall).
This isn't going to be useful, mainly because the MSI file is needed after the install is complete. Rule 31:
http://blogs.msdn.com/b/windows_installer_team/archive/2006/05/24/605835.aspx
Any kind of repair (automatic or user repair) will require the original MSI file. You're better off deleting it at uninstall time.
In general, the way I've done this type of thing is to get an executable into the user's temp location (don't install it there, copy it there with a custom action) and arrange for it to run and delete the MSI file. Just rely on eventual cleanup of the temp directory to delete the exe. However, it won't be transparent if it requires elevation to do the delete, and popups of unfamiliar programs asking for elevation may get denied.
Related
I have an MSI installer package that enforces the user to choose from a list of possible components to install, like "Version 2018" / "Version 2019" / "Version 2020". The chosen components will install themselves in a folder inside "ProgramData" that is usually writeable by every Administrator account on the system. However, in a recent customer support, this folder was created by the SYSTEM account. Probably the customer's IT installed the environment with SYSTEM privileges.
When the installer tries to put files into this folder it obviously fails. The problem is that the installer notices the missing permission, but still succeeds.
Is there any way to enforce MSI installer to abort / throw an error when a user-chosen component (or any other essential component) could not be installed?
What you want should be the default behavior of WiX / MSI as noted below. It's hard to say what's going on without a logfile.
Take a look at the WiX File#Vital attribute: https://wixtoolset.org/documentation/manual/v3/xsd/wix/file.html
If a file is vital, then installation cannot proceed unless the file
is successfully installed. The user will have no option to ignore an
error installing this file. If an error occurs, they can merely retry
to install the file or abort the installation. The default is "yes,"
unless the -sfdvital switch (candle.exe) or SuppressFileDefaultVital
property (.wixproj) is used.
It sets the underlying msidbFileAttributesVital bitmask in the Windows Installer File table as documented at:
https://learn.microsoft.com/en-us/windows/win32/msi/file-table
The file is vital for the accurate operation of the component to which
it belongs. If the installation of a file with the
msidbFileAttributesVital attribute fails, the installation stops and
is rolled back. In this case, the Installer displays a dialog box
without an Ignore button. If this attribute is not set, and the
installation of the file fails, the Installer displays a dialog box
with an Ignore button. In this case, the user can choose to ignore the
failure to install the file and continue.
We have 2 installer sources in WiX to create installer for a single product with same Product Version, GUID and Package GUID also.
Those 2 installer projects will yield different outputs, one output being just a single MSI file (File1.msi) and other project output is a CD-ROM structure having different MSI file name (File2.msi).
So now issue arises when we installed the product using single MSI file, upon that if we invoke MSI from the other CD-ROM output, we end up getting below mentioned error.
I tried keeping same MSI filename for both kind of installer output, then this above error dialog was resolved but repair functionality isn't working.
If some files were deleted in the product's destination folder, it says source file not found error pointing to CD-ROM installer source folder.
Please help where I'm going wrong. I want to support Repair installation without this errors.
The dialog is expected. You can't change the name of the MSI except during major upgrades.
After that, if you rebuilt to create the different layouts, each MSI probably has a unique PackageCode and that makes them unique packages. That is most likely why repair isn't working. A verbose log file should tell all.
Updated: Compile your main MSI, then run administrative image on it and put the extracted files and MSI on the CD? Put the compressed
version on there as well - just in case they prefer that kind of
release (happens).
I am not sure what will happen when you run both setups this way, but
I think the MSI flagged as an administrative image extract might be
detected by the engine. I am not sure. Should work. Built-in approach for MSI, and you are not fighting wind-mills.
User Accounts: Are you creating any NT User Accounts? Did you set the FailIfExists attribute to yes? Please check here:
User Element (Util Extension). What is the setting for UpdateIfExists? (if any).
Other Issues: There might be other issues as well as Rob mentions. You can not use the same package code for both release types because a package code by definition identifies a unique file. All kinds of X-Files-like problems occur if you try to "hack" this. Not a fight you want to take on.
Administrative Installation: Why would you want to distribute different setups on CDs these days? Corporations that use your setup will run an administrative installation on your setup extracting all files - which is a much better concept. It is essentially a glorified file-extraction, and it is a built in Windows Installer concept intended to make a network installation point for software - among other things. It essentially extracts all files and translates the Media table to use external source files.
List of Links:
What is the purpose of administrative installation initiated using msiexec /a?
Extract MSI from EXE
I'm using a WiX installer to install a Notes plugin. I use the IniFile action to set the fields in notes.ini telling Notes to load my plugin. I'm using WiX 3.7.1224.0
<IniFile Id="HLBridgeDLLINI" Action="addTag" Directory="LOTUSNOTESINIDIRECTORY" Name="Notes.ini" Section="Notes" Key="AddInMenus" Value="HLBridge.dll"/>
<IniFile Id="HLClientDLLINI" Action="addTag" Directory="LOTUSNOTESINIDIRECTORY" Name="Notes.ini" Section="Notes" Key="EXTMGR_ADDINS" Value="HLClient.dll"/>
Before running the installer, the notes.ini file is writable by Everyone. After the install, the Everyone user is missing from the security attributes. Is WiX doing this, presumably for security reasons? If so, is there a way to disable this? I can write a custom action to change the security back if I have to I suppose.
Short version
Custom permissioning would seem to be applied (unexpectedly) via a WiX element or a custom action during the installation process (other possible causes discussed below - maybe check the major upgrade file revert possibility in particular - or the group policy possibility).
Clues for debugging can be found in the WiX source, or the compiled MSI file, or in a verbose log file (to name a few places to start). Details for each option below.
The below was written very "organically" - it evolved a bit - so it is a bit redundant. I will leave it as it is.
Other Possible Causes
Major upgrade file revert: It is quite odd that the file has less rights after the install. Perhaps this indicates a group policy or a file recreate during installation? The latter sounds very unlikely for such an important file - but it could happen if the update is a major upgrade and the original MSI installed the INI file as a file (instead of as INI file entries) and set it to be a non-permanent file.
In this scenario the INI file will be uninstalled and then reinstalled - likely stripping it of any custom ACL permissioning (ACL permissions are very complicated, they can inherit and override, and deny or grant, etc...). Any custom INI entries added to the old file will also be wiped out - check for such missing custom entries after installation.
This is a common problem (major upgrade file revert): major upgrade file uninstall and reinstall making the file appear reverted or overwritten when it has been wiped out and installed fresh instead and can trigger many other problems than ACL issues.
Other potential sources for the unexpected permissioning are also possible:
repair / modify operation for another Lotus Notes-related MSI package targeting the same INI file?
another MSI run as part of the same setup bundle doing permissioning?
group policy / active directory processes enforcing standard ACLs? (sample)
an executable / service run in admin mode doing something funky?
scheduled tasks interference? (some possibilities)
logon scripts doing something funky? (very unlikely in your case, but login scripts can do pretty much "anything" - and they do)
some other, unexpected source. Something with admin rights does this - that is the obvious common denominator.
My 2 cents: if this is an in-house, corporate package, use group policy to apply permissioning instead and remove the operation from your package (unless you deploy to computers outside group policy control - but then you can have a special package which only does permissioning and keep permissioning out of your main package - making it less error prone).
ACLs
The problem you describe is very interesting. I am not aware of anything automatic in WiX that would meddle with ACLs, though I can not guarantee it. There are, however, constructs that are designed to change ACLs when you specify them explicitly - and you need to check your MSI for these constructs (described below)
But first of all: I ran a quick smoke test with a WiX MSI to see if I could replicate the problem, and I can not replicate it. My fear was that this could be something changed in a recent Windows Update. In other words some sort of security fix distributed without anyone's awareness which changes core functionality in Windows Installer (it wouldn't be the first one).
ACL-permissioning
Some info on how ACL permissioning can be implemented in your MSI. Essentially you can use ready-made WiX elements, or run your own custom action.
There are several WiX elements that deal with ACL-permissioning and they result either in settings added to standard, built-in MSI tables or they add entries to custom WiX tables. Look for these elements in your WiX source (if available) (samples):
Permission (maps to built-in, standard MSI LockPermissions table).
PermissionEx (WiX-specific Util extension permissioning - maps to custom WiX table).
PermissionEx (maps to built-in, standard MSI MsiLockPermissionsEx table - a feature added in Windows Installer version 5).
FileSharePermission (WiX-specific Util extension file share permissioning - maps to custom WiX table).
I am not sure why the WiX guys decided to support all these different permissioning options - there are surely good reasons - since it must be a lot of work to maintain for them. I have written permissoning code myself, and in my view it is a time bomb of conspiratory complexity to deal with. Permissions permute like you wouldn't believe, but that is off topic here. In my condensed view very few permissions make any sense, but full flexibility is allowed by ACL permissioning - all the rope you need to shoot yourself in the foot. I prefer the generic "macros": GenericAll="yes", GenericExecute="yes", GenericRead="yes", GenericRead="no", etc...
Additionally you can use custom actions to call command line permissioning tools such as subinacl.exe, cacls.exe, xcacls.exe, icacls.exe or several other ones - which I would definitely not recommend for reliability and security reasons. Custom actions are never preferable when there are other options: Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?
The Permission element I would not use for technical reasons, the built-in MsiLockPermissionsEx table I have never tested. The WiX-specific PermissionEx element is probably what I would choose to use if I needed this ACL permissioning at all.
Inspect MSI
If you have WiX source access, you should be able to find the permissioning elements or the custom action elements that cause the problem.
However, if you do not have WiX source access, you can also check your actual, compiled MSI file for any custom features that could apply custom permissioning. I would focus on the Custom Action table and any custom WiX / MSI tables found in the MSI in question.
In other words: inspect the compiled MSI file used for installation for custom actions and custom tables that are used to set ACLs. See MSDN for a list of standard MSI tables. Any table you don't find there is custom.
To inspect the MSI, use Orca or an equivalent tool. See this answer (towards bottom) for a list of tools you can use (commercial or free): How can I compare the content of two (or more) MSI files?
Verbose Logging
You can also do what I always do: create a proper, verbose log for the MSI install in question. This gives you something to start with to figure out what is happening - and as such it might in some cases be better than just inspecting the MSI. You can find some information on how to do logging here.
Alternatively, you can enable logging for all MSI installations. See installsite.org on logging (section "Globally for all setups on a machine") for how to do this. I prefer this default logging switched on for dev and test boxes, but it does affect installation performance and adds a lot of log files to the temp folder (that you can just zap once in a while). Typically you suddenly see an MSI error and you wish you had a log - now you can, always ready in %tmp%.
I would also make a note of what OS you are on, and determine if the problem is seen only on this OS? And this also involves figuring out if you have the latest hotfixes installed.
As I put in title, the question is how does Wix decide to install a particular file?
So I have exe file and when I change something in exe file and rebuild it, it will not get reinstalled if I don't change version. But if I change something in resource file, resource file will be replaced even if I don't change version of my application. So how wix is deciding if he need to replace file during upgrade or not.
I am using wix3.9. MajorUpgrade is schedule afterInstallFinalize.
Versioned files get replaced based on file version, yes, but data files get replaced based on whether you have specified file hash or not. I think WiX generates file hases by default, so this is the overwrite rule:
https://msdn.microsoft.com/en-us/library/aa370532(v=vs.85).aspx
and it's a Windows Installer rule that applies to all MSI settup, not a WiX decision.
P.S. afterInstallFinalize isn't an ideal place. afterInstallExecute is safer, and it will have the same overall result. The issue is that after InstallFinalize means that the new product is installed. If the uninstall of the older product then fails and rolls back you will end up with both old and new products installed, otherwise known as a mess. afterInstallExecute makes everything part of the transaction so you get the original product installed if there is a failure to uninstall it.
So I have a Wix 3.0 project that installs an IIS7 Native Code Module. When uninstalling I would like to be able to shut down the IIS7 application pools before deleting the file so that a reboot is not necessary.
I am using the appcmd utility to shut down the app pools in a CustomAction element, but when I attempt to do an uninstall I get this error before the customaction is ever invoked:
The setup must update files or
services that cannot be updated while
the system is running. If you choose
to continue, a reboot will be required
to complete the setup.
I have the "After='InstallInitialize'" property set on the CustomAction, because the documentation says that any deferred/not-impersonated custom action must come between InstallInitialize and InstallFinalize.
So is there some way to have a custom action execute before this check for files in use is made? Or disable this check for a given file, or make the check happen later in the sequence?
Yes, you can specify the order for actions to occur by modifying the Sequence column in the InstallExecuteSequence table within the MSI file.
Get the ORCA tool to examine the MSI file to see what I mean, and use a Javascript script to modify the MSI as appropriate.