I've inherited a Wix project. I don't know how it was compiled before, all I have are the source .wxs and .wxi files. I'm using candle and light from the command line to compile and link.
So far, I can candle my wxs files to wixobj files without error, however when I try and run light, I get a lot of errors similar to:
C:\wix\FeatureTree.wxs(39) : error LGHT0094 : Unresolved reference
to symbol 'Dialog:ErrorDlg' in
section 'Fragment:'.
I've done some reading, and it seems that the line that's causing this error:
<DialogRef Id="ErrorDlg" />
I've got the following line at the top of the Fragment:
<UIRef Id="WixUI_Common" />
Is just trying to import a built-in Wix error dialog. Why is it failing?
I was missing the library from the light command, which needs to be specified with -ext:
light -ext WixUIExtension *.wixobj -o installer.msi
Or from Visual Studio Wix project, add a reference to WixUIExtension.dll
Related
I am using a WIX installer that is showing some brackets in the status line (see image below):
I haven't made changes to the WIX file, but only the installed files have changed. I did update WIX to v3.11, because this was required to use WIX in Visual Studio 2017. We use the standard WixUI.
These strings are listed in the C:\Program Files (x86)\WiX Toolset v3.11\SDK\wixui\WixUI_en-us.wxl file. A few lines from this file:
<String Id="ProgressTextRemoveFiles" Overridable="yes"><!-- _locID_text="ProgressTextRemoveFiles" _locComment="ProgressTextRemoveFiles" -->Removing files</String>
<String Id="ProgressTextRemoveFilesTemplate" Overridable="yes"><!-- _locID_text="ProgressTextRemoveFilesTemplate" _locComment="ProgressTextRemoveFilesTemplate" -->File: [1], Directory: [9]</String>
These strings exactly match what I see during installation. It seems only the ProgressDlg has this issue, but maybe other strings don't use expansion. Anyone has a clue?
Try to add the following line in your main wxs:
<UIRef Id="WixUI_ErrorProgressText" />
See my answer for the same question.
i am using wix from command line. the problem i am facing is that i don't know how i will load the WixUtilExtension.dll at link time.
currently i am using the following commands
candle install.wxs
and then
light -ext WixUtilExtension install.wixobj
but it gives me following error
Unresolved reference to symbol 'WixUI:WixUI_InstallDir in section product
the dll is located at C:\Program Files (x86)\WiX Toolset v3.7\bin and my files are in folder which is at Desktop
can some body help me in resolving this?
thanks
You are linking WixUtilExtension, but the WixUI_InstallDir is a part of WixUIExtension. Seems like a pure typo.
I am using NUGET Pack in teamcity to build a package. But it is creating the following error. I am using nuget teamcity version 2.2.1.
Step 2/2: Build Package (NuGet Pack) (14s)
[12:10:40][Step 2/2] Cleaning Z:\hgbuilds\IT\Build\packages
[12:10:40][Step 2/2] pack: Create NuGet package from UI\UI.Tour\UI.Tour.Web\UI.Tour.Web.csproj (14s)
[12:10:40][pack] NuGet command: C:\BuildAgent\tools\NuGet.CommandLine.2.2.1.nupkg\tools\NuGet.exe pack Z:\hgbuilds\IT\UI\UI.Tour\UI.Tour.Web\Calrom.UI.InclusiveTour.Web.csproj -OutputDirectory Z:\hgbuilds\IT\Build\packages -BasePath Z:\hgbuilds\IT -Verbose -Version 1.0.0.7 -Symbols -Properties Configuration=Deploy-Test
[12:10:40][pack] Starting: C:\BuildAgent\temp\agentTmp\custom_script2086270793558421822.cmd
[12:10:40][pack] in directory: Z:\hgbuilds\IT
[12:10:45][pack] WARNING: Option 'Verbose' has been deprecated. Use 'Verbosity' instead.
[12:10:45][pack] Attempting to build package from 'UI.Tour.Web.csproj'.
[12:10:45][pack] Packing files from 'Z:\hgbuilds\IT\UI\UI.Tour\UI.Tour.Web\bin'.
[12:10:46][pack] WARNING: Description was not specified. Using 'Description'.
[12:10:48][pack] content
[12:10:54][pack] Cannot add part for the specified URI because it is already in the package.
[12:10:54][pack] Process exited with code 1
[12:10:54][Step 2/2] Step Build Package (NuGet Pack) failed
Please guide what I am missing here.
I had the same error but there were no issues in the csproj file. I was using typescript and was accidentally checking in the .js files. So at run-time another js file was being generated, thus there were two of each js files being added.
I found it by going through the team city build log and looking for duplicates. As they were "do not copy" there was no issue with a simple msbuild but as we just switched to using Octopack, cannot add multiple when nugeting a solution.....
You can find the culprit (typescript or otherwise) as it will be the first to appear after the "attempting to create line" (there could be many but finding them on at a time could be easier than doing it manually)
Edit the project file and make sure you do not have duplicate Reference Incudes or duplicate Content Includes. My issue was I had...
<Reference Include="SCS.PickList, Version=1.7.0.0, Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>Bin\SCS.PickList.dll</HintPath>
</Reference>
AND
<Content Include="Bin\SCS.PickList.dll" />
Once I removed the Content include it worked.
One possible problem could be that Octopack is actually case sensitive. In my case VS Project had reference to the file with name in lower case letters
such as this
In my .nuspec file I had the lines equivalent to:
<file src="Source\MyCompany.ProjectA\**\*.cs" target="src" />
<file src="Source\MyCompany.ProjectB\**\*.cs" target="src" />
I got the error due to the AssemblyInfo.cs file being in both projects.
(This was to enable the creation of a NuGet Symbol Package.)
For me, it was because my files didn't have extensions.
<file src=".\LICENSE" target="" />
<file src=".\NOTICE" target="" />
My solution was to add a wildcard to the end of the file:
<file src=".\LICENSE*" target="" />
<file src=".\NOTICE*" target="" />
In your nuspec file do you have a file node specified?
<files>
<file src="the_dll_for_your_csproj"/>
</files>
If so, is it possible that you have included (either explicitly or by wildcard) the dll for the csproj you are trying to build?
I am totally new to WiX, so of course my first task with WiX is to migrate an existing large installation program from WiX 2 to WiX 3. I've had a number of wrinkles most of which have been sorted, but I would be grateful for some suggestions with the following light errors. Since I am new to WiX, I want to list my whole process:
To create a WiX library:
candle.exe *.wxs
lit.exe -out "wixui_company.wixlib" *.wixobj
To generate the main MSI:
candle.exe main.wxs -o main.wixobj
light.exe main.wixobj -o Main_Installer.msi wixui_company.wixlib -ext WixUIExtension
This last command gives dozens and dozens of errors, but they all take the following form
error LGHT0091 : Duplicate symbol 'Dialog:LicenseAgreementDlg' found.
I have grep and re-greped, but the only references are the following:
In LicenseAgreementDlg.wxs:
<Fragment>
<UI>
<Dialog Id="LicenseAgreementDlg" ...
And in wixui_company.wxs
<Fragment>
<UI Id="WixUI">
<DialogRef Id="LicenseAgreementDlg" />
...
<Property Id="WixUI_WelcomeDlg_Next" Value="LicenseAgreementDlg" />
It is the DialogRef line that gives the error.
These both get referenced from wixui_company.wixlib in the main.wxs:
<UIRef Id="WixUI" />
FWIW, if I change either the ref to WixUI or the ref to LicenseAgreementDlg, duplicate errors go away, but instead I get symbol not found link errors. I migrated the original wxs files using WixCop, but under WiX 2 they all worked as is. I am guessing that this has to do with the move to put WiXUI in it's own namespace in WiX 3, but frankly I have no idea what to even try.
Any ideas on where things went horribly wrong?
Thanks,
Adam
"LicenseAgreementDlg" is the name of a dialog in the WixUIExtension that you're linking to with light.exe. Every dialog in an MSI database must have a unique identifier, so it's likely you've made a <UIRef> element to one of the standard WiX UIs ("WixUI_FeatureTree", "WixUI_Mondo", etc.), which includes WiX's LicenseAgreeementDlg dialog. You're then referencing your own LicenseAgreementDlg, so now you have two dialogs with the same name.
In this situation, you'd need to either rename your own LicenseAgreementDlg or remove it altogether and use the built-in one.
I've got a WiX installer project which uses MSBuild to generate the MSI file. The WXS file includes the WiX firewall extension:
xmlns:fire="http://schemas.microsoft.com/wix/FirewallExtension"
I've defined two cultures in the MSBuild file with the following definition:
<PropertyGroup>
...
<Cultures>en-us;no-no</Cultures>
</PropertyGroup>
I've also added the translated resources:
<ItemGroup>
<EmbeddedResource Include="lang\Firewall_no-no.wxl" />
<EmbeddedResource Include="lang\WixUI_no-no.wxl" />
</ItemGroup>
These represents translation to Norwegian for the Firewall extension and the WixUI extension. When I run the build it succeeds with the en-us part, but the no-no part fails with the following error messages:
C:\delivery\Dev\wix30_public\src\ext\FirewallExtension\wixlib\FirewallExtension.wxs(19):
error LGHT0102: The localization variable !(loc.WixSchedFirewallExceptionsInstall)
is unknown. Please ensure the variable is defined.
....
Couple of issues: I don't know where the C:\delivery directory comes from. I don't have such a directory. The localization variables referenced in the error message have been translated in the Firewall_no-no.wxl file.
When I run MSBuild with more detailed information I see the following output right before the error message:
Task "Light"
Command:
C:\Program Files (x86)\Windows Installer XML v3\bin\Light.exe -cultures:no-no
-ext "C:\Program Files (x86)\Windows Installer XML v3\bin\WixUIExtension.dll"
-ext "C:\Program Files (x86)\Windows I nstaller XML v3\bin\WixUtilExtension.dll"
-ext "C:\Program Files (x86)\Windows Installer XML v3\bin\WixFirewallExtension.dll"
-loc lang\Firewall_no-no.wxl -loc lang\WixUI_no-no.wxl
-out F:\Projects\MyProd\MyProj\Installer\bin\Debug\no-no\MyInstaller.msi
-pdbout F:\Projects\MyProd\MyProj\Installer\bin\Debug\no-no\MyInstaller.wixpdb
obj\Debug\MyProj.wixobj
As the details show, the MSBuild task results in having two -loc parameters to the Light executable. Not sure if that would be the reason for this problem. Any ideas on how to solve this?
It seems that the reason for this error was very simple. I got the exception because I hadn't changed the Culture="no-no" attribute in the WixLocalization tag. Setting this value made the errors disappear.