Get-VSTeamVariableGroup by name throws error 404 with TFS 2020 u1.1

[sevaa]

Steps to reproduce

Set-VSTeamAccount "http://tfs.acme.com:8080/tfs/MyCollection/" -UseWindowsAuthentication
Get-VSTeamVariableGroup -ProjectName MyProject -Name MyGroup

Expected behavior

A group record

Actual behavior

Error message with a large HTML along the lines of "error 404"

Retrieval by ID works.

If you set the project by Set-VSTeamDefaultProject, same result.

Environment data

OS

• macOS
• Windows
• Linux

Server

• TFS 2017
• TFS 2018
• Azure DevOps Server
• Azure DevOps Service

Billing                     :
Build                       : 3.0
Core                        : 3.0
DistributedTask             : 3.0-preview
DistributedTaskReleased     :
ExtensionsManagement        : 3.0-preview
Git                         : 3.0
Graph                       :
HierarchyQuery              :
MemberEntitlementManagement :
Packaging                   : 3.0-preview
Pipelines                   :
Policy                      : 3.0
Processes                   :
Release                     : 3.0-preview
ServiceEndpoints            : 3.0-preview
TaskGroups                  : 3.0-preview
Tfvc                        : 3.0
VariableGroups              :
Version                     : TFS2017

Name                           Value
----                           -----
PSVersion                      5.1.18362.1801
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.18362.1801
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

[sevaa]

The immediate cause of my issue is that _getApiVersion VariableGroups returns a blank string for my TFS; as a result, the URL for the variable getting misses the api-version parmeter and goes "https://tfs.niaid.nih.gov/tfs/Admin//AMBIS/_apis/distributedtask/variablegroups&groupName=Configuration".

The real bug is that the URL generation logic in _buildRequestURI produces a malformed URL if a blank api-version and a nonblank query string object is passed.

Yet another bug is that _appendQueryString unconditionally adds a & separator, even if the query string was originally empty. Normally it would have the api-version, but if the api-version is blank, _appendQueryString can't be used as is.

---

Looks like the root cause is that the Set-VSTeamAccount is not resolving the version of my on prem TFS instance and is not feeding the right set of api-version values. If the first line goes instead

Set-VSTeamAccount "http://tfs.acme.com:8080/tfs/MyCollection/" -UseWindowsAuthentication -Version AzD2019

That resolves the issue. Still, not cool.

---

On a side note, the notion that on-prem TFS is presumed to be TFS2017 - see _getVSTeamAPIVersion - is also rather questionable. That's a five year old version, soon to be unsupported. Maybe the module should try and interrogate the instance? That's a design decision above my pay grade, though.