I tried
msiexec /i "yarn-1.10.1.msi" TARGETDIR="C:\programs" /qb
The software wwas installed, but not into TARGETDIR. Did I miss something?
You can try the following command line instead:
msiexec.exe /i "yarn-1.10.1.msi" INSTALLDIR="C:\programs" /qb
Standards Compliance: Installing underneath %ProgramFiles% is always recommended. Creativity in deployment is generally always overrated and usually causes unnecessary problems. However, you could have an SOE setup that requires custom paths?
Path Update: A per-user path variable is added to a folder that is not created by default (%SystemDrive%\Users\[UserName]\AppData\Local\Yarn\bin). It is by design. The application probably creates the folder when run.
Administrative Installation: TARGETDIR is generally used during administrative installations (essentially a file extraction from the MSI) to specify the output directory for extracted files:
msiexec.exe /a yarn-1.10.1.msi TARGETDIR=D:\YarnExtractedFiles\
TARGETDIR: Without over-complicating too much, let me add two links with more information about TARGETDIR (this is to try to make the answer helpful also for others - more "general and generic" info - what you might not need, but that you just might want to know):
In WiX files, what does Name="SourceDir" refer to?
Why does the TARGETDIR directory need a name?
Related
Here is what I am dealing with. I have a WIX project, that outputs a MSI file. This works like a charm.
I got a new requirement, that I need to analyse in order to figure out how to approach it. As the new requirement is, I need to get as output, a ZIP file, that contains the files and folders as described in the WIX project...
I searched for the "ZIP" keyword on the official documentation, but did not have any luck in finding something helpful...Maybe some of you guys have an idea?
Obviously, I could use other tools to perform this, like maven and the maven assembly plugin, but that would cause maintenance issues, as there would be 2 different projects, 2 different technologies, and since the files and directories structure is quite big, this could cause issues like one developer modifying a project, and forgetting about the other..
So yeah...difficult question...any input would be welcomed :)
Thx
Administrative Installation: Windows Installer / MSI features a built-in capability to extract all files and make a "network installation point" (a network location where installation can be kicked off from to install on all workstations on the network - ensures all source files are available for repair operations and patching). This is called an administrative installation - in plain terms a glorified file extraction mechanism.
Given the availability of the administrative installation, is a ZIP file really necessary? I suppose you could zip up the extracted admin image? Note that any files that need to go to system, shared or userprofile folders may cause issues and prevent successful launching of your application from the extraction folder (obvious, just mentioning).
Command Line: Try it, from a cmd.exe command prompt (see above link for more details):
msiexec.exe /a MySetup.msi
You could set the Compressed="no" attribute of the Package element to create an uncompressed layout. The result could be easily zipped (excluding the *.msi file) by running any of the freely available command-line zippers (e. g. 7za.exe of 7-zip).
Note:
File elements can override the Compressed attribute of the package.
I am trying to repair an installed msi setup with below argument:
msiexec /f "msipath"
It is repairing properly. But while repairing i need to change its install path too. I tried this argument msiexec /f "msipath" INSTALLDIR="path"
But this is not working.
Whether it is possible to change the install path of an msi while repairing it?. If possible means, please share the exact argument.
It is not possible. For a component to be moved, it must be uninstalled and then reinstalled. (Repair just replaces resources in their original locations.) Consider this note on MsiSetTargetPath:
Do not attempt to configure the target path if the components using those paths are already installed for the current user or for a different user. Check the ProductState property before calling MsiSetTargetPath to determine if the product containing this component is installed.
Thus you typically have to remove and reinstall the entire package. A major upgrade can be a good way to accomplish that, depending on your other needs.
i am using the following command to see the logs in wix installer.
msiexec /i "D:\WixProjects\DFServicesWixSetup\DFServices\bin\Debug\DFServices.msi" /L*V "D:\DFServices.log"
but this command is trying to install the msi again.
I want to execute this command from wix after finishing the installation and log file need to save in installed folder.
can any one help me on this.
You need to decide in advance if you want Windows Installer to make a log file. You also need to decide in advance where it should go. If you want it to end up in the install folder then you either need to copy it there after installation or specify the install folder in advance, too.
In Windows Installer folders are controlled by properties. You can specify such properties in the command that starts installation. The name of the property for the "install folder" depends on how the installer authoring; INSTALLFOLDER is one typical name.
So, you could do this with a command like this:
msiexec /i "D:\WixProjects\DFServicesWixSetup\DFServices\bin\Debug\DFServices.msi" /L*V "D:\path\DFServices.log" /qb INSTALLFOLDER="D:\path"
The /qb switch is reduce the UI such that the user is offered the chance to change the installer folder. It may more may not be need for your installer, depending on what dialogs its UI normally shows.
So, the first step is to figure out which property sets the install folder in your installer.
I am trying to configure Wix to build my msi to only perform build versions (1.0.x) of my product in conjunction with the REINSTALL property, my problem is that when I run the command line: MSIEXEC.exe /i my.msi /l*vx build-inst.log REINSTALL=ALL REINSTALLMODE=vamus it fails to do anything.
I have checked the msi log and found that it is looking for the existing product in the default folder (.\program files (x86)...\myproduct) yet when I installed it the first time I actually used a custom path (c:\myproduct). It was my impression that using REINSTALL the installer would use the installed path of the original product.
Is this actually the case? Should I be specifying the INSTALLDIR on my command line? I would rather not as this is meant for use by clients and I cannot guarantee I will know where the product was installed.
This method of performing "build" upgrades has been suggested in a couple of places but I can not find anything explaining any need to specify the INSTALLDIR
Is there any way to configure this in Wix?
Thanks
Kieran
The easiest solution would be to store the installation directory in the registry and look it up upon reinstalling.
To look up your registry value, you'd use something of the sort:
<Property Id="INSTALLDIR">
<RegistrySearch Id="InstallLocation" Root="HKCU"
Key="SOFTWARE\Company\Product" Name="Location" Type="raw" />
</Property>
If the registry value isn't found, the INSTALLDIR property will be set to your directory structure.
Rob has a complete solution on his blog for when you specify such a property from the command line.
Normally the original entries in the directory table are stored for reinstall without that you store them yourself.
So there is something "special" in your MSI, if this doesn't work. If you have a custom action which sets directory properties like INSTALLDIR, you should not use it. E.g. give them a condition "Not Installed".
I found out that the problem was due to using a wildcard for the product id, so every time a new msi was built it created a new product id.
By fixing this it seemed to resolve the problem, though I have also implemented the registry key option as it will help for upgrades where I do want to change the product id.
Thanks
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?