Clarify some manifest values and add examples#6277
Conversation
This comment has been minimized.
This comment has been minimized.
JohnMcPMS
left a comment
There was a problem hiding this comment.
The changes seem reasonable to me, but I don' actually touch the schema much so I would like someone else to take a look too.
The flow for semantic changes to the schema as part of a new minor version also requires quite a bit more setup. See #5997 and/or #5011.
I think I will also create some additional documentation to prevent the need for you to parse through those if you want to wait for that.
| "minLength": 1, | ||
| "minLength": 2, | ||
| "maxLength": 2048, | ||
| "pattern": "^[%\\]", |
There was a problem hiding this comment.
A lot of apps hardcode a C:\ prefix. Most of these are parsed directly from the installer by komac
There was a problem hiding this comment.
But it does not make sense to allow that. I don't think this value is actually used yet but when it is, there are pretty much only 3 places that make sense:
%ProgramFiles%\MyApp(Or in%ProgramFiles(x86)%)%LocalAppData%\Programs\MyApp\MyApp(In the root of any drive? The same drive as%windir%?)
There was a problem hiding this comment.
Unfortunately a lot of apps do not install to paths that make sense. I don't think we can block apps from WinGet just because they install to an unusual path
There was a problem hiding this comment.
It's not about blocking anyone but manifests should match the spec. Some manifests might need to change c:\MyApp to \MyApp etc. to be compliant if they want to update to the latest manifest version.
There was a problem hiding this comment.
I think that could be misleading though. These apps don't install to \MyApp or %SystemDrive%\MyApp, they specifically hardcode C:\MyApp
There was a problem hiding this comment.
The fact that "some manifests may need to change" would indicate to me this is a breaking change as manifest versions should be forward compatible as mich as possible.
There was a problem hiding this comment.
I think that could be misleading though. These apps don't install to
\MyAppor%SystemDrive%\MyApp, they specifically hardcodeC:\MyApp
C:\ might not even exist on all systems.
Somebody from Microsoft should chime in and say the exact allowed format of this value (which is the point of this PR in the first place).
There was a problem hiding this comment.
Do we have any concrete examples of packages in the repository that exhibit this behavior. I suspect we'll need to use a few real examples to make the right decision here.
There was a problem hiding this comment.
Do we have any concrete examples of packages in the repository that exhibit this behavior.
Examples of drive c: root folders (I think this is all the packages that do this):
- KOG.Elsworld.es.installer.yaml:
C:\KOGGames\Elsword64 - Coq.CoqPlatform.installer.yaml:
C:\Rocq-Platform~9.0~2025.08 - CharruaSoft.PrintSCP.installer.yaml:
C:\CharruaSoft\PrintSCP - martinrotter.RSSGuard5.installer.yaml:
C:\RSS Guard 5
Examples of broken entries:
- Ethereum.geth.installer.yaml:
InstallDir(This looks like a bug in some sort of automated script. In NSIS installers, the default install directory is specified likeInstallDir "$ProgramFiles\MyApp") - Humanity.DJV2.installer.yaml:
Documents\DJV 3.3.4(I assume they mean My Documents but that should be specified as%userprofile%\Documents) - GAM-Team.gam.installer.yaml used to specify
./GAM7(relative to what?) in older versions but has been corrected to%SystemDrive%\GAM7in newer versions so this is no longer a problem nor a breaking change.
📖 Description
Notes:
UpgradeCodeis restricted only to GUIDs because this is a MSI feature. I have verified that all existing manifests in the community repository only uses GUIDs here.DefaultInstallLocationis restricted to strings starting with%or\. The thinking is that the only sane values are%ProgramFiles%\MyApp,%LOCALAPPDATA%\Programs\MyAppand\AppInRootOfDrive.🔗 References
Fixes some of the issues reported in #6221
🔍 Validation
None/YOLO
✅ Checklist
📋 Issue Type
Microsoft Reviewers: Open in CodeFlow