Wix 4.0 error WIX0200: The UI element contains an unhandled extension element 'Dialog'

[dd-mozdemir]

I have a WiX Project I was trying to experiment converting over to WiX 4.0 and I have gotten past some of the issues but this one stumped me for a while and I can't seem to figure out why it's happening.

I have a source.wxs file where I'm referencing a custom dialog <?include ...\assets\configdlg.wxi ?> and the contents look something like this:

<Include>
  <Dialog Id="ConfigDlg" Width="370" Height="270" Title="!(loc.ConfigDlgTitle)">
... More code here
  </Dialog>
</Include>

When I run:

wix build source.wxs -ext WixToolset.Bal.wixext.dll -ext WixToolset.Util.wixext.dll -ext WixToolset.Firewall.wixext.dll -ext WixToolset.UI.wixext.dll

I get:

error WIX0200: The UI element contains an unhandled extension element 'Dialog'. Please ensure that the extension for elements in the '' namespace has been provided.

Any clues as to why this is happening? Thanks!!

[rseanhall]

Have you been running wix convert on your source files? The Include element now requires the namespace declaration like the other root elements. The convert command should have fixed that, see the Include converter test.

[dd-mozdemir]

Thanks @rseanhall. The converter actually didn't do anything for my include files until I added <Include xmlns="http://wixtoolset.org/schemas/v4/wxs"> now they are converted.

[robmen]

Tracking the lack of error message about xmlns in #6639

[jcrawfor74]

I ran into the same error when attempting to run a wix build with UI features, this post helped solve the mystery for me..

Note: the -ext build switch is not documented in the help output
wix build -h

Also when accessing the wix extension like so in my wix project ..

<PackageReference Include="WixToolset.UI.wixext" Version="4.0.0" />

The dll is installed in the following location..
%USERPROFILE%\.nuget\packages\wixtoolset.ui.wixext\4.0.0\wixext4\WixToolset.UI.wixext.dll

and the .dll is not copied locally during the build process so the following command will not work,

wix build Package.wxs -ext WixToolset.UI.wixext.dll

I am having to either create a local copy of the .dll or reference the nuget location?

Should the .dll be copied into the bin directory such and referenced without the need for the -ext switch?

[jcrawfor74]

This is a follow up with a sample of what I ended up coming up with. This script is a powershell script that lives in a "deploy" folder in my wix project, and is building the msi, 3 or 4 folders higher into a "Published" folder..

this is called like
.\publish.ps1 Release x64

It runs an MSBuild of the projects that are referenced in the Wix Installer for the requested configuration and platform and then runs a wix build

[CmdletBinding()]
param(
    [Parameter(Position=0,mandatory=$true)]
    [string] $configuration,
    [Parameter(Position=1,mandatory=$true)]
    [string] $platform
) #end param

if($configuration -eq "") {
    write-host "ERROR - missing mandatory parameter - configuration ";
    exit 1
}

if($platform -eq "") {
    write-host "ERROR - missing mandatory parameter - configuration ";
    exit 1
}
    
if($configuration -ne "Debug" -and $configuration -ne "debug" -and 
    $configuration -ne "Release" -and $configuration -ne "release") {
    write-host "ERROR - invalid configuration parameter - valid values - debug or release"
    exit 1
}

if($platform -ne "x86" -and $platform -ne "x64") {
    write-host "ERROR - invalid platform parameter - valid values - x86 or x64 and $platform entered"
    exit 1
}

$platformTarget = $platform
$msiExtension = ""
$libraryPath = $configuration
if($platform -eq "x64"){
    $platformTarget="AnyCpu"
    $msiExtension="-x64"
} else  {
    $libraryPath = "$platform\$configuration"
}

# move back one directory
cd ..
New-Item -ItemType Directory -Force -Path "..\..\..\..\published" | Out-Null

