I'm trying to bundle a demo project with the WiX MSI installer for an application. My goal is to create a "Projects" folder that contains the "Demo Project" folder in the user's Documents directory.
Since my installation scope is "perMachine" adding files to a user directory results in the following error for each file:
It must use a registry key under HKCU as its KeyPath, not a file
I could fix this error by adding the RegistryValue element to each Component but, the demo project has at least 1000 files.
I was thinking about creating another installer for the demo project that would have a "perUser" install scope and then bundle that into a WiX bootstrapper. The only downside is that it feels like a hack.
What is a recommended method when installing complementary material for a application? Should I build another installer or is there a WiX extension that would allow me to copy files to the user's documents directory?
Because it's a demo project and not critical to your app, one approach is to zip it up and have that single zip file as the component. The potential issue with demo projects in your component-per-file case is that users will start fiddling around with the demo in some way and eventually Windows Installer will be prompted to repair it. This is especially true if the project is something that clients open with a dev tool and start changing. You don't want the demo interaction with a repair to impact your running app.
There isn't a WiX or MSI way to copy files to user's folders because that's actually what the Registry keypath is for. It also has the advantage of working for user accounts that haven't been created yet. When another user logs on and uses the app Windows notices that the keypath is missing for that user and that prompts installation of the key path component (the file) from the original install source.
Related
I am trying to find any information how the Windows installer cache is working for Wix Bootstrappers.
For MSIs you do not follow any special rules to be sure a MSI will be cached by Windows. For Bootstrappers (Burns) it looks the same, but I had several issues trying to uninstall the package without original installer.
For me several points are not clear:
how to uninstall a product without original .exe installer?
will .exe installer be cached by default during installation?
does custom user interface affects Windows caching rules for .exe installers?
If you go into your registry and find "Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall", you should be able to find a registry key corresponding to your installer package. There should be one for the bundle itself and one for each .msi installed as part of the bundle. If you find the correct key for the bundle, it will have a value called "UninstallString". This is the string you should use to manually uninstall the package via the command line.
For your second point, Windows automatically caches installed burn bundles. The same registry key you found in the step above will have another value called "BundleCachePath", which should point you to the location of the cached .exe file. This should be under "C:\ProgramData\PackageCache{GUID}", where {GUID} is the package GUID of the bundle.
I can't see why having a custom UI would change the caching location, unless you manually add a dialogue to do so.
Copying of license files using Wix 3.10.2? We have a requirement where we need copy some license files after the installation of the webapplication to IIS. Copying of license files will be the last in the sequence. The license files will reside next to the burn (bootstrapper) setup.exe. This way we can control what license file need to be installed based on the user. I am trying to understand if there will be an issue with number of license files reside along with .exe? Is there a custom action to pick files that are not part of the msi or exe?
1) There will not be an issue with number of license files residing along with exe
2) Using the Media element without a Cabinet name you can specify that certain files will neither be inside a cab or embedded into the msi, no custom action needed. See http://wixtoolset.org/documentation/manual/v3/xsd/wix/media.html
You may need to be more precise about exactly when you want the copy to occur. Your original question says "after the installation" which implies that the install has finished and that your generated MSI is no longer running. but in a later comment you say "during the install".
If after the install is what you want, then you could add a custom executable to your Burn bundle that will do whatever you want. In many of these kinds of situations the application that needs the file just goes and gets it with help from the MSI saying where it was installed from, or by using the SourceList capabilities of Windows Installer to get the location.
If you want to copy files during the install then the CopyFile element is probably what you need. It has wildcard capability to define the files you want to copy. Your source location will be the SourceDir property and the destination will be one of your defined directories. Note that the files will not be uninstalled when the product is uninstalled.
WiX Copyfile:
http://wixtoolset.org/documentation/manual/v3/xsd/wix/copyfile.html
I had to use native bootstrap that comes with Visual Studio SDK. With the bootstrap you can also create pre-requisite like installing .net. This worked for my requirement. Also there is a msbuild task so that you can automate it. Used setup project to create msi and VS bootstrap to create setup.exe
My existing WIX works fine. It allows the user to select a number of features, and when the user proceeds after feature selection, it runs a customaction to install the files using command lines tools. (My features relates one to one with files that just happen to be VSIX files that are installed using VSIXINstaller.exe from the command line customaction).
This has been working fine for months, and to date it has included all the files in the installer package itself. The files are first put on disk, and then the command line customaction is run on them locally.
However, my installer has grown quite large to download on its own (because it includes all the feature files that could possibly be installed), and it is preventing people bothering with the download. Becuase most of our users will only select one of the features (not all), what I want to do is host the individual files online somewhere at know URLs, and change the installer so that depending on what features the user selects, download each feature file in turn, save them to the same local folder and run the same cutomaction on them (like before).
So really this is just a change to the installer that already works file when the files are packaged within it. Now instead of having the files within it, they are fetched from a URL first.
Can anyone give me some guidance how to do this?
I'm not sure that you should be using Windows Installer at all but you are benefiting from the feature selection tree. If you are willing to replace that with a custom GUI (e.g., with WinForms or WPF), you could use a WiX Bootstrapper project. It provides for installing ExePackages with downloadable payloads.
You could also split your MSI into one per feature and use those with the bootstrapper.
See this demo, this article and the WiX source code for WiX's bootstrapper.
I have a Wix 3.6 managed bootstrapper in which the user can select individual packages to download and install. I want to show the download size of each package. How can I access the file size of each packages in the Bundle?
I guess this information is available somewhere in the Wix framework (because the file hashes are used to validate the downloaded files), but I did not find it.
I have an idea for a workaround, but it would be more implementation for me:
Have a wxs file generated programmatically that contains Variable elements containing the file size of the packages. Those variables would be read by the bootstrapper.
When your bundle is created, a BootstrapperApplicationData.xml is added to the bundle. That XML file contains a lot of metadata about the bundle and contained packages. Your bootstrapper application code can load this file by looking in the same direcotry as your bootstrapper application dll lives.
I did not found how by using the burn API, but I implemented my own workaround:
If the local file is present
query the file system
else
query the web server
i have already an installer for our application. but it is exe-file. it was created many years ago.. application of course was updated. we used a bat-file to register new dll-files and to install our service(windows). but we want to do all this by installer not a bat-file. we chosen a wix techology. i read about <Patch> node, but to use it i need an msi from previous version.. i think to do a simple installer, that will stop service,copy and register dll in the installed application's directory, install service. but i don't know will it overwrite the files without any problems?
You can only create an MSP (Patch) for an MSI (Installer). Also, you're going to run into component ref counting problems if you install your components into the same directory as the original install. The problem is MSI will go to see a file is already there, make it as a shared resource and increment the usage counters. Then on uninstall it will decrement, see that it's not 0 and remove to uninstall the files.
I'd suggest installing to a new directory and then using the RemoveFile table to get rid of the old files. Also I'd suggest following good CM / Versioning practices so that you don't have to worry about hacks such as Version Lying.
If all your application just needs to xcopy files, setup a directory and maybe even a ShortCut, it should be a piece of cake.
Versioned files like executables will automatically be overwritten if the version of the file number is lower.
See also Copy if not exist in WiX.