Fix Repair-WinGetPackageManager cmdlet by retrieving dependencies from GitHub assets #4923
Conversation
There was a problem hiding this comment.
This design requires that both the json and archive files be present to operate. The initial design I communicated did not. It wouldn't take much change here to realign.
Some of my comments already indicate how to verify with only the json present, although that particular scenario isn't very useful.
What we may find more useful would be functioning (albeit inefficiently) if the json file is missing or corrupted. That would require:
- Placing the dependencies in the archive in architecture directories
- Changing the format string to mirror this
- Implementing a code path that installs all packages found in all appropriate architectures when we failed to find or parse the json
I think it at least worth doing 1 and 2, as they require very little change. 3 can be done at some future point if we want, but without having done 1 or 2 now it wouldn't work for archives we make now.
src/PowerShell/Microsoft.WinGet.Client.Engine/Helpers/AppxModuleHelper.cs
Outdated
Show resolved
Hide resolved
src/PowerShell/Microsoft.WinGet.Client.Engine/Helpers/AppxModuleHelper.cs
Outdated
Show resolved
Hide resolved
src/PowerShell/Microsoft.WinGet.Client.Engine/Helpers/AppxModuleHelper.cs
Outdated
Show resolved
Hide resolved
src/PowerShell/Microsoft.WinGet.Client.Engine/Helpers/AppxModuleHelper.cs
Outdated
Show resolved
Hide resolved
src/PowerShell/Microsoft.WinGet.Client.Engine/Helpers/AppxModuleHelper.cs
Show resolved
Hide resolved
src/PowerShell/Microsoft.WinGet.Client.Engine/Helpers/AppxModuleHelper.cs
Outdated
Show resolved
Hide resolved
src/PowerShell/Microsoft.WinGet.Client.Engine/Helpers/AppxModuleHelper.cs
Outdated
Show resolved
Hide resolved
src/PowerShell/Microsoft.WinGet.Client.Engine/Helpers/AppxModuleHelper.cs
Outdated
Show resolved
Hide resolved
| @@ -122,7 +122,6 @@ private async Task RepairStateMachineAsync(string expectedVersion, bool allUsers | |||
|
|
|||
| if (seenCategories.Contains(currentCategory)) | |||
| { | |||
| this.Write(StreamType.Verbose, $"{currentCategory} encountered previously"); | |||
There was a problem hiding this comment.
Why did you remove this output?
|
|
||
| foreach (var entry in missingDependencies) | ||
| { | ||
| string fullPath = System.IO.Path.Combine(extractedDirectory.FullDirectoryPath, DependenciesAssetName, entry); |
There was a problem hiding this comment.
I don't see how this directory ends up in the path, unless you are expecting the archive to have every dependency under this one directory. I also don't know why we need to increase the length of the path just to put this name in.
There was a problem hiding this comment.
I made a mistake with how I created the test zip. I will fix this.
There was a problem hiding this comment.
I removed this extra directory as its not needed anymore. Basically, I compressed the folder containing the arch folders. I had to instead select all the arch folders and compress from there.
| private const string License = "License1.xml"; | ||
|
|
||
| // Format of a dependency package such as 'x64\Microsoft.VCLibs.140.00.UWPDesktop_14.0.33728.0_x64.appx' | ||
| private const string ExtractedDependencyPath = "{0}\\{1}_{2}_{3}.appx"; |
There was a problem hiding this comment.
| private const string ExtractedDependencyPath = "{0}\\{1}_{2}_{3}.appx"; | |
| private const string ExtractedDependencyPath = "{0}\\{1}_{2}_{0}.appx"; |
nit: I guess this isn't really that important, it just seems to suggest that the directory architecture and the file name architecture don't need to match.
If taken, update the format calls to remove the second architecture.
|
Does this address #4778 as well? |
It addresses the |
This change address an issue with Repair-WinGetPackageManager not installing the correct version of VCLibs before installing winget. The reason this issue came up was because the aka.ms links for the VCLibs package are deprecated and now point to an out of date package.
The solution here is to include both a
DesktopAppInstaller_Dependencies.jsonandDesktopAppInstaller_Dependencies.zipasset along with each release. Repair-WinGetPackageManager will look for those files and check what dependencies are required from the json file. If any of those dependencies are missing, it will download the zip, extract, and install the required binaries based on the system architecture.Testing:
Verified with the fresh Windows Sandbox install and trying out the assets on an earlier prerelease.
Microsoft Reviewers: Open in CodeFlow
Related to:
Repair-WinGetPackageManagerdoesn't work on sandbox with-IncludePrereleaseflag #4903