I am getting this error "Unresolved reference to symbol 'Property:VS2019DEVENV' in section 'Product:*'" In my Wix setup project I tried the following solutions
Updated Wix toolset version into the latest 3.14
Added reference of WixVSExtension.dll into the setup project
I changed VS2019DEVENV to VS2017DEVENV and build is succeeded for vs2017. Please find the code below
<?xml version="1.0" encoding="utf-8"?>
<!--
# This comment is generated by WixEdit, the specific commandline
# arguments for the WiX Toolset are stored here.
candleArgs:
lightArgs: "<projectname>.wixobj" -out "<projectname>.msi" -ext "C:\Program Files (x86)\WiX Toolset v3.14\bin\WixVSExtension.dll"
-->
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<?define PRODUCT_VERSION="14.0.0.1" ?>
<?define MANUFACTURER="sample"?>
<?define PRODUCT_NAME="test"?>
<?define UPGRADE_CODE="{8F258A2B-2203-43C2-A63C-B829E552F327}"?>
<Product Id="*" Name="$(var.PRODUCT_NAME) v$(var.PRODUCT_VERSION)" Language="1033" Version="$(var.PRODUCT_VERSION)" Manufacturer="$(var.MANUFACTURER)" UpgradeCode="$(var.UPGRADE_CODE)">
<Package Compressed="yes" />
<PropertyRef Id="VS2019DEVENV" />
The version of wix binaries is my problem and I updated those with v3.14
and updated the path in build settings also
".wixobj" -out ".msi" -ext "C:\Program Files (x86)\WiX Toolset v3.14\bin\WixVSExtension.dll"
Related
I am creating a batch file using wix light and candle to create an msi for a project.
I am receiving this error when i run the batch file:
light.exe : error LGHT0307 : Either
'Microsoft.Tools.WindowsInstallerXml.AssemblyDefaultWixExtensionAttribute'
was not defined in the assembly or the type defined in extension
'C:\Users\User1\Documents\testProj\CustomAction\bin\Debug\CustomAction.dll'
could not be loaded.
I have checked the filepath of the CustomAction.dll and verified it is correct. I have added the CustomAction.dll extension to the light command. I am running this batch file from the windows command line in administrator mode.
Batch File
----Line 1-----
"%WIX%bin\candle" *.wxs
-dCustomAction.TargetDir="C:\Users\User1\Documents\testProj\CustomAction\bin\Debug\"
-o obj\Debug\
----Line 2----------
"%WIX%bin\light" obj\Debug*.wixobj -ext
"C:\Users\User1\Documents\testProj\CustomAction\bin\Debug\CustomAction.dll"
-ext "C:\Users\User1\Documents\testProj\CustomAction\bin\Debug\CustomAction.CA.dll"
-ext "C:\Program Files (x86)\WiX Toolset v3.11\bin\WixUIExtension.dll" -ext "C:\Program Files (x86)\WiX Toolset v3.11\bin" -ext WixIIsExtension -ext WixNetFxExtension -ext WixUIExtension -ext
WixUtilExtension -ext
"C:\Users\User1\Documents\testProj\Utils\bin\Debug\Utils.dll" -o
obj\Debug\CommandLineInstaller.msi
I expect this to properly generate an msi file but i am receiving error code error LGHT0307.
I have removed CustomActino.dll and CustomAction.CA.dll from the candle command line. I have removed C:\Program Files (x86)\WiX Toolset v3.11\bin\WixUIExtension.dll and included -ext "C:\Program Files (x86)\WiX Toolset v3.11\bin" to the light command. Currently i am receiving this error " light.exe : error LGHT0144 : The extension 'C:\Program Files (x86)\WiX Toolset v3.11\bin' could not be loaded because of the following reason: Could not load file or assembly 'file:///C:\Program Files (x86)\WiX Toolset v3.11\bin' or one of its dependencies. Access is denied."
Here is the new command line:
"%WIX%bin\light" obj\Debug*.wixobj -ext "C:\Program Files (x86)\WiX Toolset v3.11\bin" -ext "C:\Program Files (x86)\WiX Toolset v3.11\bin\WixUIExtension.dll" -ext "C:\Program Files (x86)\WiX Toolset v3.11\bin" -ext WixIIsExtension -ext WixNetFxExtension -ext WixUIExtension -ext WixUtilExtension -ext "C:\Users\User1\Documents\testProj\Utils\bin\Debug\Utils.dll" -o obj\Debug\CommandLineInstaller.msi
Custom Action DLLs: I think you might need to take out the CustomAction.dll entry in the light.exe command line. Maybe take out all entries and add back one entry at a time. See sample command lines below.
CustomAction.dll - Managed Code assembly dll
CustomAction.CA.dll - Win32 wrapper dll for managed code dll:CustomAction.dll
MakeSfxCA.exe: The latter one is what you should include in your MSI. The DTF (Deployment Tools Foundation) tool MakeSfxCA.exe creates this .CA version of your managed DLL. It contains all the necessary config files for your managed dll to run. You can open CustomAction.CA.dll with 7Zip or another, capable compression program to see the content.
Batch Build: Minimal command line to build WiX project (if you use a default WiX GUI) - and how-to make a simple WiX project in Visual Studio:
candle.exe product.wxs -ext WixUIExtension
light.exe -out Test.msi product.wixobj -ext WixUIExtension
Votive: I suppose you could try to build the WiX project in Visual Studio to see what command lines are used for candle.exe and light.exe in the built output window. That should give you a clue what might not be necessary (I suppose that might be what you already did):
Links:
Please see this similar, but slightly different issue
MSBuild: Most people use MSBuild - I believe - to build via the command line like that. There is a section on using MSBuild in the WiX help material.
Custom Action DLL: I include custom action DLLs from within the WiX source file. Here is a sample with hard coded paths in the WiX source file for how you can include your custom action dll:
The construct: $(env.SystemRoot) - in the WiX source below -
gets the environment variable %SystemRoot% - which resolves to
C:\ on most systems (to list environment variables open a cmd.exe
and type set and press Enter). The below source should hence
compile on all systems without modifications:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="SimpleCustomAction" Language="1033" Version="1.0.0.0"
Manufacturer="-" UpgradeCode="">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate EmbedCab="yes" />
<Feature Id="ProductFeature" Title="SimpleCustomAction" Level="1" />
<!-- START: Custom action entries -->
<!-- Hard coded SourceFile path to compiled C# dll Win32 wrapper (MakeSfxCA.exe) -->
<Binary Id="CustomActions" SourceFile="C:\CustomAction1.CA.dll" />
<!-- BinaryKey => Use Binary element Id from above entry-->
<!-- DllEntry => Exported method name inside dll (C# method name) -->
<CustomAction Id="SimpleCustomAction" BinaryKey="CustomActions" DllEntry="CustomAction1"/>
<!-- Run custom action -->
<InstallExecuteSequence>
<Custom Action="SimpleCustomAction" After="CostFinalize" />
</InstallExecuteSequence>
<!-- END: Custom action entries -->
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="SimpleCustomAction">
<Component Feature="ProductFeature">
<File Source="$(env.SystemRoot)\notepad.exe" />
</Component>
</Directory>
</Directory>
</Directory>
</Product>
</Wix>
Batch Build: This should suffice, no need to specify anything in the candle.exe and light.exe commands to build the MSI. Here are some sample commands:
"%WIX%bin\candle.exe" product.wxs -ext WixUIExtension >> Build.log
"%WIX%bin\light.exe" -out Test.msi product.wixobj -ext WixUIExtension >> Build.log
I am trying to create a Wix Bootstrap executable that contains an .msp patch file. I have generated the patch file using pyro.exe and the patch itself works absolutely fine and updates the required files correctly when ran by itself.
However we package all our .msi's in a Wix Bootstrap project with a custom user interface, which I have cloned for the patch files. However when running the executable this way it removes all the files from the install directory.
Has anyone experienced this issue before or am I doing something wrong? Thank you in advance, let me know if you need further code examples.
BootstrapBundle.wxs
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"
xmlns:vi="http://schemas.visualinstaller.de/VisualInstallerWixExtension">
<Bundle Name="MyProgram" Version="1.0.0.1"
Manufacturer="Test"
UpgradeCode="GUID"
SplashScreenSourceFile="Resources\splash.bmp"
IconSourceFile="Resources\icon.ico">
<Update Location="http://test.laika42.com/UpdateInfo.xml"/>
<BootstrapperApplicationRef Id='ManagedBootstrapperApplicationHost'>
<PayloadGroupRef Id='VisualInstallerRuntimeFiles'/>
</BootstrapperApplicationRef>
<Variable Name="INSTALLFOLDER" bal:Overridable='yes'
Value='[ProgramFilesFolder]Test\MyProgram\'/>
<Chain>
<PackageGroupRef Id='NetFx45Web' /> <!-- Fails to build without this? -->
<MspPackage Id='PatchMsp' SourceFile='C:\Patches\Patch.msp' />
</Chain>
</Bundle>
</Wix>
Just had this problem myself. It seems that the UpgradeCode for the bundle must be different to the UpgradeCode for the MSI - the bundle will remove anything older with the same Bundle UpgradeCode, including the original full MSI. I have to say I find the Wix documentation less than illuminating. Bdum-tsh.
The important bits seem to be having different UpgradeCodes for the MSI, the MSI bootstrapper bundle and the patch bootstrapper bundle but keeping each one of the three the same going forward, and the RelatedBundle element.
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<?include $(var.SolutionDir)\Installer\ProductDefs.wxi?>
<?include $(var.SolutionDir)\Installer\version.wxi?>
<!-- A DIFFERENT UpgradeCode to the main bundle, but consistent for all patches. I think. -->
<?define PatchBundleUpgradeCode = "AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA"?>
<!-- The UpgradeCode of the Bundle that was used to deploy the MSI originally. -->
<?define MSIBundleUpgradeCode = "BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB"?>
<!-- ... both of which are different to the MSI UpgradeCode. -->
<Bundle Name="$(var.ProductName) $(var.ProductVersion)"
ParentName="$(var.ProductName)"
Version="$(var.ProductVersion)"
Manufacturer="$(var.Manufacturer)"
UpgradeCode="$(var.PatchBundleUpgradeCode)"
IconSourceFile="$(var.SolutionDir)\Installer\MyIcon.ico"
AboutUrl="https://www.somecompany.com/"
HelpUrl="https://www.somecompany.com/support/"
>
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense">
<bal:WixStandardBootstrapperApplication
LicenseFile="$(var.SolutionDir)\Bootstrapper\license.rtf"
LogoFile="$(var.SolutionDir)\Bootstrapper\Logo.jpg"
ShowVersion="yes"
SuppressOptionsUI="yes"
/>
</BootstrapperApplicationRef>
<OptionalUpdateRegistration Classification="Update" Name="$(var.ProductName) $(var.ProductVersion)"/>
<RelatedBundle Id="$(var.MSIBundleUpgradeCode)" Action="Patch" />
<Chain>
<MspPackage SourceFile="$(var.ProjectDir)\Release\$(var.ProductName) $(var.ProductVersion) Patch.msp" DisplayInternalUI="yes"/>
</Chain>
</Bundle>
</Wix>
Also, if you want to apply more than one minor patch, make sure your PatchMetadata element (in the patch.wxs, not the bundle.wxs) contains the following attribute otherwise the first patch will apply but subsequent ones won't.
MinorUpdateTargetRTM="1"
I have an issue when creating a patch, using pyro tool. I am not sure if this is a WiX tool defect, or I am doing something wrong. When executing the pyro.exe, my release builder crashes with the output from the pyro tool as below:
Windows Installer XML Toolset Patch Builder version 3.11.0.1701
Copyright (c) .NET Foundation and contributors. All rights reserved.
pyro.exe : error PYRO0001 : Object reference not set to an instance of an object.
Exception Type: System.NullReferenceException
Stack Trace:
at Microsoft.Tools.WindowsInstallerXml.MediaRow.get_LastSequence()
at Microsoft.Tools.WindowsInstallerXml.Patch.AttachTransforms(ArrayList transforms)
at Microsoft.Tools.WindowsInstallerXml.Tools.Pyro.Run(String[] args)
And, this is the execution sequence of WiX tools I am using to build a patch:
candle.exe -out Patch.wixobj -ext WixUIExtension -ext WixNetFxExtension -arch x86
light.exe -out Product_1.wixout Product_1.wixobj -xo -ext WixUIExtension -ext WixNetFxExtension
light.exe -out Product_2.wixout Product_2.wixobj -xo -ext WixUIExtension -ext WixNetFxExtension
torch.exe -out Diff.wixmst Product_wixout Product_2.wixout -p -xi -ext WixUIExtension -ext WixNetFxExtension
light.exe -out Patch.wixmsp Patch.wixobj -ext WixUIExtension -ext WixNetFxExtension
pyro.exe -outPatch.msp Patch.wixmsp -t MyPatch Diff.wixmst
Please advise.
Many thanks
The current workaround for this issue (that is not documented, for whatever terrible reason), is to change the way media is defined in your product you are creating a patch for.
So, instead of using the following in your Product element (which is the recommended approach...):
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product ...>
...
<MediaTemplate EmbedCab="yes" />
...
</Product>
</Wix>
You will need to replace the MediaTemplate element with the Media element, like the following:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product ...>
...
<Media Id="1" Cabinet="MyProduct.cab" EmbedCab="yes" />
...
</Product>
</Wix>
For more advanced installations, the Media element will be more difficult to use than MediaTemplate, but there is decent documentation on these elements out there. What I've shown is for the simplest type of install. I think this issue cropped up when the WiX Toolset team introduced the newer, easier to use MediaTemplate, and somehow the patching use-case was missed in testing.
Hopefully this helps anyone else who is trying to use WiX Patching and getting this nasty exception.
I'm trying to create a patch using WiX 3.6 following this example containing 2 C# projects (executable and library). But I'm getting this error:
warning PYRO1079 : The cabinet 'RMT.cab' does not contain any files. If this patch contains no files, this warning can likely be safely ignored. Otherwise, try passing -p to torch.exe when first building the transforms, or add a ComponentRef to your PatchFamily authoring to pull changed files into the cabinet.
error PYRO0227 : The transform being built did not contain any differences so it could not be created.
Executed commands:
set w="c:\Program Files (x86)\WiX Toolset v3.6\bin\"
%w%torch.exe -p -xi 1.0.0.0\PatchMe.Installer.wixpdb 1.1.1.1\PatchMe.Installer.wixpdb -out Patch\Diff.wixmst
%w%candle.exe Patch.wxs
%w%light.exe Patch.wixobj -out Patch\Patch.WixMsp
%w%pyro.exe Patch\Patch.WixMsp -out Patch\Patch.msp -t RTM Patch\Diff.wixmst
Directories "1.0.0.0" and "1.1.1.1" contain output of two different versions of same projects (changed AssemblyVersion and some code changes).
Patch.wxs file:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<?include Variables.wxi ?>
<Patch AllowRemoval="yes"
Manufacturer="$(var.Manufacturer)"
DisplayName="$(var.ProductName) $(var.ProductVersion)"
Description="Small Update Patch"
Classification="Update"
TargetProductName="$(var.ProductName)"
>
<Media Id="5000" Cabinet="RMT.cab">
<PatchBaseline Id="RTM">
</PatchBaseline>
</Media>
<PatchFamilyRef Id="SamplePatchFamily"/>
</Patch>
<Fragment>
<PatchFamily Id="SamplePatchFamily" Version="$(var.ProductVersion)" Supersede="yes">
<ComponentRef Id="cmp981D9885AA29DD578D66D32ED919EBFB"/>
<ComponentRef Id="cmpD5E6EA59DB565F052E0217CB3248DAE5"/>
</PatchFamily>
</Fragment>
</Wix>
ComponentRef Id's refers to component fragments create by heat.exe harvest of projects mentioned earlier.
Any idea, what could be a problem and why transform doesn't contain any changes?
I think this may be a bug in 3.6. I tried for several hours to get this to work with version 3.6.3303.1, but I always got the PYRO1079 error. I finally downgraded to version 3.5.2519.0, and the error has not reoccurred.
I had to give up my MediaTemplate node and the Directory attribute of my ComponentGroup node after downgrading. I don't know if this was part of the solution or not (i.e. this might have fixed the problem instead of the downgrade).
I am a beginner in Wix and we are trying to migrate from Installshield to Wix. However I am stuck with an error which I am unable to resolve. I have done my share of research online before posting this message and I am hoping to get some help from you experts in case someone had a similar problem and would be kind enough to point out the silly mistake I am making here.
Here is my Wix include file: properties.wxi
<Include>
<?define Language="1033"?>
<?define Manufacturer="ABC Inc"?>
<?define Name="TRIAL-MSI"?>
<?define UpgradeCode="....GUID...."?>
<?define Version="09.00.0021"?>
<?define Comments="Contact: team#abc.com"?>
<?define Description="TRIAL Application"?>
</Include>
And I am calling it in my code as follows:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<?include properties.wxi ?>
<Product Id="*"
Name="${var.Name}"
Language="${var.Language}"
Manufacturer="${var.Manufacturer}"
UpgradeCode="${var.UpgradeCode}"
Version="${var.Version}" >
<Package Comments="${var.Contact}"
Description="${var.Description}"
InstallerVersion="200"
Keywords="Installer,MSI,Database"
Languages="${var.Language}"
Manufacturer="${var.Manufacturer}"
Compressed="yes"
Platform="x86" />
I am compiling my script on the command line:
candle -arch x86 -I properties.wxi trial.wxs
I keep getting errors as follows:
error CNDL0048 : The document element name 'Include' is invalid. A Windows Installer XML source file must use 'Wix' as the document element name.Source trace:
And I guess because Candle did not accept the include file, it throws exception for:
error CNDL0008 : The Product/#Language attribute's value, '${var.Language}', is not a legal integer value.
Could someone please help me with this? Any help is greatly appreciated.
I had this error when migrating wxs files to wxi
Setting the files Build Action property in Visual studio from Compile to Content fixed it.
The -I flag to candle is used to specify a directory to search for include files:
usage: candle.exe [-?] [-nologo] [-out outputFile] sourceFile
[sourceFile ...] [#responseFile]
-I add to include search path
The Wix preprocessor will automatically look in the directory of the current source file for include files so there is no reason to specify the include file on the command line. Your command line should only include the Wix source files:
candle -arch x86 trial.wxs
UPDATE:
Wix variables are inserted using $(var.VARIABLENAME). You have all of your variables surrounded with curly braces instead of parentheses.