I have got the following Problem: In my WiX Setup I need to register a COM Object. I have got a ".tlb" File and a ".dll" File (in my example: XYCommon.dll and a XYCommon.tlb)
Now I want to make the Setup to Register the TLB.
How Can I do this in Windows Installer XML ?
My first try was to work with a CustomAction and Open "Regasm.exe" and Register it - but I dont know how I can bring the Regasm.exe to Register the XYCommon.tlb
Any Help ? Thanks
Use the WiX harvester utility called Heat. It will generate the WiX source that contains the necessary registry entries to correctly register (and unregister) your COM objects.
Will your COM objects (XYCommon.dll and XYCommon.tlb) change often?
If no: then just run Heat on those two files (read up on the command-line parameters and experiment with them to get the desired output), clean them up if necessary, and add them to your project.
If yes:
If you want to try to run Heat as a Visual Studio prebuild event, this SO answer should give you some guidance: Add a folder to installer in wix not files?
Sometimes when you use Heat you still need to tweak then generated .wxs files a little. Therefore you may want to write some wrapper utility that calls heat on a list of files or a directory, then cleans up the output how you would like. Then you can add the utility to your build process.
Example of using heat on an individual file:
heat.exe file myFile.dll -gg -g1 -suid -svb6 -out myFile.wxs
Example of using heat on an entire directory:
heat.exe dir myDirectory -gg -g1 -suid -svb6 -out myDirectory.wxs
Breakdown of some of the parameters I used:
heat.exe: you'll have to specify the full path to the executable if it's not in your path
file myFile.dll: specify that you want to run heat on the single file, myFile.dll
dir myDirectory: specify that you want to run heat on the directory, myDirectory
gg: generate guids for the components
g1: generate guids without the curly braces
suid: suppress creating uniquely generated ids for files and components, instead use the file names as the ids
svb6: suppress harvesting COM information for the VB6 runtime. Note: If you want to register COM objects that use the VB6 runtime, you need to use this flag so that you do not overwrite your VB6 runtime registry entries
Related
I am trying to package the binaries of an external application in my installer. This external application is managed by another department. There can be multiple versions installed and in multiple locations (ie Program Files and Program Files (x86)). There is a batch file that can find the latest version installed.
What I am trying to do is to dynamically define a preprocessor that matches the location of this external app.
Here is how I proceed.
In the Pre-build Event Command Line of the wix project, I call a batch file.
This batch file finds the path to the external app (ie C:\Program Files (x86)\Foo company\Bar program v3.4) and saves it in an environment variable (%EXTERNAL_APP_PATH%).
Then I call heat with: call "%WIX%bin\heat.exe" dir "%EXTERNAL_APP_PATH%" -cg ExternalAppBinaryFiles -dr INSTALLBINDIR -sreg -srd -var var.ExternalAppBinariesSourceDir -ag -sfrag -out "heat_generated.wxs"
Then I generate a custom file heat_var_ExternalAppBinariesSourceDir.wxs whose content looks like the following:
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<?define ExternalAppBinariesSourceDir = "C:\Program Files (x86)\Foo company\Bar program v3.4" ?>
</Wix>
When building the project, I get the following error: heat_generated.wxs(6,0): error CNDL0150: Undefined preprocessor variable '$(var.ExternalAppBinariesSourceDir)'.
I was expecting that file heat_var_ExternalAppBinariesSourceDir.wxs which define this preprocessor variable would be sufficient for the heat generated file. Mostly because I do include heat_var_ExternalAppBinariesSourceDir.wxs in my project files.
My understanding is that heat generated files only resolves preprocessor variables from "global preprocessor variables" defined in the project properties (under Build section, label "Define preprocessor variables").
If I define this preprocessor variable as ExternalAppBinariesSourceDir=C:\Program Files (x86)\Foo company\Bar program v3.4 in the project properties, the solution builds with no error.
However, I do have to hardcode the path which is the opposite of "dynamically find the path of my application".
A possible solution would be to add a custom include file (*.wxi) in the generated heat file. Is there a way to force my heat generated file to include another file? This way I could generate a custom include file with the preprocessor variable defined.
Maybe I am not using heat as intended. If I omit the -var var.ExternalAppBinariesSourceDir part in the command line, the Source attribute of <File> elements are prefixed with SourceDir\.
The result is a build fail with the following error: error LGHT0103: The system cannot find the file 'SourceDir\myapp.exe'.
Is there a way to have absolute paths for Source attributes in a heat generated file?
I would like to keep the process as lite as possible for people that build the installer. For example, double-click the solution file in File Explorer, the solution opens in Visual Studio, right-click the Wix setup project and select Build.
I have looked at many other wix example. I have not found people that have the same use case as mine. Most use cases hardcode a preprocessor with a relative path to the binaries from the project files. Some suggest to change the arguments to candle.exe/light.exe, but like I said, I build from Visual Studio and does not call light.exe or candle.exe directly.
I suspect that I should be able to specify "search paths" for resolving paths that are prefixed with SourceDir\. Looking at my project properties in Visual Studio, there is a "paths" section, but it is all grayed out. Again, I will need to be able to specify dynamic search paths. The problem is still the same. Also search paths might be problematic if multiple directories have the same filename. This is often problematic when packaging a dll with a standard name.
I am using Visual Studio 2017 and Wix Toolset 3.11.
If you want to use an environment variable as the base for your files, you have a few options. Both MSBuild and WiX provide ways to access environment variables directly:
In MSBuild, environment variables are straight-up available as properties. So you could use $(EXTERNAL_APP_PATH) in your .wixproj and get the path. In particular, you could use it in a DefineConstants property in your .wixproj like:
<PropertyGroup>
<DefineConstants>
$(DefineConstants);
ExternalAppBinariesSourceDir=$(EXTERNAL_APP_PATH)
</DefineConstants>
</PropertyGroup>
In WiX, you can directly reference environment variables in the preprocessor using $(env.EXTERNAL_APP_PATH). That will accomplish the same as the above but without using $(var.ExternalAppBinariesSourceDir) as an intermediary.
The option I would choose is a combination of the above two. I'd use BindPaths (a WiX feature designed to allow you to specify where your files are found) along with the MSBuild support for environment variables by adding the following item to your .wixproj:
<ItemGroup>
<BindInputPath Include="$(EXTERNAL_APP_PATH)" />
</ItemGroup>
Then all the file sources rooted in SourceDir\ will automatically search the list of BindInputPaths from your .wixproj to be found.
The latter option is the most powerful and flexible. But any of the above should get you what you want... assuming you want to use the environment variable. Modifying the above to use an MSBuild property from the command line (or other options) should not be hard either.
as for now, what I did was to painstakingly query a directory get the file names and one by one create a and as dependency of the product.
I have tried i am getting errors but I am also confuse as to whether its possible or not.
My directory lies in the same folder as the Wix project and it contains files and subdirectory.
I have like 200 files total and it seems like doing it one at a time is tedious with directories and subdirectory.
Pre-note: The following are my notes from the times when I was using Wix extensively. They are a little old (from around 2017-2018) but may help you for harvesting directories.
When a project contains many files to install, it will take too much time to create file and component elements for all of them. One of the tools that is shipped with WiX (heat.exe) could create these as well.
The general syntax for Heat is:
heat.exe harvestType harvestSource <harvester arguments> -o[ut] sourceFile.wxs
Heat can look at a directory, evaluate all the files in it, and create a .wxs file defining the components needed to install all those.
HarvestType
dir: harvest a directory
file: harvest a file
payload: harvest a bundle payload as RemotePayload
perf: harvest performance counters
project: harvest output of a VS project
reg: harvest a .reg file
website: harvest an IIS website
HarvestSource
It is the path to the directory (relative or absolute) which should not end with a backslash.
Without supplying several arguments, the output of heat is not as helpful as it should be:
All directory element names will be impromptu folders supplied to heat.exe, which will not be after an installation.
All guids are “PUT-GUID-HERE”. Heat can generate its own guids.
Source attributes of all File elements are set to “SourceDir\Filename”.
Components will not be grouped as a ComponentGroup.
To fix these issues, the following arguments should be supplied:
-cg: create a componentgroup with the supplied name
-dr : Name of the directory that will be created on the end-user's computer.
-gg: create GUIDs instead of fillers
-g1: do not use curly brackets for guids
-sfrag: use a single Fragment for everything
-srd: not to harvest the folder itself where files are
-var: a preprocessor variable can be used to insert in place of sourceDir.
-scom: suppress com element harvesting
-sreg: suppress registry harvesting
heat.exe dir “D:\Documents\heatf” -dr MyProgramDir -cg NewFilesGroup -gg -g1 -sfrag -srd -sreg -scom -var “var.MyDir” -out “.\heatfile2.wxs”
Now the components are grouped, each component has Guid, and installed to “MyProgramDir” folder, and file elements use the preprocessor variable supplied.
In order to use this fragment file in the main file, referencing ComponentGroup “NewFilesGroup” under a Feature is enough:
<Feature Id…>
<ComponentGroupRef Id=”MyFilesGroup” />
</Feature>
It should be remembered that every time Heat is run on a directory and -gg flag is set, new Guids will be created for components. If a version is already installed at end users, the guids of the components should never change, as doing so will prevent Windows from accurately keeping track of them. Heat will also create new Id attributes for File and Component elements each time it is used.
Note: If the binary files (dll and exe) are compiled with the flag “COM Visible”, then heat will generate the com class registrations (registry and COM element harvesting) as well in the wsx file.
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'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 am using Heat.exe to harvest a directory containing my DLLs that need to go into the GAC. The fragment is correctly created and I can build my MSI. The problem I am having is that after the wxs source file is created I have to manually edit the file adding the File/#Assembly =".net" attribute.
Is there a way to have heat include Assembly=".net" for each File when using heat.exe from the command line?
Using WiX 3.0.
There's no ad hoc attribute for this, probably because you can have your own rules, which files need this attribute, and which do not.
However, you can apply XSLT transform to the heat output and adjust the resulting XML (WXS file) the way you need. Take a look at -t:<xsl> switch for more details.