I'm struggling to understand the cause(s) of "wminet_utils.dll"-related errors in the pipeline.

[DandelionSprout]

Among the affected PRs:

• New package：Microsoft.DotNet.Runtime.2_2 version 2.2.8.28209 #324922 (comment)
• New package：Microsoft.DirectX.Mesh version 2025.10.28.1 #325936 (comment)
• OBSProject.OBSStudio: Add portable installers for x64 and arm #320323
• New version: liule.Snipaste version 2.11.2 #322996 (comment)
• New version: ImageMagick.Q16 version 7.1.2.11 #323044
• Update libvips.libvips version 8.18.0 #324760

The error message in question:

Failure to parse win 10, attempting win 11
Caught exception while trying to kill child processes: System.TypeInitializationException: The type initializer for 'System.Management.ManagementPath' threw an exception.
---> System.TypeInitializationException: The type initializer for 'System.Management.WmiNetUtilsHelper' threw an exception.
---> System.ComponentModel.Win32Exception (193): Failed to load required native library 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\wminet_utils.dll'.
Executable C:\Users\Validator\AppData\Local\Microsoft\WinGet\Packages\Microsoft.DotNet.Runtime.2_2__DefaultSource\dotnet.exe returned exit code: -2147450751

In the case of the first 2 PRs, I presumed that adding Microsoft.DotNet.Framework.DeveloperPack_4 as a package dependency would fix it, but apparently it doesn't. So that leaves me unsure as to whether it's a client-side dependency problem, or if the .dll error is on the pipeline VMs' part?

[UnownPlain]

That error shows up on all arm64 validations so it's probably a pipeline issue. It doesn't cause the run to fail so you should ignore them.

[evilbananas]

Most things just need the .NET Framework RUNTIMES that already come packaged with the latest versions of windows.

I would be surprised if you really needed the DEVELOPER pack. I would not be adding Microsoft.DotNet.Framework.DeveloperPack_4 unless you are absolutely sure it is needed.

[DandelionSprout]

(To UnownPlain) Good to know.

(To evilbananas) I predicted that kind of situation and thus made #325400, but ironically that PR itself is struggling, since fresh stock installs of W11 will have it silently fail to install.

[evilbananas]

I could see #325400 creating a couple of issues which is probably why it isn't currently in the repo.

1.) People will install it unnecessarily
For most users, it is already included as part of their Windows installation. Because winget does not register its presence, users will assume they don’t have it and install this package needlessly. It just creates confusion as to what users have on their system.

2.) Manifests will include it as a dependency when it’s not needed
If it is added, I expect an influx of manifests—especially from new contributors—declaring it as a dependency without realizing it’s already part of Windows. I think it will just create more maintenance work for contributors in the future having to remove unneeded dependencies.

Maybe I'm missing something though and others have a different view on this.