I have several folders files included in my Wix based installer. One of the folders may exist on the target machine already outside of any MSI installation. I do not want to replace the folder or files if they already exist for just one of the folders. It might be OK to not replace the files if they are older. Is there anything I need to specify or is this the default behavior?
The definitive answer is in the MSI SDK here: http://msdn.microsoft.com/en-us/library/aa368599(VS.85).aspx
Related
I have a WiX project making msi which replaces much older installation which was made by a set of scripts which unpacked zip files.
I'd like to specify that certain files in msi must force overwrite already existing non-versioned files from the old installation. Later it wouldn't be a pb as msi to msi update would be an upgrade.
Is it possible to specify on a per-file basis that msi must overwrite old non-msi installed files?
I will add some links for you and a summary.
Yes, you can overwrite single files by various means and you can even
force downgrade files setup-wide, but the latter is terribly dangerous
to do (information on dangers in section 4 here).
Ensure Overwrite: This answer describes various measures to always-overwrite files: Ensure file overwriting - with a WiX example. Here is an alternative answer.
The use of companion files is what I would recommend.
Hacking file versions I do myself sometimes - just to make things work.
I prefer to move or rename files to "remove the problem".
See the above links for more on the above "options".
Further information:
On file overwriting in general - step-by-step (describes the REINSTALLMODE property and the problems that are caused by using it to force-downgrading files during installation)
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 ran into an issue that some of the files in my installation were not replaced on upgrade. The problem is not too severe yet, but I would like to avoid it in the future. According to https://msdn.microsoft.com/en-us/library/aa368599(v=vs.85).aspx files with higher version are always used. I considered using a CompanionFile to force upgrade the relevant files. But I would like to know what file should be used as the companion parent. Does it have to be an exe or dll? I am asking because I found online (in WiX: A Developer's Guide to Windows Installer XML) an example of FileSearch on .txt file with MinVersion and MaxVersion. Can txt files be also versioned? And is there anywhere a list of file types WiX searches for version? I did not find anything like it.
If your product has one main exe it is probably best to use that since it logically follows that your new version should always put the new exe there since the exe will have the new version as its file version. In reality, it doesn't matter what file you companion file reference as long as you know it will always be installed (have a higher version) than the previous installation.
I don't think you can version a txt file and probably the version info in the file search is ignored if the file has no version.
Is there any way to create minor upgrade (patch file i.e. .msp) or msi based on the old MSI installer and new MSi installer. we want to give the customer to minor upgraded patch (.msp or .msi0, which contains the changes only.
1) I have created (old) Test.msi, based on the 4 .wxs files. these 4 wxs files helps the installation wizard steps. Below are example.
Welcome.wxs file: where we mentioned just welcome message with reference of our project image
Main.wxs file: which contains the actual script of wxs sourcse file for the compononets and features.
InstallerPath.wxs: Where user can select his installation path
LicenseAgrement.wxs: license aggrement mentione dialog file.
2) I have changed the Product verison number only and modified few of my project files, and added few new files.
3) Then I have created (new) Test.msi, based on those 4 .wxs files.
4) By using these old and new installers, how can I genreate patch (.msp or .msi) for minor upgrade.
If you want to do this the two MSIs then this is a starting point:
http://wixtoolset.org/documentation/manual/v3/patching/patch_building.html
Then there's WiX patching:
http://wixtoolset.org/documentation/manual/v3/patching/wix_patching.html
Or as a variation on the first one, you could create your own .PCP file and run msimsp from the Windows kit as described here:
https://msdn.microsoft.com/en-us/library/aa367816(v=vs.85).aspx
Just to provide one more link, as an additional information to the last link, PhilDW gave already: Useful, if you want to call the patch generation by an own app/framework for patching. Then you could target the PatchWiz.dll from MS directly without using msimsp.
https://msdn.microsoft.com/en-us/library/aa370590%28v=vs.85%29.aspx
But MsiMsp is a simpler first entry of course. Basically it's just a shell for this dll.
But: Creating .pcp Files is not everybody's favor... reserved for people who want to go deeper here.
But IF you want it, it is probably safer of doing it with code than manually, once you have understood all the points.
WiX files always seem to include this line:
<Directory Id="TARGETDIR" Name="SourceDir">
What is "SourceDir"? What is it used for? It's not a real directory name. Is it some kind of magical value?
From: https://robmensching.com/blog/posts/2010/1/26/stackoverflow-what-does-namesourcedir-refer-to/
Honestly, it's something that we should have hidden from the developer but didn't. Sorry. The truth of the matter is that the Windows Installer expects the Directory tree to always be rooted in a Directory row where the primary key (Directory/#Id) is "TARGETDIR" and the DefaultDir column (Directory/#Name) is "SourceDir".
During an install, TARGETDIR will default to the largest drive on the machine. SourceDir will be set to the location where the MSI is being executed. Now, SourceDir is tricky after the initial install because it won't be set unless the ResolveSource action is called. However, you don't want to explicitly call the ResolveSource action because it is likely to prompt you to provide the original source media (aka: insert the CD, please).
What we should have done in the WiX toolset is remove the need to specify the TARGETDIR/SourceDir pair and say "Any Directory element that has no parent will automatically be parented to TARGETDIR because that's what the MSI SDK says to do." Instead, you have to do it yourself... and some devs wonder what it all means.
From the wix.chm documentation, topic "How To: Add a File To Your Installer":
The element with the id TARGETDIR is
required by the Windows Installer and
is the root of all directory
structures for your installation
According to the MSDN documentation TARGETDIR is
the root destination directory for the
installation
Also according to MSDN, SourceDir is
the root directory that contains the
source cabinet file or the source file
tree of the installation package
So the SourceDir property points to a real directory: the one where your MSI file sits. You can see this in the installer log when installing with msiexec /lvx* installer.log installer.msi.
However, for some reason SourceDir is completely ignored when resolving the TARGETDIR. The TARGETDIR must be either set explicitly (e.g. on the command line) or else it resolves to ROOTDRIVE. If ROOTDRIVE is not explicitly set then it is the root of the drive with the most free space.
A quick test shows that installing a component to TARGETDIR indeed puts the files at the root of my D:\ drive, instead of the folder where the MSI sits.
None of this was really helpful for me. I found this thread wondering how to make a Debug build, where my source files (the ones going in the installer) could be pulled from either the "Release" build dir or the "Debug" build dir of the project I am trying to make an installer for.
After some grepping, I found the actual path in the wixproj file, there SourceDir is defined as:
<SourceDir>$(SolutionDir)distribution\Release</SourceDir>
which has really nothing to do with installation files and project files. I was able to add another PropertyGroup that mirrored the release group which now pointed to my debug files:
<SourceDir>$(SolutionDir)distribution\Debug</SourceDir>
Hope this helps someone. I know it's a little off topic, but hopefully it helps someone in the future. Not sure why the project plug-in does not expose this value? Or am I missing that?