英文:
Wix 4 PackageReference are not resolved to Extensions
问题
The relevant content for translation is as follows:
*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 misunderstood 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:
```xml
<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.0.0\build\..\wixext4\WixToolset.Netfx.wixext.dll
C:\Users\Username\.nuget\packages\wixtoolset.ui.wixext.0.0\build\..\wixext4\WixToolset.UI.wixext.dll
C:\Users\Username\.nuget\packages\wixtoolset.util.wixext.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 Studio22\Enterprise\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets" with target "CollectPackageReferences" from project "C:\Program Files\Microsoft Visual Studio22\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?
<details>
<summary>英文:</summary>
*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:
```xml
<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.0.0\build\..\wixext4\WixToolset.Netfx.wixext.dll
C:\Users\Username\.nuget\packages\wixtoolset.ui.wixext.0.0\build\..\wixext4\WixToolset.UI.wixext.dll
C:\Users\Username\.nuget\packages\wixtoolset.util.wixext.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 Studio22\Enterprise\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets" with target "CollectPackageReferences" from project "C:\Program Files\Microsoft Visual Studio22\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?
答案1
得分: 1
好的，看起来你忘记恢复包了。 dotnet build 默认会这样做，但对于 Framework MSBuild，你需要使用 MSBuild -Restore 或在 MSBuild -t:Build 之前使用单独的 MSBuild -t:Restore。
英文:
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论