[laurentiu021]

Three places in the Uninstaller worked out which uninstall entry, or which command, belongs to an app from less than the entry itself.

What changes

• Each row takes its own entry. EnrichFromRegistry matched the rows winget lists to Windows' uninstall entries by name alone, with TryAdd, so the first row of a name took the first entry of that name and a second row of the name took nothing. Of two programs with one name, a 32-bit and a 64-bit build, or a copy for one user beside one for everyone, one row ran the other copy's uninstaller, IsStillRegistered then checked that command and reported the row removed, and the other row had no command. The entries are now read once, and a row with an ARP\Machine\X64\<key>, ARP\Machine\X86\<key> or ARP\User\…\<key> id takes the entry the id names. winget gives that id to every app it found only in the registry, which are the rows removed with the entry's own command. Any other row is matched by name, entries Windows shows first, then by version, and when the entries left still run different commands or name different folders the row takes neither from them. Size, publisher and icon are display only and keep coming from the first entry of the name that has one.
• The MSI removal switch follows the program that runs. /I was turned into /X inside ParseUninstallCommand, in the branch for a command that starts with MsiExec, so "C:\Windows\System32\MsiExec.exe" /I{…} and C:\Windows\System32\msiexec.exe /I{…} kept /I and were refused as not a plain removal while the bare spelling of the same command ran. The rewrite now happens in UninstallLocalAsync once the program is known to be MsiExec, before the arguments are validated, so all three spellings run the same removal.
• The leftover search finds where another app lives without the launch's refusals. ParseUninstallCommand is now the launch rules (RefuseChaining) over SplitUninstallCommand, which only splits. LeftoverFinder.UninstallerFolder uses the split, so a command the Uninstaller would not run, an unquoted path with & in it say, still says where that app's uninstaller is; before, the refusal read as "lives nowhere" and a folder around that uninstaller could be offered as the removed app's install folder, ticked. SharedWith also refuses a folder that another installed app's uninstall command names anywhere in its text, followed by a separator, a quote or the end, which covers the DLL a rundll32 command loads and a command no rule splits into a program.

How it was checked

Each new test failed with its rule taken out:

• With the ARP\ id ignored, ARowWithAnArpId_TakesTheEntryItNames_AndAnotherRowOfTheNameTakesItsOwn, AUsersArpId_IsLookedUpInTheUsersList and AnArpIdNamingNoEntry_TakesNothingFromAnotherEntryOfItsName failed. Taking commands from entries that differ failed TwoProgramsOfOneName_GiveARowWithoutAnArpId_NeitherCommandNorFolder; ignoring the version failed AmongEntriesOfOneName_TheRowsVersionPicksItsOwn. TheListsAreReadInWindowsOrder_SixtyFourBitThenThirtyTwoBitThenTheUsers now gives its three entries one command, since entries of one name that run different commands are exactly what no longer hands one over.
• Without the rewrite at launch, all three rows of UninstallLocalAsync_AnMsiInstallSwitch_IsARemoval_HoweverMsiExecIsWritten failed. ParseUninstallCommand_MsiExec_SplitsOffItsArgumentsAsWritten replaces the test that pinned the rewrite in the parse.
• With the split refusing & the way the launch does, AnApp_StillLivesAroundItsUninstaller_WhenSysManagerWouldNotRunItsCommand and both rows of SplitUninstallCommand_FindsTheProgram_OfACommandTheLaunchRefuses failed. Without the search through the command's text, both rows of AnApp_LivesInAFolderItsUninstallCommandNames_ThoughNotAsTheProgramItRuns failed, and without the boundary after the name, ACommandNamingAFolderWhoseNameStartsTheSame_DoesNotClaimThisOne did.
• Unit suite twice, the format check, and all four projects built with no warnings.