Add WiX Toolset build tools to `windows-2022`

[barnson]

Tool name

WiX Toolset

Tool license

MS-RL

Add or update?

• [X] Add
• [ ] Update

Desired version

v3.11.2.4516

Approximate size

120MB

Brief description of tool

About the WiX toolset: The WiX toolset lets developers create installers for Windows Installer, the Windows installation engine.

WiX is available in previous generations of VMs but was not included in windows-2022, presumably because Visual Studio 2022 isn't yet supported by the WiX Visual Studio extension. However, the WiX Visual Studio extension is only used for in-IDE development and isn't needed to build (from the command line or MSBuild).

URL for tool's homepage

https://wixtoolset.org/

Provide a basic test case to validate the tool's functionality.

"%WIX%\bin\candle.exe"

Virtual environments affected

• [ ] Ubuntu 18.04
• [ ] Ubuntu 20.04
• [ ] macOS 10.15
• [ ] macOS 11
• [ ] Windows Server 2016
• [ ] Windows Server 2019
• [X] Windows Server 2022

Can this tool be installed during the build?

No response

Tool installation time in runtime

No response

Are you willing to submit a PR?

Yes

[miketimofeev]

Hi @barnson! Please feel free to submit a PR. Let us know if you need any help with this.

[miketimofeev]

@barnson Thanks for the PR! The changes will be deployed next week.

[barnson]

Thanks!

[NateB2]

We are getting the following error when trying to build one of our Wix projects on a 2022 image we built ourselves using the packer script:

##[error]src\UesClient.Installer.CustomAction\UesClient.Installer.CustomAction.csproj(66,3): Error MSB4019: The imported project "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\WiX\v3.x\Wix.CA.targets" was not found. Confirm that the expression in the Import declaration "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\WiX\v3.x\Wix.CA.targets" is correct, and that the file exists on disk. This error is occurring while using the Visual Studio build task in Azure DevOps to build the solution. It was working fine using the VS 2019 image.

I have verified that the wixtoolset is installed:

[miketimofeev]

@barnson do you know what could be the root cause for @NateB2?

[NateB2]

I found the wix.ca.targets file in the wix toolset's SDK folder, but now it's failing trying to find the wix.targets file, which does not exist in the wix toolset's folder.

[barnson]

WiX installs its targets files to C:\Program Files (x86)\MSBuild and uses MSBuildExtensionsPath32 in the project templates to refer to it. Try creating new projects using the templates available in the VS2022 extension and compare them to your existing projects.

[NateB2]

Yep, that worked, thanks for the help! Our Wix project is super old at this point, so that probably explains the issue.

[PatrickGrub]

@barnson I get the same error see #4573

The line which fails in the project file contains <Import Project="$(WixTargetsPath)" />

So, you say we should change it to <Import Project="$(MSBuildExtensionsPath32)" />

Can you confirm that?

[barnson]

.wixproj files need multiple changes to support isolated MSBuild. The easiest way to fix them is probably to create new .wixproj files from the templates in the Visual Studio extension for VS2019 or VS2022.

[PatrickGrub]

Why happened this regression in the VS2017-Win2016 ?

[NateB2]

@barnson , @PatrickGrub - this is what I had to change in our main .wixproj file to get the project to build on the VS 2022 agents:

[PatrickGrub]

I could solve it by using vm image "windows-latest.

Edit: It was not solved, read https://github.com/actions/virtual-environments/issues/4573#issuecomment-979309550

[svnscha]

@NateB2 this helped for VS 2019 agents, too. Thanks for this.

For anyone else who want copy-paste the changes:

<Import Project="$(WixTargetsPath)" Condition=" '$(WixTargetsPath)' != ''" />
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets" Condition=" '$(WixTargetsPath)' == '' AND Exists('$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets') "/>
  <Target Name="EnsureWixToolsetInstalled" Condition=" '$(WixTargetsImported)' != 'true' ">
     <Error Text="The WiX Toolset v3.11 (or newer) build tools must be installed to build this project. To download the WiX Toolset, see http://wixtoolset.org/releases/" />
  </Target>

[barnson]

Note that removing the WixTargetsPath entries from the PropertyGroup isn't optional. @NateB2's diff screenshot is correct.

