[enhancement]: Please add support for VS 2026 (18.0) - MSBuild & Vs build Task

[rizi]

Add support for VS 2026 (18.0)

No response

Describe your feature request here

Since a preview of Visual Studio 2026 is now available, please add support for it to the MSBuild and VSBuild tasks so we can use Visual Studio 2026 on Azure DevOps Server.

Thx in advance

Br

[StellaHuang95]

Our team (Python Tools for Visual Studio) also relies on the MSBuild task in our build pipelines to build our projects. It would be helpful to know the expected timeline for adding Visual Studio 2026 support if there's plan to support it:)

[ToreDemant]

We am also struggling with this, including in the VSTest task (V2 also as it seams that V3 does not support Azure DevOps Server)

The exact same happened back when Visual Studio 2022 was released and that required us to manually deploy new versions of the tasks:
#15051
microsoft/azure-pipelines-agent#3567
microsoft/azure-pipelines-agent#3569

[ToreDemant]

Question: Why are these tasks even hardcoded to specific version of Visual Studio? They use VSWhere which does seem forward compatible so aside from situations where there is a breaking change between version, there should be no work needed on the tasks to support a new Visual Studio version.

[rizi]

Question: Why are these tasks even hardcoded to specific version of Visual Studio? They use VSWhere which does seem forward compatible so aside from situations where there is a breaking change between version, there should be no work needed on the tasks to support a new Visual Studio version.

I also asked the same question in a different repo, I would not hardcore this, that does not make any sense and it's always extremely cumbersome.

[avivanoff]

DotNetCoreCLI task also needs updating, at a minimum there are new test options when using Microsoft Test Platform runner.

I would think VSTest and some other tasks need to be updated as well.

[jessehouwing]

Question: Why are these tasks even hardcoded to specific version of Visual Studio? They use VSWhere which does seem forward compatible so aside from situations where there is a breaking change between version, there should be no work needed on the tasks to support a new Visual Studio version.

There is a bit of logic in a number of tasks that relies specifically on what version of Visual studio there is. Especially old versions. And the path to some utilities has changed over time. This accounts for some of the hardcoding. Having to find the specific executables using Search eats build time every time a build runs, so a lot of these have been hardcoded to speed things up.

And the task.json would need some datasource to allow you to easily select a version, unless the version would be a simple textbox. Currently there is no such datasource and the dropdown is simply hardcoded. Retroactively adding that dropdown is hard, since no version of Azure DevOps Server would have that endpoint now and it would need to require a patch for each.

But there is a workaround. The msbuild and vstest tasks offers the ability to provide a direct path to where the executables can be found:

# msbuild
- task: MSBuild@1
  inputs:
    msbuildLocationMethod: 'location'
    msbuildLocation: 'path/to/msbuild'

# vstest
- task: VSTest@3
  inputs:
    vstestLocationMethod: 'location'
    vstestLocation: 'path/to/vstest'

This will allow you to use them directly with prerelease versions as well as unsupported versions in the dropdown.

Unfortunately vsbuild doesn't offer this. In most cases MsBuild will do the trick though, if you point it to the msbuild.exe that's installed by visual studio.

[ToreDemant]

Thanks for the info @jessehouwing

We are already using the msbuildLocation/vstesLocation as workaround to do some testing before the GA, but would prefer not to litter this around our repositories and branches.

I believe that vswhere does return locations of various tools, but that would of cause still cost a little build time - I just figure that it is very little.

All-in-all it would have been nice if the hardcoded lists was extended as soon as the new VS Insider was made available. But I full recognize that there is always priorities to look at.