Adding Visual Studio 18.0

[andysterland]

Context

Adding VS2026 to the VSBuild@1 task so it can be used as soon the GA release of VS2026 becomes available.

Important This task uses VSWhere to determine what versions of Visual Studio are installed. VSWhere won't find VS2026 Insiders without the -prerelease flag. This will cause issues wherever it's assumed -latest will return 18.0. Ergo it might be best to not update this task until VS2026 is GA as plumping through -prerelease is a much bigger change.

#21319

 vswhere -latest -prerelease

---

Task Name

VSBuildV1

Description

Adding Visual Studio 2026, 18.0, to the hardcoded list of versions that are available.

Risk Assessment (Low / Medium / High)

Low

---

Change Behind Feature Flag (Yes / No)

No.

---

Tech Design / Approach

Copy of the commit 1ab60be and 41450699102924f215268bff661191afe9fe6c3d5703d3a7473db7e4293a2950 that added VS2022 but with +1 on versions :).

---

Documentation Changes Required (Yes/No)

Yes. Documentation needs to be updated to include 18.0 as a valid version.

---

Unit Tests Added or Updated (Yes / No)

No

---

Additional Testing Performed

---

Logging Added/Updated (Yes/No)

No, no change required updated logging.

Telemetry Added/Updated (Yes/No)

No. The task has no telemetry.

---

Rollback Scenario and Process (Yes/No)

---

Dependency Impact Assessed and Regression Tested (Yes/No)

• All impacted internal modules, APIs, services, and third-party libraries are analyzed.
• Results are reviewed and confirmed to not break existing functionality.

---

Checklist

• Related issue linked (if applicable)
• Task version was bumped — see versioning guide
• [] Verified the task behaves as expected

[ToreDemant]

Would it make sense to also include the same changes for VSBuild, VSTest and other tasks that have hardcoded Visual Studio versions?

For reference, similar changes when VS2022 was released:
#15179
#15400

[timheuer]

Thanks @andysterland for getting this started -- change looks good to me. As we discussed in chat I think this is overly engineering with specific string-looking rather than really relying on vswhere itself which already has version and latest and prerelease supported. But for the sake of ensuring this maps to release forVS2026, I'd take this change quickly and log a different issue to refactor so that each release/dot-release we don't have to chase down all these tasks. Also +1 to @ToreDemant as it indeed looks like all the others need same update.

[jessehouwing]

This SqlAzureDacpacDeploymentV1 Task also looks up the presence of VS:

azure-pipelines-tasks/Tasks/SqlAzureDacpacDeploymentV1/FindSqlPackagePath.ps1

Line 444 in d70c0cc

Invoke-VstsTool -FileName "$PSScriptRoot\vswhere.exe" -Arguments "-version [15.0,18.0) -latest -format json" -RequireExitCodeZero 2>&1 |

[jessehouwing]

And I suspect it should target the msbuildv1 as well:

https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/MSBuildV1/task.json#L57-L65

Which requires updating:
https://github.com/microsoft/azure-pipelines-tasks-common-packages/blob/626b27c67dcbc98a222c3ed13d47903107e8f44a/common-npm-packages/msbuildhelpers/PathFunctions.ps1#L370

[ToreDemant]

Similar to the comment from @jessehouwing , then I believe that also VSTestv2 needs to be fixed for us that are on Azure DevOps Server 2022.2 if the documentation is correct that V3 is not supported on-prem:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/vstest-v3?view=azure-pipelines&viewFallbackFrom=azure-pipelines-2022.2

[andysterland]

And I suspect it should target the msbuildv1 as well:

https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/MSBuildV1/task.json#L57-L65

Which requires updating: https://github.com/microsoft/azure-pipelines-tasks-common-packages/blob/626b27c67dcbc98a222c3ed13d47903107e8f44a/common-npm-packages/msbuildhelpers/PathFunctions.ps1#L370

Thanks for pointing that out :).

Looking into that file a bit more. It looks like making a change across the board in that file is probably best once VS2026 is released as it looks like that file checks for latest and I'd be worried about the impact as the -prerelease flag isn't used and adding it would add a fair bit of complexity.

[andysterland]

Similar to the comment from @jessehouwing , then I believe that also VSTestv2 needs to be fixed for us that are on Azure DevOps Server 2022.2 if the documentation is correct that V3 is not supported on-prem: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/vstest-v3?view=azure-pipelines&viewFallbackFrom=azure-pipelines-2022.2