[Gallimathias]

For all those for whom the file changes are currently too time-consuming or do not work. You can execute the file that @barnson removed in the ci yourself.

But it may take 20 minutes.

https://github.com/actions/virtual-environments/issues/4582#issuecomment-979324383

[AlmightyFuzz]

@barnson Why was this change also applied to the windows-2019 image if this was only supposed to be applied to the windows-2022 image?

Your changes to the Install-Wix.ps1 script in PR #4448 has removed the the Wix Toolset Studio 2019 Extension from the windows-2019 vm image which appears to be outside the scope of this change.

[barnson]

The Windows version is irrelevant. What matters is the version of Visual Studio. More than 4.5 years ago, we (the WiX team) released support for Visual Studio 2017 and "isolated MSBuild." Doing so required changes in the .wixproj structure, creating "new-style" .wixprojs so we deprecated "old-style" .wixprojs. In Visual Studio 2019, we obsoleted old-style .wixprojs and that obsolescence continues in Visual Studio 2022.

New-style .wixprojs are backward compatible, to at least Visual Studio 2015 (and probably earlier, though I haven't personally tested), and forward compatible, to at least Visual Studio 2022.

The changes required to make an old-style .wixproj a new-style .wixproj are trivial and mechanical.

[KlausLinzner]

Please don't get me wrong - I completely understand that changes can be necessary f.e. switching from windows-2019 to windows-2022 image; this is not a problem as it can be handled via regular change & deployment process to make those changes ahead of time. And while everybody understands that bugs can occur, (intentionally) breaking a released image is a completely different situation;

We ship build pipelines and deployment pipelines to customers - some repos we don't event have access to. At the moment it's a lot of work to update all of our repositories and their branches and to ship emergency fixes to customers.

Once the current situation is dealt with we'll have to answer why we chose a platform that can (intentionally) break at a moment's notice - and we may need to move away from hosted Azure.

[ghelyar]

IMHO the real problem is that without any version number changes, things that have been building for years have stopped working, and can't be fixed without making changes, which indicates a breaking change.

If you have a WiX project that was created a few years ago, but still on the same major version of WiX (3), and it has been successfully building for years, and then suddenly something changes on the build agent, which is still Visual Studio 2019, and it no longer builds.

If it was ".wixproj changes are required to move to WiX 4" or ".wixproj changes are required to move to Visual Studio 2022" then that would be understandable, but it's actually ".wixproj changes are required to move from WiX 3 on Visual Studio 2019 on environment version 20211110.1, to WiX 3 on Visual Studio 2019 on environment version 20211122.1".

I think this is a bug in the 2019 environment, but any attempt anyone has made to talk about 2019 has been closed and redirected here.

[MikeAtETI]

We've also been stung by this change to the VS2019 based images - and while the changes at https://github.com/actions/virtual-environments/issues/4419#issuecomment-976961106 aren't difficult its something the tooling in VS should have picked up and suggested a long time ago if it was going to be needed.

To us it is a breaking change in the images that they no longer support this.

[chrpai]

@dibir-magomedsaygitov I don't see how this is a dupe. All those comments over there should be over here. A change to add Votitve to VS2022 shouldn't break VS2019.

Reading through the image readme.md file I can see the components are no longer installed. This was never announced and is a regression. Every single customer who builds WiX is going to be affected and it's not right to say they need to update all their import statements to keep building when it was building before.

[dibir-magomedsaygitov]

@chrpai we are in progress of reverting our recent changes. The PR has been prepared.

[chrpai]

@chrpai we are in progress of reverting our recent changes. The PR has been prepared.

Is there a way in the pipeline to specify the image version to be used? I'm looking but don't see it. Maybe I'm blind.

[dibir-magomedsaygitov]

@chrpai you can't specify image version unfortunately

[chrpai]

@chrpai you can't specify image version unfortunately

Rats. Is there an ETA on when the new image will be deployed? I'm a WiX / Azure DevOps consultant and my inbox is being lit up by customers with broken builds.

[dibir-magomedsaygitov]

@chrpai the new images should be available by Thursday next week. We will post an update message.

[chrpai]

For a quick workaround add this powershell to your VS2019 builds. The code is simplified snippets taken from InstallHelpers.ps1 and Install-Wix.ps1, The dependency on the toolset.json is removed and hardcoded to Enterprise edition.

function Start-DownloadWithRetry { Param ( [Parameter(Mandatory)] [string] $Url, [string] $Name, [string] $DownloadPath = "${env:Temp}", [int] $Retries = 20 )

if ([String]::IsNullOrEmpty($Name)) {
    $Name = [IO.Path]::GetFileName($Url)
}

$filePath = Join-Path -Path $DownloadPath -ChildPath $Name
$downloadStartTime = Get-Date

# Default retry logic for the package.
while ($Retries -gt 0)
{
    try
    {
        $downloadAttemptStartTime = Get-Date
        Write-Host "Downloading package from: $Url to path $filePath ."
        (New-Object System.Net.WebClient).DownloadFile($Url, $filePath)
        break
    }
    catch
    {
        $failTime = [math]::Round(($(Get-Date) - $downloadStartTime).TotalSeconds, 2)
        $attemptTime = [math]::Round(($(Get-Date) - $downloadAttemptStartTime).TotalSeconds, 2)
        Write-Host "There is an error encounterd after $attemptTime seconds during package downloading:`n $_"
        $Retries--

        if ($Retries -eq 0)
        {
            Write-Host "File can't be downloaded. Please try later or check that file exists by url: $Url"
            Write-Host "Total time elapsed $failTime"
            exit 1
        }

        Write-Host "Waiting 30 seconds before retrying. Retries left: $Retries"
        Start-Sleep -Seconds 30
    }
}

$downloadCompleteTime = [math]::Round(($(Get-Date) - $downloadStartTime).TotalSeconds, 2)
Write-Host "Package downloaded successfully in $downloadCompleteTime seconds"
return $filePath

}

function Install-VsixExtension { Param ( [string] $Url, [Parameter(Mandatory = $true)] [string] $Name, [string] $FilePath, [Parameter(Mandatory = $true)] [string] $VSversion, [int] $retries = 20, [switch] $InstallOnly )

if (-not $InstallOnly)
    {
        $FilePath = Start-DownloadWithRetry -Url $Url -Name $Name
    }

$argumentList = ('/quiet', "`"$FilePath`"")

Write-Host "Starting Install $Name..."
$vsEdition = "Enterprise"
try
{
    #There are 2 types of packages at the moment - exe and vsix
    if ($Name -match "vsix")
    {
        $process = Start-Process -FilePath "C:\Program Files (x86)\Microsoft Visual Studio\$VSversion\${vsEdition}\Common7\IDE\VSIXInstaller.exe" -ArgumentList $argumentList -Wait -PassThru
    }
    else
    {
        $process = Start-Process -FilePath ${env:Temp}\$Name /Q -Wait -PassThru
    }
}
catch
{
    Write-Host "There is an error during $Name installation"
    $_
    exit 1
}

$exitCode = $process.ExitCode

if ($exitCode -eq 0 -or $exitCode -eq 1001) # 1001 means the extension is already installed
{
    Write-Host "$Name installed successfully"
}
else
{
    Write-Host "Unsuccessful exit code returned by the installation process: $exitCode."
    exit 1
}

#Cleanup downloaded installation files
if (-not $InstallOnly)
    {
        Remove-Item -Force -Confirm:$false $FilePath
    }

}

Install-VsixExtension -Url https://wixtoolset.gallerycdn.vsassets.io/extensions/wixtoolset/wixtoolsetvisualstudio2019extension/1.0.0.4/1563296438961/Votive2019.vsix -Name Votive2019.vsix -VSversion 2019

[MaksimZhukov]

Hello everyone! We are sorry for the inconvenience!

We have reverted changes for Windows 2016 and 2019. The pull request has been merged. We will rollout images next week.

Thank you for the patience!

[VonOgre]

Based on https://github.com/actions/virtual-environments/commit/446bf8d222493ea5c155c47024263a72f3aa87dc#diff-816219d3c9f30fcc1c40f88ca826c1662bf99eded781c1b419dd2dfb577ae227L480-L481 and behavior I noted in my builds this morning, WiX was removed entirely from the windows-2019 image

[nikolai-frolov]

@VonOgre WiX toolset is located under Tools now: https://github.com/actions/virtual-environments/blob/446bf8d222493ea5c155c47024263a72f3aa87dc/images/win/Windows2019-Readme.md?plain=1#L88

[MPasadu]

Does this mean the issue with 2019 missing wix toolset will also be resolved soon without the need of user action - so pipelines will work again? Or must we implement the suggested fix posted above regarding the .wixproj files?

[robmen]

@MPasadu, you will want to apply those changes to your .wixproj in all cases. Future updates to the tooling will (eventually) deprecate the current syntax.

[dibir-magomedsaygitov]

Hello everyone! The new Windows2016 and Winndows2019 images should be available now. Thank you for the patience.

[chrpai]

@dibir-magomedsaygitov Thank you! I can confirm that my pipelines are green after disabling my Install Votive 2019 build step.

[sportbilly21]

@dibir-magomedsaygitov I am still getting an error regarding the wix Toolset is not installed. VmImage 'windows-2019' Please see below error from pipelines.

============================================================================== "C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/MSBuild/Current/Bin/msbuild.exe" /version /nologo Active code page: 65001 Detected NuGet version 6.0.0.280 / ... ...error : The WiX Toolset v3.11 build tools must be installed to build this project. To download the WiX Toolset, see http://wixtoolset.org/releases/ NuGet Version: 6.0.0.280 MSBuild auto-detection: using msbuild version '16.11.2.50704' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\bin'.

[sportbilly21]

Update: Pipeline is working OK for me now. I had done the changes suggested in the wix project file and I had removed the lines below: ` Package

$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets

<WixTargetsPath Condition=" '$(WixTargetsPath)' == '' ">$(MSBuildExtensionsPath)\Microsoft\WiX\v3.x\Wix.targets</WixTargetsPath>`

I have put them back in and now it is working OK

[MaksimZhukov]

Windows images were deployed. I'm going to close the issue, please feel free to contact us if you have any concerns. Thank you!

[chrpai]

Windows images were deployed. I'm going to close the issue, please feel free to contact us if you have any concerns. Thank you!

@MaksimZhukov Thanks for fixing VS2019. Where does this leave VS2022? Does it have WiX or not yet? If not yet do we have an ETA?

[nikolai-frolov]

@chrpai installation was fixed for Windows 2016 and 2019. Windows 2022 has a WiX toolset installed as well (https://github.com/actions/virtual-environments/blob/050efaf52a756ad291fd5e0d5923d07e913bc34c/images/win/Windows2022-Readme.md?plain=1#L82).

[SenthilSelvaraju]

Can the the windows Images be updated to use wix v3.14?

To support .net framework 4.8 capabilities, we need wix 3.14. => https://wixtoolset.org/releases/v3-14-0-712/

it doesn't look like windows-2022 have wix 3.14, which is preventing us from using Azure hosted agents.

[miketimofeev]

@gep13 👋is it possible to update https://community.chocolatey.org/packages/wixtoolset package to WiX 3.14 per @SenthilSelvaraju request?

[gep13]

@miketimofeev I can certainly add it to my list of things to do, however, I can't commit to exactly when that might be.

[gep13]

@miketimofeev actually, looking at the release page, it would seem that the latest production releases are already available:

https://wixtoolset.org/releases/

@robmen can you confirm if the production releases have changed?

[robmen]

The production releases have not changed. We are totally focused on a WiX v4 release by the end of the year.

[SenthilSelvaraju]

We are using private agents as a work around. Do you mind sending an update in this thread when Wix v4 is available in windows images?

Thanks.

[robmen]

One of the huge changes in WiX v4 is that we've done (a lot of) work so that the WiX Toolset is easily installable without out having to be built into the many, many various CI virtual environments. For example, when using a .wixproj in v4, running msbuild -Restore will bring down the WiX Toolset and build the project in one go.

Our (obvious) goal is to make it trivial to use whichever revision of WiX v4 you want without needing an update from the CI provider.

[SenthilSelvaraju]

That's exciting.!!! Thanks for the brief into the upcoming release. I appreciate it.

I am looking forward to the release of Wix v4.