Clarify some manifest values and add examples

[sredna]

📖 Description

• Tries to clarify the description of some of the manifest values.
• Adds value examples.
• Adds the UpgradeCode definition.

Notes:

• UpgradeCode is 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.
• DefaultInstallLocation is restricted to strings starting with % or \. The thinking is that the only sane values are %ProgramFiles%\MyApp, %LOCALAPPDATA%\Programs\MyApp and \AppInRootOfDrive.

🔗 References

Fixes some of the issues reported in #6221

🔍 Validation

None/YOLO

✅ Checklist

• Signed the Contributor License Agreement
• Linked to an issue
• Updated Release Notes (if applicable)
• Updated documentation (if applicable)
• Updated Copilot instructions (if build, architecture, or conventions changed)

📋 Issue Type

• Bug fix
• Feature
• Task

Microsoft Reviewers: Open in CodeFlow

[JohnMcPMS]

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.

[JohnMcPMS]

#6280 ; you could either grab the script from that PR or wait for it to be merged. But #6279 is updating the minor version that the script picks up so probably want that too.

[pl4nty]

A lot of apps hardcode a C:\ prefix. Most of these are parsed directly from the installer by komac

[sredna]

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%?)

[pl4nty]

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

[sredna]

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.

[pl4nty]

I think that could be misleading though. These apps don't install to \MyApp or %SystemDrive%\MyApp, they specifically hardcode C:\MyApp

[sredna]

I think that could be misleading though. These apps don't install to \MyApp or %SystemDrive%\MyApp, they specifically hardcode C:\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).

[denelon]

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.

[sredna]

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 like InstallDir "$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%\GAM7 in newer versions so this is no longer a problem nor a breaking change.

[denelon]

@JohnMcPMS what are your thoughts here?

[florelis]

I don't think we should add a new restriction on the possible values for a field, even if they may be "wrong", because that would break backwards compatibility. We could clean up the community repo, but we can't be sure it's not used like that in some private third party source.

Also, my understanding is that winget doesn't use this to decide where to install a package to, and instead it just tells us where a package installs by default. I think in those cases there is a meaningful difference between having C:\Program Files\MyApp\ and %ProgramFiles%\MyApp\: If %ProgramFiles% is configured in the machine as something different, but the installer uses C:\Program Files\ instead of a variable, then it will try to install there regardless of what your %ProgramFiles% is or whether you even have a C:\ drive.

Same for having a relative path. If an installer defaults to .\MyApp\ relative to where it is run from, then we can't say it's going to be %SystemDrive%\MyApp\ or anything like that. If the app is run from winget then we know it will be relative to winget's cwd, but I think that could change, for example if we're running inproc.