Added.

[andysterland]

@timheuer @ToreDemant @jessehouwing Thanks for looking at this PR :). I was thinking of holding off merging until VS2026 releases. vswhere won't, by default, find the current VS2026/Dev18 installs as they are prerelease. I worry that might cause buggy interactions with assumptions around either 18 or 17 being latest.

[ToreDemant]

@andysterland These tasks have never supported prerelease/insider release som maybe it is not the biggest problem if they don't after this change either. Perhaps changing the title and description to mention 'Visual Studio 18.0 GA'

I do however agree that it would be preferrable if that support could be added too, in another PR of cause. Perhaps it could be done like the environment knob in Azure Pipeline Agent called ENABLE_VS_PRERELEASE_VERSIONS:
https://github.com/search?q=repo%3Amicrosoft%2Fazure-pipelines-agent+prerelease&type=code

[ToreDemant]

It seems that the node module azure-pipelines-tasks-msbuildhelpers also has a few lists of Visual Studio versions that is used if calling MSBuildV1 (and possibly others) asking for 'Latest'.

Any idea on how/where that can be updated?

[andysterland]

It seems that the node module azure-pipelines-tasks-msbuildhelpers also has a few lists of Visual Studio versions that is used if calling MSBuildV1 (and possibly others) asking for 'Latest'.

Any idea on how/where that can be updated?

I think @jessehouwing pointed out they come from: https://github.com/microsoft/azure-pipelines-tasks-common-packages/tree/main/common-npm-packages/msbuildhelpers

Started a draft PR for that at: microsoft/azure-pipelines-tasks-common-packages#506

[ToreDemant]

Arh, of cause, @jessehouwing is as always one step ahead :-)

[ToreDemant]

@andysterland there seem to still be picklists missing from this PR.

These are the ones I found:

• azure-pipelines-tasks/Tasks/XamarinAndroidV1/task.json

  Line 119 in 16c4e56

  "17.0": "MSBuild 17.0",

• azure-pipelines-tasks/Tasks/VsTestV3/helpers.ts

  Line 173 in 16c4e56

  case 17: return '2022';

• azure-pipelines-tasks/Tasks/VSBuildV1/task.json

  Line 48 in 16c4e56

  "17.0": "Visual Studio 2022",

• azure-pipelines-tasks/Tasks/VSBuildV1/task.loc.json

  Line 48 in 16c4e56

  "17.0": "Visual Studio 2022",

• azure-pipelines-tasks/Tasks/VSBuildV1/task.json

  Line 48 in 16c4e56

  "17.0": "Visual Studio 2022",

• azure-pipelines-tasks/Tasks/VsTestV2/task.loc.json

  Line 219 in 16c4e56

  "17.0": "Visual Studio 2022",

I found these places by searching for '17' and '2022' as I figured that if they are there then there probably also need to be something for '18' or '2026'.

[jessehouwing]

Arh, of cause, @jessehouwing is as always one step ahead :-)

I'll take that as a compliment. I'll make sure the task is available for Azure DevOps Server

[timheuer]

@andysterland should we convert this to a full PR and just request not merge until release?

[ToreDemant]

@timheuer / @andysterland I believe that some changes are still needed - see my comment above.

... and the following changes in Azure Pipeline Tasks Common Packages are also needed:
microsoft/azure-pipelines-tasks-common-packages#506

[andysterland]

@timheuer / @andysterland I believe that some changes are still needed - see my comment above.

... and the following changes in Azure Pipeline Tasks Common Packages are also needed: microsoft/azure-pipelines-tasks-common-packages#506

Created a PR for that: microsoft/azure-pipelines-tasks-common-packages#506

[jhudsonWA]

A merge would be 100% appreciated. We have been blocked from builds in DevOps since the 11th because we need MSBuild/2026 support. I have a workaround by keeping an older version of VS on the build machine, but I'd rather move forward as the majority of our systems have been updated to .NET 10 and 4.8.1

[durandt]

A merge would be 100% appreciated. We have been blocked from builds in DevOps since the 11th because we need MSBuild/2026 support. I have a workaround by keeping an older version of VS on the build machine, but I'd rather move forward as the majority of our systems have been updated to .NET 10 and 4.8.1

@jhudsonWA
I think you should be able to fix this by adding capabilities manually on your agents:

(should work for MSBuild and VSTest too)

or by updating your pipelines to point at the exe files location directly:
#21319 (comment)

[andysterland]

