Get arguments when using archive type package

[Trenly]

This fixes an issue where default arguments are not being passed to nested installers

Microsoft Reviewers: Open in CodeFlow

[yao-msft]

@Trenly Do you have an example where default args are not passed to installer? From my local testing, args were correctly passed to nested installers (without this change).

[Trenly]

@yao-msft - When running this manifest locally
microsoft/winget-pkgs#87332

[yao-msft]

@yao-msft - When running this manifest locally microsoft/winget-pkgs#87332

Thanks, let me try a repro.

[Trenly]

@yao-msft - When running this manifest locally microsoft/winget-pkgs#87332

Thanks, let me try a repro.

I should still have the logs around from my local tests if they would be helpful

[yao-msft]

Yep, logs should show what args are selected for execution.

[Trenly]

Yep, logs should show what args are selected for execution.

Before PR:
WinGet-2022-11-03-10-03-42.819.log
WinGet-2022-11-03-18-08-32.570.log

Using dev build with PR changes: (Line 61521)
WinGet-2022-11-03-09-58-24.721.log

[yao-msft]

I tried the package (without the change) and cannot repro locally.

I'm not sure what leads to empty installer args with the logs you shared Before PR.

But for the log after the pr, I can see the GetInstallerArgs were called twice (Line 61519 amd Line 61520).

[Trenly]

I tried the package (without the change) and cannot repro locally.

I'm not sure what leads to empty installer args with the logs you shared Before PR.

But for the log after the pr, I can see the GetInstallerArgs were called twice (Line 61519 amd Line 61520).

Interesting, because @SpecterShell was experiencing the same issue I was

[yao-msft]

Interesting, because @SpecterShell was experiencing the same issue I was

Maybe you are using an old version of winget that does not have this fix? #2413

[yao-msft]

The branch is called msiZipBug for #2413, and the description matches exactly what you were experiencing.

[Trenly]

Interesting, because @SpecterShell was experiencing the same issue I was

Maybe you are using an old version of winget that does not have this fix? #2413

Possibly. I thought I tested it with both winget and wingetdev before the change, since I did see that PR earlier. PerhPs I missed somethinf

I agree that it is definitely being called twice though, so this should probably be reverted.