I am searching for a description, what the attribute "cache" is standing for in the MsiPackage.
When I look at http://wix.sourceforge.net/manual-wix3/wix_xsd_msipackage.htm I cannot get some additional information.
Is there another link with a description of this attribute or can someone explain me this attribute?
The WiX toolset boostrapper/chainer, Burn, has the ability to acquire (copy or download) and cache the packages it installs. The package cache is very useful to provide the Windows Installer a location to go get the original package if for some reason it's cache (under %WINDIR%) is invalidated. There are a number of reasons the Windows Installer will not trust its cache and many of them will hit at the most innopportune times. In particular, minor upgrading and patching can require the original source.
Anyway, the MsiPackage element Cache attribute can be used to force the Burn engine to cache or not cache the package. The default will provide the best user experience so unless you have an explicit reason to change it, I recommend leaving the Cache attribute absent.
Related
I am creating a new version of an existing setup with WiX.
In the process, the version of an included third party product has been updated. It consists of several files (DLLs, Configs, exes), each of which is in its own component.
Do I need to change the GUIDs of all these components?
The new version of the third party product requires a newer VC redist package than the old version, so it is not backward compatible.
The names and destinations of the affected files are the same.
I have read
https://learn.microsoft.com/en-us/windows/win32/msi/changing-the-component-code?redirectedfrom=MSDN
Change my component GUID in wix?
but I am honestly even more confused now.
If it wasn't for the redist dependency change thing, I would have just put the new files in the places of the old ones and left the GUIDs the same.
But now?
The names and destinations of the affected files are the same.
Overall: This basically means that you should keep the same component GUIDs as before. The component GUID essentially identifies a target destination. If the target destination (the absolute path) changes you need a new component GUID.
File Name Change: Keep in mind that renaming a file changes the absolute path even if the path stays the same - hence you need a new component GUID for such file name changes.
Runtime: The incompatibility of the runtime should be irrelevant for the component GUID issue. What third party product is this? Perhaps it has its own installer? If it does it can potentially interfere with your installation in other ways (COM registration etc...).
Setup.exe Launcher: The standard procedure is to bundle runtimes in a setup.exe wrapping your MSI and all runtimes it requires. WiX offers the Burn framework to make such setup.exe launchers. Perhaps try my deployment info search grid for info on Burn. Also: Make yourself a single page PDF explaining your application's runtime requirements for corporate use and include it in your setup.exe so your setup is easy to deploy large scale.
The MSI File Itself: You can also add launch conditions to the MSI to identify that a required runtime is missing (so you can abort) - or you can use a custom action to inspect the system (I find this more flexible, but custom actions in general are complex. Use them read-only - for inspection only, and they are safer).
Links:
Will change in ComponentID for component in Windows Installer effect during upgrade scenerio.?
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.
I'm using latest votive (Wix v3.5) and created a simple Wix VS 2010 setup project. I added my website reference and set the Harvest option as true.
Now since my INSTALLDIR points to a folder under IISROOT, I get this light.exe error:
[filepath]: error LGHT0231: The component
'cmp93982C4086FF8C75F07339DD7CEA8152' has a key file with path
'TARGETDIR\webdir...[filename].xml'. Since this path is not rooted
in one of the standard directories (like ProgramFilesFolder), this
component does not fit the criteria for having an automatically
generated guid. (This error may also occur if a path contains a
likely standard directory such as nesting a directory with name
"Common Files" under ProgramFilesFolder.)
While I understand the reason behind this error, I don't necessarily agree to its rational (maybe I don't understand the innate workings of Wix MSI generation).
How can I resolve this error?
To provide some context:
I'm trying to set this up in conjunction with Team Build. I can use the legacy format and run Heat/Harvest task against a folder to bypass this issue but do not want to go the legacy route.
I have not played enough with the new workflow based build definition, so not sure how I can incorporate this custom task.
I need to run harvest every time the Setup project is built because I do not want to keep track of hundreds of files manually.
The problem is because the component is rooted in TARGETDIR, which WiX cannot use for automatically generating a guid. You can add Directory/#ComponentGuidGenerationSeed to a directory above this component to avoid the problem. By adding this attribute, you must now take responsibility for ensuring the component doesn't get installed to two different directories across upgrades.
In Windows Installer, components need to have a guid that doesn't change between patches, minor upgrades, and major upgrades. As a convenience, WiX can generate a version 5 UUID for you using the component's directory hierarchy as the seed. But, TARGETDIR is ineligible for this.
I believe the reason is that TARGETDIR changes across installations (it's set to the drive that has the most free space). One of the component rules is "each component must be stored in a single folder". If TARGETDIR changed between major upgrades, then you could end up trying to install the same component to a second folder.
I'm learning about Windows-Installer and Wix, and have a number of questions related to how it works:
If a component GUID changes, but the same files are in the component, what happens on a major upgrade? Do the files get replaced?
If a component is removed from a product, what happens to the associated files on a major upgrade? Do the original files get removed on an uninstall?
Am I correct in saying that a major upgrade will replace all files in all components, regardless of whether the assembly version of the file has changed, and that on small updates and minor upgrades, it only replaces a file if the GUID is the same, and the assembly version of the file has been incremented? What if the file doesn't have an assembly version, like an aspx page?
Suppose that a product was deployed on a machine without using an installer. If you then created an installer, with files of the same name in a component as what's in the installed directory, what happens to those files if you tried an installation? Are they replaced?
Am I correct in saying that if I used a tool like heat to create an xml file with all the files in a directory (like for a website), that you'd have to keep the GUIDs the same (manually or with a script), or you'd only be able to do major upgrades?
If a component GUID changes, but the
same files are in the component,
what happens on a major upgrade?
First, the question is whether the old component gets uninstalled. If you don't configure your upgrade to uninstall previous versions of your product, then the component will not be removed (although its files may be overwritten). See also answer to question 2.
Second, the question is whether the new component will be installed. A component is only installed if its keypath is missing. If the keypath is a versioned file, then a lower version also counts as "missing".
Finally, if the new component was marked for installation, and Windows Installer encounters a file with the same name as the one it is trying to install, the File Versioning Rules determine whether the file is replaced or not. For example, a file with a higher version will not be downgraded.
If a component is removed from a
product, what happens to the
associated files on a major upgrade?
Do the original files get removed on
an uninstall?
Unless you put the right entries in the Upgrade table and the InstallExecuteSequence that tells windows installer to remove the old product, the old components will be left alone. See this blog post by Alex Shevchuk for guidance on how to create an installer in wix that removes old versions.
Am I correct in saying that a major
upgrade will replace all files in all
components ...
No. It depends on whether the old component was removed first, whether the new component was installed depending on the keypath, and the file versioning rules.
Suppose that a product was deployed on
a machine without using an installer.
If you then created an installer, with
files of the same name in a component
as what's in the installed directory,
what happens to those files if you
tried an installation?
Again, it depends on whether the components get installed, depending on their keypath, and the file versioning rules.
Am I correct in saying that if I used
a tool like heat to create an xml file
with all the files in a directory
(like for a website), that you'd have
to keep the GUIDs the same (manually
or with a script), or you'd only be
able to do major upgrades?
Correct. The GUID is the identity of a component, so if you would change the GUID there would exist two components (in the old and new version of your product) that installed the same resources to the same target location. And that's a no-no according to MSDN: "Never create two components that install a resource under the same name and target location."
Learn the Component Rules. They're very easy to break and Windows Installer doesn't enforce them. However if you don't follow the rules, then weird strange voodoo happens.
Easy solution, stick with one file per component and use heat with compile time GUID generation (outputs with Guid="*" uses a stable algorithm, it's not random). Having heat generate GUIDs is random, but GUIDs generated by candle at compile time will be stable (based on filename + path hash or something from memory)
If windows installer finds a file already on disk during install, it will increment the reference count for that file assuming it's a "shared" file. Files are only removed from disk once the reference count returns to zero so if a file already existed, the count may never return to zero and you can get files left lying around even after uninstalling.