CODEWITHSUNDEEP
wixwix4
Anders Forsgren
Anders Forsgren

Reputation: 11111

Wix 4 PackageReference are not resolved to Extensions

EDIT: This was resolved by using "dotnet build [wixproj]" instead of msbuild, but I'll leave the question here for while because I'm curious if I have misunerstood something with how this is supposed to work. I didn't think HeatWave would come into play for a command line msbuild.

I have a wix 4 project with the following section of package references to extensions:

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

I'm not 100% familiar with how this works under the hood, but when I build this using msbuild /t:Restore;Build myproject.wixproj on my local machine, the PackageReferences are gathered in the @(Extensions) msbuild item list, and finally sent as arguments to wix build -ext [extensionpath]. This works perfectly and is certainly a step up from the way Wix3 worked.

relevant parts of the working build log include e.g. the Extensions item:

WixExtension
    C:\Users\Username\.nuget\packages\wixtoolset.netfx.wixext\4.0.0\build\..\wixext4\WixToolset.Netfx.wixext.dll
    C:\Users\Username\.nuget\packages\wixtoolset.ui.wixext\4.0.0\build\..\wixext4\WixToolset.UI.wixext.dll
    C:\Users\Username\.nuget\packages\wixtoolset.util.wixext\4.0.0\build\..\wixext4\WixToolset.Util.wixext.dll

However, when I try to do this on a different machine (A build server), there are no @(Extensions) when it reaches the build step. The @(WixExtension) items are never populated. Relevant log

Target "ResolveWixExtensionReferences" skipped, due to false condition; ( '@(WixExtension)' != '') was evaluated as ( '' != '').

Consequently the build will fail because the extension is not available, for example

Error WIX0200: The File element contains an unhandled extension element 'NativeImage'. Please ensure that the extension for elements in the 'http://wixtoolset.org/schemas/v4/wxs/netfx' namespace has been provided

When trying to debug this I notice this in the log from the working build: it uses a different method of collecting the package references, which seems to come from an msbuild extension added by the HeatWave VS plugin. But this plugin isn't available on the build server, so nor is this message in the log. It uses the default CollectPackageReferences target from msbuild there.

Overriding target "CollectPackageReferences" in project "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets" with target "CollectPackageReferences" from project "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\FireGiant\HeatWave\FireGiant.HeatWave.PackageDependencyResolution.targets".

I'm not sure I understand this correctly: but shouldn't I be able to build with extensions on a machine without having HeatWave? Is the build relying on msbuild extensions and not merely the Wix4 Sdk itself? Do I need to add a reference to WixToolset.Heat to the wixproj to make it work on build servers, even though there is no actual harvesting used?

Upvotes: 0

Views: 1813

Answers (1)

Bob Arnson
Bob Arnson

Reputation: 21896

It sounds like you forgot to restore packages. dotnet build does so by default but for Framework MSBuild, you need to use MSBuild -Restore or a separate MSBuild -t:Restore before MSBuild -t:Build.

Upvotes: 1

Related Questions