I'm using a WiX setup project to build an MSI package.
I want the MSI, to do a copy of the given file during the installation to the installation folder from the one, where the .msi file is running from.
I read on WiX a bit, and what I found is the <CopyFile... /> element supposed to do that.
Appreciate your help.
Actually I've figured out what the issue is.
The problem is that the SourceDirectory of the CopyFile element supposed to point to the Directory tag id.
Instead, I've used SourceProperty attribute of the CopyFlie tag, and also defined a Property separately, which made the use of the CopyFile element correct.
So it worked.
Related
I've got an C# Wix Custom Action which is reponsible for setting up Datatabase.
All needed Dlls are extracted during Installation into C:\windows\installer\currentinstalldir.
So thats fine. The needed Sql Files are in the same Directory, but they have to be copied to
C:\windows\installer\currentinstalldir\sqlscripts.
I've found a way to get what i want.
This code used as PostBuild Function does what i need.
%wix%SDK\MakeSfxCA.exe “$(TargetDir)$(TargetName).CA$(TargetExt)” “%wix%SDK\x86\SfxCA.dll” “$(TargetPath)” “$(TargetDir)Microsoft.Deployment.WindowsInstaller.dll”
Found on buildmaestro
But due to a limitation of cmd.exe (max Chars) I could not add all files I need.
My Workarround ist to Install these Files as a hidden feature and pass the Directory via Install Property to my Custom Action.
i have created an MSi installer. when i install this installer it also installs a visual studio project which is actually a tutorial project. When user runs this project it generates Bin and Obj folders. when i uninstall the install it does not delete all the those Bin and Obj folder which are generated after the installation.
Can you provide me some example how to use RemoveFolder tag in Wix to remove those two folders and the files inside them recursively.
Thanks
RemoveFile will only remove files that are installed by this msi.
To remove entire folder you have to use util:RemoveFolderEx. To use it you have to:
- Store [TARGETDIR] in registry on install;
- Retrieve it on any actions except on install and store in local variable (using RegsitrySearch)
- Add util:RemoveFolderEx action to your main component and pass your stored path variable to the Property attribute.
If you need an example I could write it for you.
Can anyone tell me how can I find out the location from where the msi installer is being run.
For example I have my Sample.msi and Manuals folder in the folder InstallerExample on the Desktop.
I need this information so that I can use it in File/#Source, like the one given below.
<File Id="MyFileId" Name="MyFile" Source="[SourceDir]Manuals" KeyPath="yes" >
SourceDir should have value C:\Users\bla\Desktop\InstallerExample\Manuals
It will be great if anyone can please help me with this.
I just had the same problem as I wanted my custom action to read a file from where my MSI was so i needed the path. I was able to locate it using
TARGETDIR
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.
I have a problem which is related to the execution of CopyFile on change/repair when using WIX to make a msi setup.
I have a feature which has a component which copies/moves a file from the source folder to a folder already present somwhere inside a users system. It is not the folder of my application. I am only moving this file and not installing it to the the target. This feature works fine if I install it using a complete setup. But when on initial install I chose not to install this feature and then try to install it during a " change " all other custom actions/components inside the feature are executed/installed except for the CopyFile component. This is critical to my setup and if it does not get copied my setup will fail.
Just wondering if anyone found a solution to a similar problem or ever came across a similar issue?
The component which contains the CopyFile operation is configured incorrectly. It should have an actual file or registry entry as a key path.
Although Windows Installer uses components to manage resources, the component key path is main factor which decides if the component is installed or not.
So a component without a resource as a key path will never be installed and the CopyFile operation it contains will never be executed.
(I'm newbe in Installer world so I'm still not sure what is right what is wrong. Anyway.)
I make a installer for service which uses desktop database. The database file should somehow be copied during first installation, be intact during upgrades and finally removed during uninstall.
As far I know, I can't add the database file as a directory component - 'cause installer will automatically remove it during uninstall. On the other hand, if I set the Persistent attribute, the database file will be NEVER removed by installer (even, if I will create separate component with RemoveFile element).
The above leads me to thinking, that I can't add the database file as directory's component.
So what are other options?
Is it possible to include a file into installer file (msi) and then copy the file with custom action to target folder?
Then deletion could be solved with RemoveFile element and condition base on UPGRADINGPRODUCTCODE property.
What do you think, guys?
If you are going to be using a custom action, why not create a custom action the will remove the file on uninstall. I have a custom action like that in a couple of my installers due to updates that happen to the target folder after the program has been running for a while. this just ensures a clean uninstall with no files laying around.