Users using the API should have greater control over the user agent string

[scottbommarito]

I am currently working on NuGet/NuGetGallery#6584

Right now, if I'd like to set the user agent used by the NuGet Client API, I have to use UserAgent and UserAgentStringBuilder, which gives me very little control. UserAgentStringBuilder allows me to set the client name, but it doesn't let me set the version, and appends the current API version to it.

[scottbommarito]

Two possible solutions:

1. Make UserAgent.UserAgentString's setter public.
2. Improve UserAgentStringBuilder so that it is more general.

I would suggest 1 over 2 because

• it is simpler, as we don't need to make UserAgentStringBuilder useful to general users
• users should be allowed to use whatever user agent string they'd like, and UserAgentStringBuilder can be a helper class for internal users

[rrelyea]

Why do you need control over version here?
Is it not useful to know which NuGet client version is being used?

/cc @joelverhagen

[joelverhagen]

Why do you need control over version here?

I'll let @scottbommarito speak to that fully, but my understanding is that he wanted the version to match the version of our job (that is using some client APIs) not the client API version.

Is it not useful to know which NuGet client version is being used?

Yes, it would be useful. We could pick just one of the two possible versions (either client API version or job version). Alternatively, we could encode both in the user agent.

My browser user agent is:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

As you can see there are many versions in there. We could do something similar for the user agent sent by entry points that use NuGet client APIs but are not themselves NuGet client 😄.