[Installation] Winget package path includes version number, causing PATH conflicts and update breakage

[igalvit]

Description:

Currently, when installing Microsoft.Edit via Winget, the package is installed into a version-specific directory:
%LOCALAPPDATA%\Microsoft\WinGet\Packages\Microsoft.Edit_..._8wekyb3d8bbwe\edit-2.0.0-x86_64-windows\

Issues caused by this implementation:

• PATH Priority: On Windows 11 systems where edit.exe (v1.2.1) is already present in C:\Windows\System32, the system continues to default to the older version because the Winget path is dynamic and often ranked lower in priority.

• Broken PATH on Updates: Every time the tool updates (e.g., from 2.0.0 to 2.1.0), the folder name changes. This requires the user to manually update their Environment Variables every single time, which defeats the purpose of a package manager.

• Command Conflict: Users are forced to manually "Move Up" the user Path over System32, which is reset or ignored when the directory name changes due to a version bump.

Suggested Solution:

Implement a static "link" or "shim" directory (similar to how Scoop or Chocolatey work) where a symlink or an alias points to the current executable. This would allow a single, static entry in the PATH (e.g., ...\Microsoft\WinGet\bin) that remains valid across updates.

Environment:

• OS: Windows 11 25H2
• Microsoft Edit version: 2.0.0 (via Winget)
• System Edit version: 1.2.1 (in System32)

[jtabox]

I think the solution you're suggesting is already there? At least for me, it's in %LOCALAPPDATA%\Microsoft\Winget\Links:

❯ where edit
C:\Windows\System32\edit.exe
C:\Users\jtabox\AppData\Local\Microsoft\WinGet\Links\edit.exe

That said, the v2 installation is so sloppy, and that's the nicest thing I can say about it.

For starters, the Winget\Links location is worthless, because it's in the user-scoped %PATH%, while Windows\System32 is in the system-scoped %PATH%, and thus Winget\Links will never have priorty by default.

The only way is to move Winget\Links to the system-scoped %PATH%, above Windows\System32 (good luck with that if you don't have admin privileges). This also means that every other random program you install via winget will also have priority over programs with the same name in Windows\System32.

This is just plain bad. For security reasons obviously, but also prone to cause bugs and other issues.

And then, why leave the v1 back as garbage in Windows\System32?

Sorry but this whole thing is horribly messy.

[igalvit]

Good point, you're right, the WinGet Links directory is already there.

I think I described the problem a bit wrong. The issue is more that the WinGet version is still shadowed by the old edit.exe in System32, so running edit keeps launching the older one.

And yeah, moving WinGet links above System32 sounds like a bad workaround, since it affects all WinGet-installed tools, not just Edit.

So I guess the real issue is the conflict/coexistence between the old System32 version and the newer WinGet version.

I'm not sure what the best fix would be here. I mainly wanted to raise the issue because the current behavior feels confusing from a user perspective, and maybe there is a better way to handle or document the coexistence between the System32 version and the WinGet version.

[jtabox]

Yes, that's the big issue. There's all sorts of executables in System32, blindly giving priority to everything that ends up in WinGet's Links is just trouble waiting to happen. Personally I'm not gonna shoot myself in the foot just to use edit.

Not to mention it isn't at all easy to delete the edit.exe that's in System32, as it's a hardlink to a file that also exists in protected Windows folders (WinSxS and SysWOW64), so you can't just delete it or replace it with the new version, even with administrative privileges. You need to do it using the TrustedInstaller role, which isn't available unless you use special commands/programs. And then you have to pray nothing else gets messed.

Also, leaving v1 behind in System32 and just yolo it and install v2 in a user folder is either a bad oversight or a bad design choice.

The only solution I can think of now is to download the exe file from this repo's releases, put it in a custom folder of your choice, and put that folder above System32 in the system-scoped %PATH%. At least this way you're in control of what that folder contains. It's what I did, I have a C:\Progs folder anyway for portable installs, created an edit subfolder in there and placed C:\Progs\edit above System32.

[jtsom-do]

Ok, so how do we fix this? I updated Edit via winget, but cannot get it to run. I removed via winget, the edit.exe version is still in \windows\system32, I cannot delete it, even with administrator privileges.

Yup. This seems like a mess.

[igalvit]

Yeah, that’s exactly my concern too. Moving the whole WinGet Links folder above System32 feels like overkill and potentially risky.

Your C:\Progs\edit workaround makes sense, since at least you control exactly what gets priority. That feels much safer than giving priority to every executable installed through WinGet.

I also didn’t realize the System32 copy was tied into WinSxS / protected Windows locations, so deleting or replacing it clearly isn’t a realistic solution either.

So I guess the issue is not that there are no workarounds, but that the official WinGet install leaves things in a confusing state: v2 is installed, but running edit still launches v1.

I’m not sure what the best fix is, but some official guidance or a safer supported way to launch the WinGet version would be nice.

[lhecker]

One solution would be to provide a hidden --x-install / --x-uninstall flag to edit which instructs it to place itself into a SYSTEM-protected directory and insert the directory into %PATH% before the System32 directory. I don't know how winget works, but I assume it could call such a custom command during installation.

Would anyone be interested in prototyping this?

Until then, if you're using PowerShell, you can place this into your Microsoft.PowerShell_profile.ps1:

function edit {
    & "${env:LOCALAPPDATA}\Microsoft\WinGet\Links\edit.exe" @args
}

---

Side note: We have considered implementing a way to centrally define overrides for System32 applications, but it's not certain yet if we will be able to ship this. The security implications are concerning after all.

This issue is not unique to Windows, however. C:\Windows\System32\edit.exe is akin to /usr/bin/edit on Linux. winget is akin to installing applications at ~/.local/bin which also doesn't take priority over /usr/bin. So, if you used a winget equivalent on Linux it would result in similar issues.

[Smart-Ace-Designs]

So, I checked out my links folder and it's empty after installing it via winget. I tried on two win 11 machines (one home and one pro) and they both have the same problem (edit.exe legacy takes precedence) and both have an empty links folder. I also tried uninstalling and reinstalling (thinking maybe a partial install) but same results...empty links folder.

Anyone know why my links folder would be empty? Since it is happening on two machines, not sure if machine specific.
Thanks.