Is it on purpose that the following one (from the list above) is not updated too?

azure-pipelines-tasks/Tasks/XamarinAndroidV1/task.json

Line 119 in 16c4e56

"17.0": "MSBuild 17.0",

At least this one is still missing

I left that out on purpose as Xamarin is not supported in VS2026 and the component is not included. I assume folk wanting to build Xamarin apps will need to use earlier versions of the tools.

[ToreDemant]

Is it on purpose that the following one (from the list above) is not updated too?

azure-pipelines-tasks/Tasks/XamarinAndroidV1/task.json

Line 119 in 16c4e56

"17.0": "MSBuild 17.0",

At least this one is still missing

I left that out on purpose as Xamarin is not supported in VS2026 and the component is not included. I assume folk wanting to build Xamarin apps will need to use earlier versions of the tools.

Arh, that is correct. Perhaps add a comment in the code about that to avoid someone trying to add it later

[snickler]

Hi all,

Any update to this that will push it over the finish line? :)

[ToreDemant]

@snickler I am also waiting in excitement but I believe that the following needs to be finished first so its package can be included here.
microsoft/azure-pipelines-tasks-common-packages#510

[ToreDemant]

@andysterland the changes in Azure Pipelines Tasks Common Packages have now been merged into main, so I wonder if this PR could be resumed.

[ToreDemant]

@sanjays-ms is there a plan for integrating the updated azure-pipelines-tasks-common-packages from your PR into this one so that the task can be concluded?

[ToreDemant]

Thanks @andysterland for getting this started -- change looks good to me. As we discussed in chat I think this is overly engineering with specific string-looking rather than really relying on vswhere itself which already has version and latest and prerelease supported. But for the sake of ensuring this maps to release forVS2026, I'd take this change quickly and log a different issue to refactor so that each release/dot-release we don't have to chase down all these tasks. Also +1 to @ToreDemant as it indeed looks like all the others need same update.

@timheuer do you know the status on this PR. It would be mighty good to finish it up and get it merged.

[chrisbardon]

Found this PR after trying to get VS2026 to work on an agent. It looks like with the VSBuild@1 task, the build is still looking for 2022 if you have "latest" selected:

2025-11-27T16:36:39.1881425Z ##[command]"C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\Bin\amd64\msbuild.exe" "D:\buildagent-rnd\_work\1\s\iceServer.sln" /nologo /nr:false /dl:CentralLogger,"D:\buildagent-rnd\_work\_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.260.0\node_modules\azure-pipelines-tasks-msbuildhelpers\tools\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";"RootDetailId=e92ed642-cecf-4688-bd1c-37ecb310b61c|SolutionDir=D:\buildagent-rnd\_work\1\s|enableOrphanedProjectsLogs=true"*ForwardingLogger,"D:\buildagent-rnd\_work\_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.260.0\node_modules\azure-pipelines-tasks-msbuildhelpers\tools\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll"  /p:platform="x64" /p:configuration="Release" /p:VisualStudioVersion="17.0" /m /p:_MSDeployUserAgent="VSTS_3f9cc452-4b91-4f2b-8489-556283877cf8_build_13_0"

Adding the user-defined build capabilities to the agent doesn't help:

Will this get merged and pushed out sometime soon? We held off on updating VC dependencies until GA assuming that everything would work at GA, but now the build pipeline is busted.

[durandt]

@chrisbardon
Have you tried to point at the exe in your pipelines tasks?
#21319 (comment)

Not saying it's a good workaround, but it is a work-around nonetheless.

[chrisbardon]

@durandt , I saw that comment, but the challenge is that I'm using vsbuild (not msbuild) in all of my pipelines, and I'd rather not have to go through and update all of them (and then revert once this works properly).

[ToreDemant]

@tarunramsinghani MSBuild and VSBuild was fixed, but what about the rest of the tasks addressed here?

[michha]

Is this PR obsolete because #21476 is already merged?

[MichelZ]

Is this PR obsolete because #21476 is already merged?

Yes/No. This one seems to also touch the VSTest tasks, where the other PR did not. So it still has value I think (but should be rebased)

Altough there is another PR here for this: #21508

[andysterland]

Should this PR just be abandoned? I'm fine with that, I haven't had the time I had hoped for to look at this.

[MichelZ]

IMHO yes. It looks like the other PR's are from repo team members and will most likely be the one's to get merged

[ToreDemant]

However, #21508 only contains fixes for V3 and not V2