#Build the project
MSBuild.exe ..\..\Client\MyApp.Client.csproj /p:Configuration=$configuration /property:Platform=$platformTarget
MSBuild.exe ..\..\Server\MyApp.Server.csproj /p:Configuration=$configuration /property:Platform=$platformTarget
MSBuild.exe ..\..\UI\MyApp.UI.csproj /p:Configuration=$configuration /property:Platform=$platformTarget

Write-Host Building Wix Installation Package - $platform

# get the base path to reference the nuget package
$nugetBasePath = "$env:USERPROFILE\.nuget\packages"

wix build "Package.wxs" -loc "Package.en-us.wxl" -o "..\..\..\..\published\My.App.Suite$msiExtension.msi" -src "Srt*.wxs" -src "Folders.wxs" -arch $platform `
                            -ext "$nugetBasePath\wixtoolset.ui.wixext\4.0.1\wixext4\WixToolset.UI.wixext.dll" `
                            -b "..\..\Client\bin\$libraryPath" -b "..\..\Client\ConfigurationFiles" `
                            -b "..\..\Server\bin\$libraryPath" -b "..\..\Server\ConfigurationFiles" `
                            -b "..\..\UI\bin\$libraryPath"

Write-Host My.App.Suite$msiExtension.msi created in the published folder - $platform

del ..\..\..\..\published\*.wixpdb

# move back to the directory I started in
cd deploy

[robmen]

Why wix build instead of using a .wixproj? You're already using MSBuild and a .wixproj with correct project references would allow you to do things like parallel build and abort on failure. This looks like a lot of work to recreate what a .wixproj would give you.

[hollowaykeanho]

@robmen , Hi, can the wix build be properly documented for the UI section please? I'm actually developing the headless CI automation and wix4 had been blocking for quick at least 4 weeks from today and counting now.. 200+ failure.

headless CI is important for automation and MSI packaging is also essentials for Windows distributions. This link: https://wixtoolset.org/docs/tools/wixext/ makes zero sense after >50 retries.

Reference:

1. https://github.com/corygalyna/AutomataCI/actions/workflows/git-push.yml

[jcrawfor74]

Sorry for the slow response, I suppose the reason that I never used msbuild on the .wixproj file is that I never knew you could!! Some of the documentation around using Wix is a bit hit and miss and it is a bit hard to find how to do things, so when looking to build all I could find was the wix build action which I made work.

Now attempting to use msbuild the question I wanted to ask and have answered myself was "Where does the msi get built?"
It ends up in a subdirectory of bin with .\en-US - see my script below..

So for anyone else who finds this I have the following script assuming you have two variables:

• $platform - Debug or Release
• $configuration - x86 or x64

Write-Host Building Wix Installation Package - $configuration - $platform

msbuild .\MyApplication.wixproj /p:Configuration=$configuration /property:Platform=$platformTarget

Write-Host Copy Msi
copy .\bin\$platformTarget\$configuration\en-US\*.msi "..\..\..\..\published\"

where I am copying the built .msi from the bin directory to a sub... directory called published which is higher up in my directory structure.

yes this approach is heaps easier and less work, and will also make the development of my CI/CD pipeline code much simpler where I am currently having to manually build each individual project prior to packaging so the .dlls etc are available to package.
Thanks @robmen

[robmen]

The Get started with WiX page of the documentation, the very first page of the documentation, spells out that you can use MSBuild and has a link to the MSBuild documentation. I highly recommend reading all of that if you're new to this world of building software from the command-line.

If you'd rather watch videos, then I also recommend my Deployment Dojo which currently has 54 episodes. I'm confident you'll learn a lot, including how to build from the command-line in various ways.

[barnson]

https://wixtoolset.org/docs/tools/wixext/

[MoonLigh1]

@robmen I can't build my wix pojects that were created in visual studio using heatwave using msbuild from jenkins, it gives me the follow error.

