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
path
passed to the ResourceLib is path to the ZIP archive ending in.zip
and 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 -i
wingetcreate update aluxnimm.outlookcaldavsynchronizer -v 18.0 -i
wingetcreate update Hugo.Hugo -v 18.0 -i
wingetcreate update Istio.Istio -v 18.0 -i
Expected 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