Provide better information through the user agent when querying remote repositories #3526

pauby · 2024-10-04T17:10:32Z

Checklist

I have verified this is the correct repository for opening this issue.
I have verified no other issues exist related to my request.

Is Your Feature Request Related To A Problem? Please describe.

No.

Describe The Solution. Why is it needed?

To provide better feedback and information, we should update the user agent that Chocolatey CLI uses.

Additional Context

None.

Related Issues

N/A

Work the ProcessTree into a service that can be pulled in to the NugetCommon library in order to provide a more informative user agent when querying repositories.

The primary method is quickest, but as it is an unstable API, we have a need to provide a fallback that will be able to be used if the DLL is missing/removed, or if the entry point is later removed. Of the stable options, this p/invoke method seems to be the next best option to work with. Crucially, these p/invokes need to be provided by different types, so that if there is a TypeLoadException from a failed p/invoke, we can still attempt the fallback.

We need to define values for ReleaseOfficial for the benchmark project or the Cake build complains. Also added Chocolatey.PowerShell to the slnf in the repo, since that was missing.

RuntimeInformation is shadowed by Mono which means that build breaks and because all of the namespaces are the same under Mono's version, that name is not usable in our build currently. We can reuse our existing Platform.GetPlatform() helper here instead, rather than trying to disentangle exactly why this build configuration is not particularly functional.

Work the ProcessTree into a service that can be pulled in to the NugetCommon library in order to provide a more informative user agent when querying repositories.

The primary method is quickest, but as it is an unstable API, we have a need to provide a fallback that will be able to be used if the DLL is missing/removed, or if the entry point is later removed. Of the stable options, this p/invoke method seems to be the next best option to work with. Crucially, these p/invokes need to be provided by different types, so that if there is a TypeLoadException from a failed p/invoke, we can still attempt the fallback. Also, added a couple more exclusions for the choco.exe shim and for winlogon, which are not useful to include.

We need to define values for ReleaseOfficial for the benchmark project or the Cake build complains. Also added Chocolatey.PowerShell to the slnf in the repo, since that was missing.

RuntimeInformation is shadowed by Mono which means that build breaks and because all of the namespaces are the same under Mono's version, that name is not usable in our build currently. We can reuse our existing Platform.GetPlatform() helper here instead, rather than trying to disentangle exactly why this build configuration is not particularly functional.

These processes are not particularly useful to note as they are common terminal emulators, so we can exclude them when looking at the process tree.

Work the ProcessTree into a service that can be pulled in to the NugetCommon library in order to provide a more informative user agent when querying repositories.

The primary method is quickest, but as it is an unstable API, we have a need to provide a fallback that will be able to be used if the DLL is missing/removed, or if the entry point is later removed. Of the stable options, this p/invoke method seems to be the next best option to work with. Crucially, these p/invokes need to be provided by different types, so that if there is a TypeLoadException from a failed p/invoke, we can still attempt the fallback. Also, added a couple more exclusions for the choco.exe shim and for winlogon, which are not useful to include.

We need to define values for ReleaseOfficial for the benchmark project or the Cake build complains. Also added Chocolatey.PowerShell to the slnf in the repo, since that was missing.

RuntimeInformation is shadowed by Mono which means that build breaks and because all of the namespaces are the same under Mono's version, that name is not usable in our build currently. We can reuse our existing Platform.GetPlatform() helper here instead, rather than trying to disentangle exactly why this build configuration is not particularly functional.

These processes are not particularly useful to note as they are common terminal emulators, so we can exclude them when looking at the process tree.

Simplify some naming, also add a constant (and comment) to clarify what some of the p/invoke nonsense is doing.