I am using wix toolset to create MSI build.
Here is the Binary source in Product.wxs file.
<Binary Id="BI.CA"
SourceFile="..\..\CustomAction\bin\$(var.Configuration)\CustomAction.CA.dll" />
MSI generated and works as expected in local but fails in build machine showing below error.
Could not find CustomAction.CA.dll
I see that CustomAction.CA.dll is present in the build machine but not the path which I specified.
How do I embed this dll in to MSI?
Update
In build machine, I see the DLL here
E:\BuildAgent\1\b\CustomAction.CA.dll"
When your DLL has the name CustomAction.CA.dll that should not be! Then you need to double the CA here <Binary Id="BI.CA"
SourceFile="..\..\CustomAction\bin\$(var.Configuration)\CustomAction.CA.CA.dll" />
The CA is an internal postfix for the DLL but the output / target of your Custom Action Library should not have it in the name.
You have two options:
a) Remove the CA from the output target in Custom Action project
b) Introduce a second CA in MSI-Project Binary Element
See also How to execute a WiX custom action DLL file with dependencies
Related
I created a solution with two new projects: ATLProject1 which is a COM dll and ATLProject2 which is a COM EXE. To both projects added same simple class with single method.
Added both to WIX setup project (this is an existing setup project that already installs other COM dlls. I'm just using it for this test).
Added following lines to product.wxs:
<Component Id="ATLProject1.dll" Guid="{...}">
<File Id="ATLProject1.dll" Name="ATLProject1.dll" KeyPath="yes" SelfRegCost="0" Source="$(var.TargetDir)\ATLProject1.dll" />
</Component>
<Component Id="ATLProject2.exe" Guid="{...}">
<File Id="ATLProject2.exe" Name="ATLProject2.exe" KeyPath="yes" SelfRegCost="0" Source="$(var.TargetDir)\ATLProject2.exe" />
</Component>
and also
<ComponentRef Id="ATLProject1.dll" />
<ComponentRef Id="ATLProject2.exe" />
The file also has these lines:
<EnsureTable Id="PublishComponent"/>
<EnsureTable Id="Condition"/>
<EnsureTable Id="TypeLib"/>
<EnsureTable Id="Class"/>
<EnsureTable Id="Extension"/>
When running the setup I get error: "Module ATLProject2.exe failed to register. HRESULT -2147024769" (hex 0x8007007f the specified procedure cannot be found).
If I remove ATLProject2 from setup, it succeeds and ATLProject1 is correctly registered in registry (this is without generating registry information e.g. using heat, it just works).
Should exe component be treated differently?
I found this 10 year old post suggesting heat.exe does not treat COM exe as COM. If this is the problem, Not sure if this is still the case?
The Windows Installer does not recommend using SelfReg to register at install time. Instead, adding the registration to your .wxs code or capturing the registration at build time is highly recommended.
To add the registration manually, you don't use EnsureTable, you use the COM related elements (like Class, ProgId, TypeLib). It can be tedious but will be far more robust than trying to selfreg during installation.
Unfortunately, the alternative to capture the registration during build using heat.exe (provided in the WiX toolset) does not support capturing from executables. If you are open to a commercial solution, we (FireGiant) developed an alternative to heat.exe that can capture executable registration (and much more). That advanced harvesting solution has more documentation on the FireGiant site.
RegServer Switch: COM EXE files are normally self-registered via the /RegServer switch as in:
MyBinary.exe /RegServer
In other words EXE files are not registered via the normal regsvr32.exe mechanism. This is the tool used to register COM dll's and OCX files, but it does not handle EXE files. There is also an /UnRegServer switch to unregister EXE COM files - for the executables that support /RegServer (which is not all COM EXE files - it could be missing as a feature).
Self-Registration: Self-Registration is not ideal to register COM files, and here is a write-up of why this is the case: MSI register dll - Self-Registration considered harmful. In MSI one extracts the COM registry data and populates a number of special COM-tables to allow the registration of the COM server in a way that supports advanced features such as rollback. I don't like the COM extract either (risk of self-repair problems, more on self-repair problems), but it helps in most cases - especially when there are dependencies that can trigger registration problems. Moreover it is the way COM files are supposed to be registered in MSI. It is the standard. I should note that some COM settings go into the Registry table still - since there are no dedicated COM-related tables for them.
heat.exe: WiX's own heat.exe tool now can extract COM data from dll files and ocx files (32-bit). But it does not seem to work for EXE COM files - I am not sure why:
heat.exe file MyCOMDll.dll -out MyCOMDll.wxs
RegSpy2.exe: There is a tool you can use to extract COM registration information from both DLL, OCX and EXE files. It can be downloaded from here: http://www.installsite.org/files/iswi/RegSpy2.zip. Here is the main page listing numerous tools. The RegSpy tool is written by Phil Wilson - MSI Expert and author of The Definitive Guide to Windows Installer (APress).
Here is how to extract the COM data from a COM executable (if you get no data, try unregistering the file first and then running regspy.exe):
RegSpy.exe MyBinary.exe /RegServer >> RegistryOutput.reg
The exported *.reg file can then be converted to WiX elements. This is not an easy process. Using the WiX tool heat.exe does not populate the proper COM tables, but rather puts everything in the Registry table (which will work though, barring MSI validation errors):
heat.exe reg MyCOMRegistryData.reg -out MyWiXFile.wxs -sfrag -suid
There used to be a tool called Tallow that converted reg files to WiX COM registration, but this tool is no longer anywhere to be found. I am not aware of any other ways to generate it short of writing it yourself, or download another deployment tool and import the COM data or extract it and decompile the generated MSI with dark.exe and take out the WiX markup. Or figure out how heat.exe writes its WiX XML output with COM data and adapt that to process the output from RegSpy.exe.
UPDATE: Throwing in a link to Paraffin: https://github.com/Wintellect/Paraffin. This is supposedly a "better Tallow". I am not sure what it supports in terms of COM-extract. My quick test seemed to indicate it doesn't support COM extraction at all, but supports auto-generating WiX markup and add and remove files for updates.
Custom Actions: It is possible to register your COM EXE by means of a custom action that calls the /RegServer switch as well, though this is not recommended for all the reasons listed in the link above (self-registration considered harmful).
Some Links:
Adding a .reg file to registry WIX
How to generate WiX XML from a .reg file?
I have a Windows application which is built using MSVC and packaged as an .MSI file using WiX. The whole build is managed by cmake and WiX is invoked using the CPackWIX module.
I am now trying to extend the build environment to also build an .APPX package. I am following the official documentation by FireGiant.
After installing the WiX Expansion Pack, I have added the extension FgAppxExtension.wixext by appending it to the variable CPACK_WIX_EXTENSIONS like so:
SET(CPACK_WIX_EXTENSIONS WixUtilExtension FgAppxExtension.wixext)
I have then edited the .wxs source code as indicated here.
The build runs without any errors but creates no .APPX package. It only creates the usual .MSI package. In the wix.log file I see the line:
"C:/Program Files (x86)/WiX Toolset v3.11/bin/light.exe" -nologo -out "F:/dev/MyApp-build/_CPack_Packages/win32/WIX/MyApp-1.15.0+115-default-eb4abec2e9d2+.msi" -ext "FgAppxExtension.wixext" -ext "WixUIExtension" -ext "WixUtilExtension" -cultures:de-DE;en-US "-loc" "C:/dev/MyApp/resources/packaging/win/WIX.Texts.de-DE.wxl" "-loc" "C:/dev/MyApp/resources/packaging/win/WIX.Texts.en-US.wxl" "F:/dev/MyApp-build/_CPack_Packages/win32/WIX/directories.wixobj" "F:/dev/MyApp-build/_CPack_Packages/win32/WIX/files.wixobj" "F:/dev/AusweisApp2-build/_CPack_Packages/win32/WIX/features.wixobj" "F:/dev/MyApp-build/_CPack_Packages/win32/WIX/main.wixobj"
for the .MSI file, but no line for the .APPX package.
The documentation says that after adding a reference to FgAppxExtension.wixext
... the build process will attempt to create AppX packages.
but this does not happen.
Note that adding a wrong extension in the cmake file will result in a build error.
Changing the .wxs source code without adding the extension will also result in an error:
The Product element contains an unhandled extension element 'fga:Appx'.
So I think the FgAppxExtension.wixext extension is loaded correctly, yet no .APPX package is built.
Do you have any hints?
Loading the FgAppxExtension.wixext extension isn't enough to build the .appx package while building the .msi package. FgAppxExtension does that using MSBuild, which isn't in play when using CMake.
When you're not using MSBuild, you can invoke the FireGiant.Appx.exe tool after Light.exe has produced the .msi and .wixpdb files.
I am using the Wix Toolset 3.8 Visual Studio add-in. I have created a WIX Setup Library which encapsulates some common components that will be consumed by various service deployment projects. This library includes references to several solution files which need to be packaged into each deployment.
These dependencies are used in my wix library fragments in a few different ways. For example:
<Binary Id="InstallationScript" SourceFile=".\Dependency1.vbs" />
<CustomAction Id="DependencyAction"
BinaryKey="InstallationScript"
VBScriptCall=""
Execute="deferred"
Return="check"
HideTarget="no"/>
<Component Id="DLL_Component" Guid="4745D9E2-0EBA-EE57-D8DB-677ADA9E9EC8">
<File Id="DLL1" Name="Dependency1.DLL" Source=".\Dependency1.dll" Vital="yes" KeyPath="yes" DiskId="1"/>
</Component>
The WIX Setup Library builds fine whether I add the files to the project as a link or copy them into the project directory, and whether I reference them in the project directory or use a relative path to their original location. The problem comes when I include the fragment in my WIX Setup Project for my service deployment.
<Custom Action="DependencyAction" Before="InstallFinalize">
NOT INSTALLED AND NOT UPGRADINGPRODUCTCODE
</Custom>
The Setup Project is not at the same relative depth in the folder structure, so a relative path does not point to the same place as it does when referenced from the WIX Library. When I reference the action or feature from the WIX library I get errors like The system cannot fine the file '.\Dependency1.dll' The XML is being read exactly as it is and referenced from the Setup Project location rather than from the Library Project location, so the relative directory is wrong. I can set the relative path in the WIX library to what it should be for the Setup Project that consumes it, or I can copy the solution files into the Setup Project directory as well, but of course, that completely defeats the purpose of using a common WIX library. There are other service deployment projects that need to consume this library.
So the question is, how do I reference solution files in a WIX library in a way that can be used by the Setup Project that consumes it, regardless of the directory that the Setup Project is in?
Create a binary .wixlib that contains the files referenced in your authoring. (That's -bf at the command line, BindFiles property in the .wixproj, "Bind files into the library file" checkbox in Votive.)
I've got following problem: With WiX 3.7 I have built an installer which creates several localized MSI files, for example:
..\bin\x86\Release\en-us\myProject.msi
..\bin\x86\Release\fr-fr\myProject.msi
..\bin\x86\Release\de-de\myProject.msi
Furthermore, I created a Burn bootstrapper project which should ensure that .NET 4.5 is installed:
...
<Chain>
<PackageGroupRef Id="NetFx45Web"/>
<MsiPackage SourceFile="$(var.myProject.TargetPath)"></MsiPackage>
</Chain>
...
Now I have expected that the Burn bootstrapper project creates:
..\bin\x86\Release\en-us\myProject.exe
..\bin\x86\Release\fr-fr\myProject.exe
..\bin\x86\Release\de-de\myProject.exe
but MsiPackage expects a single file.
Is it generally possible to make the Burn project work as I expect?
If this is not the case, is it possible to get to know how the exact name of the created MSI file? I can not hard code the MSI file name, because the output name can vary.
I don't think that this is possible... If you are using MSBuild or something similar you can build it as you're building your MSI packages.
Or you can use a simple script which will call candle.exe with parameter -dYOUR_VARIABLE=myProject.msi.
See Working with MSBuild for more information.
I need to include a dll/exe in the resulting MSI (created through a WiX project), but I do not want to deploy them during installation: I only want to use them in some CustomAction my purpose is to include an existing exe/dll and call it during installation from wxs code (not from a CustomAction dll).
Is it possible to include files which are not deployed during installation? I mean, only pack them inside the resulting MSI, and call them for some task while they are unpacked inside %temp% folder?
Also, it would be nice if somebody could show some sample code of how to include dll/exe through the Product.wxs XML code unit.
Thanks.
Yes, include them using the Binary element.
<Binary Id='MyCustomActionBinary'
SourceFile='$(var.CustomActionProject.TargetPath)' />
This will make them available to your CustomAction where you can use the BinaryKey attribute to reference the Binary:
<CustomAction Id='MyCustomAction'
BinaryKey='MyCustomActionBinary'
DllEntry='MyCustomFunction'
Execute='deferred' />
If you are using C#/DTF to write a custom action, you simply add the DLL's as references. For any other kind of file you add them to the project as Content | CopyAlways and the build will automatically include these files in the self extracting custom action. They will be available in the current directory ( a temp directory) when the CA runs and automatically cleaned up when the CA ends.