16.7 shows 16.8

[johnkors]

Hi,

Am I doing it wrong, or is there any other way to get it to use 16.7? It seems to resolve 16.8 even though I specify 16.7.

        uses: microsoft/[email protected]
        with:
          vs-version: 16.7
      - name: show msbuild version
        run: msbuild -version

Output:

Run msbuild -version
  msbuild -version
  shell: C:\Program Files\PowerShell\7\pwsh.EXE -command ". '{0}'"
Microsoft (R) Build Engine version 16.8.1+bd2ea1e3c for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

16.8.1.52902

[timheuer]

Hi @johnkors what agent machine are you using. If you are using windows-latest then this is correct behavior as the agent machines were upgraded to 16.8.x last week. https://github.com/actions/virtual-environments/blob/main/images/win/Windows2019-Readme.md#visual-studio-enterprise-2019

The hosted agent machines only have one version of VS installed at them. This vs-version attribute is mostly helpful to those who have self-hosted agent machines that may be configured with multiple versions of VS and can specify to find the path to the best match for that version. In this case I'm assuming you are using a hosted agent (windows-latest/windows-2019) and thus it only has VS 16.8 installed.

[johnkors]

Yep, exactly. Using windows-latest.

Ok, so there is no way to test 16.7 on hosted agents? 16.8 currently contains a regression, so would be nice to use 16.7 while they fix it.

We're seeing some issues on 16.8 building mixed solutions, and trying to verify that 16.7 works and what measures to take.

[timheuer]

Correct @johnkors that the hosted agents don't have another alternative for 16.7. For the regressions, using NuGet 5.8 with 16.8. I can't tell from your repro if that is still causing you issues (perhaps due to packages.config), but another option is to use msbuild to perform the restore https://devblogs.microsoft.com/nuget/getting-started-with-nuget-5-8/#known-issues