Update YamlDotNet to Latest

[Trenly]

• I have signed the Contributor License Agreement.
• This pull request is related to an issue.

I know that NuGet packages are typically not updated unless there are CVEs, important bug fixes, or other specific need to. However, when reviewing the list of NuGet packages installed, I saw that YamlDotNet was several versions out of date. This package directly affects the parsing of manifests within WinGet and the associated utilities. Given that, I thought it best to update it, especially given the fact that 1.10 is preparing to go through the release cycle, which would give these changes enough time to be tested in the 1.11 previews and testing cycles.

This change only directly updates the top-level project - WinGetUtilInterop. I'm expecting that all the other projects which have this NuGet package as a transient dependency will pick up this new version, as all of them have a Project Dependency on WinGetUtilInterop.

The projects which consume this change -

Top-Level

• WinGetUtilInterop

Transitive

• AppInstallerCLIE2ETests
• Tool\IndexCreationTool
• Tool\LocalhostWebServer
• WinGetSourceCreator
• WinGetUtilInterop.UnitTests

---

Microsoft Reviewers: Open in CodeFlow

[yao-msft]

8.1.2 is the explicit version used by internal wingetsvc (not sure why, maybe it's from some earlier security fix), which has a dependency on the UtilInterop. But I guess it's ok to update now since it's so many versions behind.

[yao-msft]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Trenly]

8.1.2 is the explicit version used by internal wingetsvc (not sure why, maybe it's from some earlier security fix), which has a dependency on the UtilInterop. But I guess it's ok to update now since it's so many versions behind.

Does this mean I need to update another place in the code also?

[JohnMcPMS]

8.1.2 is the explicit version used by internal wingetsvc (not sure why, maybe it's from some earlier security fix), which has a dependency on the UtilInterop. But I guess it's ok to update now since it's so many versions behind.

Does this mean I need to update another place in the code also?

My guess is that it means we (the service maintainers) would need to update the version internally whenever this change gets integrated into the service code. That is probably more of a logistical annoyance than anything else.