This uses the Vestris.ResourceLib to parse the installer and retrieve its InstallerType. For zip installers in interactive updates, this seem to throw a Win32 Exception and interactive update returns Failed to parse the package from [<InstallerUrl>] at:
Brief description of your issue
Interactive update uses a call to
ParsePackageAndUpdateInstallerNode()to Parse the InstallerType of an installer.https://github.com/microsoft/winget-create/blob/5ec4ad62c6434934c3d630d589bf9c2bf767e264/src/WingetCreateCLI/Commands/UpdateCommand.cs#L724
This uses the Vestris.ResourceLib to parse the installer and retrieve its InstallerType. For zip installers in interactive updates, this seem to throw a Win32 Exception and interactive update returns
Failed to parse the package from [<InstallerUrl>]at:https://github.com/microsoft/winget-create/blob/5ec4ad62c6434934c3d630d589bf9c2bf767e264/src/WingetCreateCore/Common/PackageParser.cs#L703-L710
which is called from: https://github.com/microsoft/winget-create/blob/5ec4ad62c6434934c3d630d589bf9c2bf767e264/src/WingetCreateCore/Common/PackageParser.cs#L283-L285
This is because the
pathpassed to the ResourceLib is path to the ZIP archive ending in.zipand not the actual installer present in the archive.Steps to reproduce
Unattended update: (Dummy version used to simulate update)
Notice they all succeed in autonomous update. Now try the same packages in interactive update i.e.,
wingetcreate update Guru3D.Afterburner -v 18.0 -iwingetcreate update aluxnimm.outlookcaldavsynchronizer -v 18.0 -iwingetcreate update Hugo.Hugo -v 18.0 -iwingetcreate update Istio.Istio -v 18.0 -iExpected behavior
Interactive update should succeed like the autonomous ones
Actual behavior
Interactive updates gives
Failed to parse the package from [<InstallerUrl>]after downloading the package from URL.Environment