SQL Programmers:
I need to see how you used WiX to execute a collection of SQL files to the server. The files are to be specified in a separate fragment, auto-generated by heat.
The installer does not need to install these SQL files on the target machine, just execute them. (However it would not be a problem if they were installed.)
I also would like to see the error messages (logs) from these executions if possible. I don't see any logging functionality in the WiX SqlExtension.
For starters, I'm trying to use Neil Sleightholm's idea, because it provides logging. Then extend that to dozens of files from heat.
Thanks!
I would use the SqlScript element in the WiX toolset instead of sqlcmd.exe. Heat.exe will not be able to generate all this for you, you'll need to author the SqlScript elements by hand.
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'm converting our current monolithic installer to use a WiX 3.7 Bundle/chain. We have several components that are now building into their own separately-maintainable MSI installers. My next task is to add all of these to a bootloader/bootchainer, but I've hit a snag.
A requirement for our individual installers is that they contain the version in the filename (i.e. MyApplication-5.4.22.msi). I don't see a tool like Heat for collecting MSI packages together, and I don't see a way to add an MsiPackage element with a wildcard to account for varying package names.
As a last resort, I can wrap the bundler inside of another MSBuild script that will 'autocomplete' the filenames and pass the paths in as variables to the bundler. I'm hoping someone can recommend a solution that works directly in the wxs or wixproj setting.
If the msi files are built with WiX Setup projects, the WiX Bootstrapper project can reference them, thereby creating useful WiX variables that are defined as the paths to the msi files.
See my answer here, as well as the list of variables here.
If that's not the case then you can write some MSBuild targets that run before the Build target to figure out the actual file paths. If the available standard and community MSBuild tasks aren't sufficient, you can write your own tasks, either by creating an assembly or using inline code. (And, of course, there is always the Exec task to shell out to a command-line program like cmd.exe, after which you can parse its output to extract the msi paths.)
I’m writing an MSI for using WiX 3.0 and I’m trying to figure out how to make it include all but some files from a directory without having to manually specify each and every attribute. Similar to a dynamic pickup in installshield.
An old installer I’m looking at for reference (which uses WiX 2.0) does the following:
A makefile to call a script that will copy all the necessary files to a separate directory structure that emulates how the final product should be installed.
another script to insert the attributes for each of the files in this temp folder to a partially completed wxs file.
WiX runs
I want to avoid this step and was wondering if there were some commands or pre-processor directives to achieve this WiX itself?
Also the 1st step above spits out some generated files (from a tool) which is then included into the wxs file. Is there a way I can emulate that as well?
You need to specify each file.
However, you can use Heat.exe to automatically generate a wxs file you can include as part of your build process.
I cheaped out with a non-solution, and zipped up the directory and it's files in the build script. The advantage of your current method is that MSI is aware of the files and they could potentially be key files (and thus patched/upgraded and/or repaired).
I'd look into saschabeaumont's suggestion about using heat. clearly a better solution
I've just started looking at wix again now that it looks like installer projects are going to be deprecated from VisualStudio. We have a third party application that is "install via xcopy", which makes it hard for us to track in terms of versioning so we'd like to create an msi for it. There are several hundred files that are part of the installation.
I'd like to use heat to create the list of files for the installer, but I've heard that it's not good to use heat to create the wxs file more than once with autoguids because then your installer will have issues.
I was wondering if in wix 3.6, there was a command line parameter to heat which would take a previously generated wxs file as the source for guids? I want heat to autogenerate guids for any new files, but use the previous output of heat as a database for existing files.
If you use the -ag flag this will set the guids to be generated at compile time and as long as the path doesn't change the compiler will keep the same guid for each component. Rather than use a command-line to do the harvesting it is better to edit the *.wixproj file and add a HeatDirectory element.
I'm trying to get a Wix installer written that does some TypeLib registration.
I'm already pulling the FileVersion off a registered file elsewhere using
!(bind.FileVersion.#InteropDll)
but I want to do the same thing for the TypeLib, which only has separate MajorVersion and MinorVersion attributes. Ideally, I'd like to do
<TypeLib ...
MajorVersion="!(bind.FileVersion.InteropDll).Split('.')[0]"
MinorVersion="!(bind.FileVersion.InteropDll).Split('.')[1]">
How can I accomplish this (or the like)? ...Or should I just not bother with all this and invoke regasm on the dll file at install time?
Thanks.
The WiX toolset doesn't support doing that today. It's an interesting feature request. I would never call regasm during an install. It's way to hard to get rollback and patching and all that working correctly by shelling out to an external executable.