C:\Autosphere DevOps\MSI\Wix\Autosphere Orchestrator bundle\Bundle.wxs(7): error WIX0200: The BootstrapperApplication element contains an unhandled extension element 'WixStandardBootstrapperApplication'. Please ensure that the extension for elements in the 'http://wixtoolset.org/schemas/v4/wxs/bal' namespace has been provided. [C:\Autosphere DevOps\MSI\Wix\Autosphere Orchestrator bundle\Autosphere Orchestrator bundle.wixproj] C:\Autosphere DevOps\MSI\Wix\Autosphere Orchestrator bundle\Bundle.wxs(13): error WIX0200: The Bundle element contains an unhandled extension element 'RegistrySearchRef'. Please ensure that the extension for elements in the 'http://wixtoolset.org/schemas/v4/wxs/util' namespace has been provided. [C:\Autosphere DevOps\MSI\Wix\Autosphere Orchestrator bundle\Autosphere Orchestrator bundle.wixproj] C:\Autosphere DevOps\MSI\Wix\Autosphere Orchestrator bundle\Bundle.wxs(14): error WIX0200: The Bundle element contains an unhandled extension element 'RegistrySearchRef'. Please ensure that the extension for elements in the 'http://wixtoolset.org/schemas/v4/wxs/util' namespace has been provided. [C:\Autosphere DevOps\MSI\Wix\Autosphere Orchestrator bundle\Autosphere Orchestrator bundle.wixproj] C:\Autosphere DevOps\MSI\Wix\Autosphere Orchestrator bundle\Bundle.wxs(28): error WIX0200: The Fragment element contains an unhandled extension element 'RegistrySearch'. Please ensure that the extension for elements in the 'http://wixtoolset.org/schemas/v4/wxs/util' namespace has been provided. [C:\Autosphere DevOps\MSI\Wix\Autosphere Orchestrator bundle\Autosphere Orchestrator bundle.wixproj] C:\Autosphere DevOps\MSI\Wix\Autosphere Orchestrator bundle\Bundle.wxs(29): error WIX0200: The Fragment element contains an unhandled extension element 'RegistrySearch'. Please ensure that the extension for elements in the 'http://wixtoolset.org/schemas/v4/wxs/util' namespace has been provided. [C:\Autosphere DevOps\MSI\Wix\Autosphere Orchestrator bundle\Autosphere Orchestrator bundle.wixproj] Done Building Project "C:\Autosphere DevOps\MSI\Wix\Autosphere Orchestrator bundle\Autosphere Orchestrator bundle.wixproj" (Rebuild target(s)) -- FAILED. Done Building Project "C:\Autosphere DevOps\MSI\Wix\Autosphere Orchestrator bundle\Autosphere Orchestrator.sln" (rebuild target(s)) -- FAILED.

These schemas have been already added in the tag in my bundle project
<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs" xmlns:bal="http://wixtoolset.org/schemas/v4/wxs/bal" xmlns:util="http://wixtoolset.org/schemas/v4/wxs/util">

[MoonLigh1]

the build works find when build directly from visual studio, or if I call msbuild directly from command line, on jenkins I have provided the same path to the msbuild plugin that I used locally to build the project but I get the above error.

[robmen]

You do not provide enough information to really diagnose what is going wrong, but my hypothesis is you need to do restore on your CI system.

VS+HeatWave do a restore for you automatically on project open.

msbuild -Restore will restore and build in one go.

[MoonLigh1]

@robmen okay so I was working with this problem and it turned out to be a locality problem, the build agent that I was using to build this specific job was jenkins master on local windows but When I created a slave a agent on the same machine and made sure that I executed the agent connection jar from the same user the msbuild jobs executed just fine given that I provided the exact path of msbuild directly to the job and ensured that the job runs on the slave agent that I created.

This is still weird though, and If I remove the usage of these two extensions (bal (Registry search and util (ui related stuff)) the build works just fine from any agent local or remote, still very confusing.

Though I will test the restore thing and se what happens.