(Public Beta) Windows Server 2022 with Visual Studio 2022 is now available

[maxim-lobanov]

Windows Server 2022 availability 🚀

Hello everyone!

We are happy to announce that Windows Server 2022 is available for GitHub Actions and Azure DevOps users 🥳
You can use windows-2022 image label in your YAML to select this image.

GitHub Actions

jobs:
  jobName:
    runs-on: windows-2022

Azure DevOps

jobs:
- job: jobName
  pool:
    vmImage: 'windows-2022'

"Beta" status

The image is marked as "beta" for now. It means some software can be unstable on the new platform. Also there could be queueing issues as the capacity will be balanced only throughout the next weeks. Known issues:

• Some build software is not compatible with Visual Studio 2022 yet (For example: Bazel)
• Some Azure DevOps tasks don't work on the new platform properly yet: VSBuild, MSBuild, UsePython (PyPy only)

Please report any problems with the new image to this repository. Any issues related to Azure DevOps tasks should be reported to https://github.com/microsoft/azure-pipelines-tasks.

Software differences

The full documentation of Windows Server 2022 image can be found in image README.
The software set is different between Windows Server 2019 and 2022. We have deprecated some legacy software with low usage and temporarily disabled software that is not supported on the new platform yet. Also, for tools with multiple installed versions we have reconsidered the list of versions based on usage.

Please find differences in the table below:

Tool name	Windows 2019	Windows 2022	Notes
Windows Server	2019 (10.0.17763 Build 2061)	2022 (10.0.20348 Build 112)
Visual Studio	2019 (16.10.31515.178) Workloads: recommended + custom + wix components	2022 Preview (17.0.31521.260) Workloads: recommended set	Our policy is installing one VS version per platform. On Windows Server 2022, we install only VS 2022 (it is in Preview for now but will be released in future). If your use-case requires using VS 2019, continue using Windows Server 2019 image. We don't have plans to deprecate it in near future.
Python	Default version: 3.7.x Architectures: x64 & x86 Pre-cached versions: 2.7, 3.5, 3.6, 3.7, 3.8, 3.9	Default version: 3.9.x Architectures: x64 Pre-cached versions: 3.7, 3.8, 3.9	On GitHub Actions, actions/setup-python can install any version on-flight so this change doesn't impact users
PyPy	2.7, 3.6, 3.7	2.7, 3.7	Version 3.6 is officially deprecated in favor of 3.7 and is not updated anymore.
Ruby	Default version: 2.5.x Pre-cached versions: 2.4, 2.5, 2.6, 2.7, 3.0	Default version: 3.0.x Pre-cached versions: 2.7, 3.0	On GitHub Actions, ruby/setup-ruby can install any version on-flight so this change doesn't impact users
Go	Default version: 1.15.x Pre-cached versions: 1.13, 1.14, 1.15, 1.16	Default version: 1.16.x Pre-cached versions: 1.15, 1.16	If your use-case requires using any of these versions, consider using tasks to install Go on-flight: - actions/setup-go (GitHub Actions) - Go Tool Installer (Azure DevOps)
Java	Default version: 8 Pre-installed versions: 8, 11, 13	Default version: 8 Pre-installed versions: 8, 11	Our policy is pre-installing only LTS versions of Java. if your use-case requires using non-LTS Java version, please consider using tasks to install it on-flight: - actions/setup-java (GitHub Actions) - Java Tool Installer (Azure DevOps)
Android	Build-tools: >= 19.x Platforms: >= 19.x CMake: 3.10.2, 3.18.1 Google APIs: 21, 22, 23, 24 NDK: 21, 22	Build-tools: >= 27.x Platforms: >= 27.x CMake: 3.18.1 Google APIs: - NDK: 21, 22
.NET Core SDK	2.1, 3.1, 5.0	3.1, 5.0	.NET Core 2.1 End Of Support is scheduled on August 21, 2021. Please consider using tasks to install any version on-flight: - actions/setup-dotnet (GitHub Actions) - Use .NET Core (Azure DevOps)
Az modules	Installed: 6.1.0 Zipped: 1.0.0, 1.6.0, 2.3.2, 2.6.0, 3.1.0, 3.5.0, 3.8.0, 4.3.0, 4.4.0, 4.7.0, 5.5.0, 5.9.0, 6.1.0	Installed: 6.1.0 Zipped: -	If your use-case requires using any of these versions, consider using tasks to install Az modules on-flight: - azure-powershell-action (GitHub Actions) - Azure PowerShell (Azure DevOps)
MSYS2	A lot of pre-installed msys packages	Only pure MSYS2 is installed. No additional packages	On Windows Server 2016 and 2019 we had a lot of pre-installed MSYS2 packages. We had a long discussion about "pre-installing them" vs "installing in runtime and caching". Our recommendation is using official setup-msys2 action to install packages on-flight and cache them.

The following software were not installed on Windows Server 2022 images by default: Miniconda, Google Cloud SDK, InnoSetup, NSIS, Perl, sbt, Cloud Foundry CLI, BizTalk Server and Client, WebPlatformInstaller, Windows Driver Kit

[robertmclaws]

Can you please update the Visual Studio version on this image to Preview 4? Thanks!

[miketimofeev]

Hi @robertmclaws! We always install the latest VS version available at the moment of image generation, so the preview 4 image should be accessible later this week.

[robertmclaws]

Thanks Mike! It's really cool that you folks have automated these releases and such... thanks so much for your efforts!

Would be really nice though if you folks could put out image updates day-and-date with Visual Studio releases, especially around major versions (like Release Candidates). OR give us an easy way to trigger VS updates from a task. It's tough to meet our deadlines when builds that run locally won't run in CI because VS releases in our pipeline are a week behind.

Thanks again!

[miketimofeev]

@robertmclaws unfortunately, we are usually not aware of such major changes in VS beforehand. It would be great if you or any other VS user would create an issue here in advance next time so we can push the critical update on time rather than follow up our usual deployment schedule (start on Monday and finish on Wednesday-Thursday).

[miketimofeev]

@robertmclaws the new image with update VS has been deployed

[robertmclaws]

By virtue of having Visual Studio 2022 on there, it should also have the .NET 6 SDK that ships with that version.

Having said that, I always have a ".NET Core SDK" task in my pipeline that installs the version specified in global.json. Ensures I'm using the right version no matter what is on the box.

[MaksimZhukov]

Hello @jackbond! The Windows Server 2022 image contains .NET Core SDK 6. Please find more details about included software in the Windows2022-Readme.md file

[MSP-Greg]

Please consider installing the base-devel and compression groups to the MSYS2 installation on Windows-2022. Both were installed on previous images.

A few issues:

1. The base-devel group is shared by the separate build tool chains. For example, mingw or ucrt gcc won't run unless MSYS2 base-devel is installed. It contains many build tools that are platform/compiler agnostic.

2. Without compression, there's no tar. Pretty common command for CI. I haven't checked for a while, but at one time the Windows tar did not support all the formats that MSYS2/*nix tar does.

3. At some point, parity with Ubuntu or WSL2 should be considered.

4. Working with Ruby, the time to install ucrt64 or mingw64 is one half the time it takes to install the portion of the MSYS2 base-devel group that we need. The time needed is to extract the files from a single file (which we create), so caching won't improve the time much.

MSYS2 base-devel packages:

asciidoc            diffutils           pacman *
autoconf            dos2unix            patch
autoconf2.13        file                patchutils
autogen             flex                perl *
automake-wrapper    gawk *              pkgconf
automake1.10        gdb                 pkgfile
automake1.11        gettext *           quilt
automake1.12        gettext-devel       reflex
automake1.13        gperf               scons
automake1.14        grep *              sed *
automake1.15        groff               swig
automake1.16        help2man            texinfo
automake1.6         intltool            texinfo-tex
automake1.7         libtool             ttyrec
automake1.8         libunrar            unrar
automake1.9         libunrar-devel      wget *
bison               m4                  xmlto
btyacc              make                
diffstat            man-db              

* Seven packages already installed on Windows-2022

[xavier2k6]

For anyone interested:

Visual Studio 2022 hits general availability (GA) on November 8

Visual Studio 2022 Launch Event Monday November 8, 2021 | 8:30am PT

[sylveon]

Is it possible to install the Windows SDK, version 10.0.22000 on those images?

Also, VSTest is not listed in the broken tasks but is broken.

[al-cheb]

Is it possible to install the Windows SDK, version 10.0.22000 on those images?

Also, VSTest is not listed in the broken tasks but is broken.

Currently, WDK 22000 is not available for VS 2022.

[database64128]

Currently, WDK 22000 is not available for VS 2022.

It is. I'm using it on my local install of VS2022RC.

[mikhailkoliada]

@database64128 Hello!

I am curious, could you please be kind and share a link where you downloaded a wdk version for VS 2022?

[database64128]

@mikhailkoliada I installed Windows 11 SDK 22000 from Visual Studio Installer:

This is also what @sylveon asked for.

[miketimofeev]

@database64128 @sylveon looks like we mixed up SDK and WDK. We will add SDK to the image.

[nesherhh]

Could you please also update VS 2022 to the latest RC2 oder Preview 5?

[miketimofeev]

@nesherhh it will be updated automatically next week as we always install the latest version.

[nesherhh]

ok, thanks

[miketimofeev]

@database64128 @sylveon the image with windows11 SDK will be deployed next week

[sylveon]

Awesome, thank you!

[nesherhh]

Can you tell us which day this week it will be updated automatically? There is already VS 2022 Preview 6.

[miketimofeev]

@nesherhh it will be available in a week (approx November 2 or 3)

[nightlark]

Would it be possible to get NSIS added to the windows-2022 image? Some of our pipelines have been failing when we tried updating; it looks like it was previously included in windows-2016 and windows-2019 images.

[miketimofeev]

@nightlark could you please open an issue about adding the tool?

[p2pbsh]

Great job having the VS2022 image available to coincide with the final .NET6 RC phase. Last year was a bumpy ride, but this time I've been able to port to 6 and keep my pipelines running seamlessly. 🥇

[fbrosseau]

@... looks like we mixed up SDK and WDK. We will add SDK to the image.

Hi @miketimofeev, I can confirm Windows SDK 22000 is there, but the Debugging Tools (dbgeng.dll, etc etc) do not seem to be installed, and they were before. They are usually part of the Windows SDK umbrella.

This is typically C:\Program Files (x86)\Windows Kits\10\Debuggers (exact path can be found through registry)

My usecase of using the debugging tools may be a little niche, but could you confirm if this change is intentional and that they should be manually acquired instead?

[sylveon]

I would also like for the v142 C++ build tools to be installed in the image. One of my project cannot build using the v143 build tools because of https://github.com/microsoft/microsoft-ui-xaml/issues/5597, so has to be built using the v142 tools. My other projects, however, use the v143 tooling and some of the new features it provides.

Additionally, spectre mitigated runtime libraries aren't installed for ARM64:

Project "D:\a\1\s\TranslucentTB.sln" (1) is building "D:\a\1\s\TranslucentTB\TranslucentTB.vcxproj" (2) on node 1 (default targets).
Project "D:\a\1\s\TranslucentTB\TranslucentTB.vcxproj" (2) is building "D:\a\1\s\ExplorerHooks\ExplorerHooks.vcxproj" (3) on node 1 (default targets).
PrepareForBuild:
  Creating directory "ARM64\Debug\".
##[error]C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Microsoft\VC\v170\Microsoft.CppBuild.targets(483,5): Error MSB8040: Spectre-mitigated libraries are required for this project. Install them from the Visual Studio installer (Individual components tab) for any toolsets and architectures being used. Learn more: https://aka.ms/Ofhn4c
C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Microsoft\VC\v170\Microsoft.CppBuild.targets(483,5): error MSB8040: Spectre-mitigated libraries are required for this project. Install them from the Visual Studio installer (Individual components tab) for any toolsets and architectures being used. Learn more: https://aka.ms/Ofhn4c [D:\a\1\s\ExplorerHooks\ExplorerHooks.vcxproj]
Done Building Project "D:\a\1\s\ExplorerHooks\ExplorerHooks.vcxproj" (default targets) -- FAILED.

[miketimofeev]

@fbrosseau no, it is not intentional. I assume these debuggers are installed as a part of either standalone SDK package or WDK, which is not available for VS2022 at the moment. SDK and WDK are installed using this script https://github.com/actions/virtual-environments/blob/main/images/win/scripts/Installers/Install-WDK.ps1 so we will update it once WDK for VS2022 is available.

[miketimofeev]

@sylveon please create an issue to add these components.

[sylveon]

I opened #4342 and #4341 for them. @miketimofeev

[jomocl]

What about wsl2? - and maybe being able to run Linux containers in the hosted agent?

[krokofant]

@jomocl I believe because Windows containers are enabled by default (or at least work by default) it's easier to use Windows containers in Windows agents and Linux containers in Linux agents.

[miketimofeev]

@jomocl wsl2 is not available for windows server distributions

[andreineculau]

@miketimofeev I'm noticing some differences regarding permissions. It's an early stage in my investigation and I don't have a simple repro, but I'm posting here in case it's something obvious on your side.

So I'm creating a file within wsl's ubuntu 20.04 distro and then I want to chmod a+rw, which fails, because the file is owned by root:root on windows-server-2022 and github:github on windows-server-2019. Upon further investigation it looks like the entire checkout is owned by root:root instead of github:github. I should mention that the checkout is done outside of actions/checkout, but that it is at core a simple git checkout command, which runs in the bash shell. So my first guess is that there's a diff 2019-2022 as to which user you run the shell.

failing 2022: https://github.com/ysoftwareab/yplatform/runs/4044740469?check_suite_focus=true#step:6:15

green 2019: https://github.com/ysoftwareab/yplatform/runs/4044740416?check_suite_focus=true#step:6:15

EDIT: confirmed that the checkout is ok. The permissions are the same on 2019 and 2022. https://github.com/ysoftwareab/yplatform/runs/4044933354?check_suite_focus=true and https://github.com/ysoftwareab/yplatform/runs/4044933386?check_suite_focus=true

[miketimofeev]

@andreineculau thanks for reporting! No, we haven't seen this before so please feel free to create an issue when you have a repro.

[andreineculau]

@miketimofeev I won't create an issue. When digging into the behaviour - I was setting default uid/gid using wsl.conf but I was never calling wsl --shutdown or sleeping ~8 seconds (as per https://github.com/MicrosoftDocs/WSL/blob/master/WSL/wsl-config.md) for the changes to be applied. No problem at all with 2019, but constantly failing with 2022.

It might be that others will face the same issue, but it is simply a behaviour/timing change, not something you need to handle. But thanks anyway! Keep up the nice work! 🙋‍♂️

[RolandoMalena]

Is WSL2 something that can happen on this new agent? One nice use case that we would love to have on our CI pipelines is to have integration testing where we test the integration between our Windows Desktop App and our NodeJS API running on Ubuntu (which is what we use on Production). The former would send data via HTTP requests to the latter.

I would love to be able to run Linux containers in a Windows Agent, so we can ramp our API in a Docker Container and run our Desktop App against it.

[andreineculau]

@RolandoMalena unfortunately there is no wsl2 on Windows Server 2022. Nothing to do with GitHub turning on a switch, it's all about Windows - see https://github.com/microsoft/WSL/issues/6301#issuecomment-858816891

We are many that would be interested in WSL2 and I hope there are alternatives considered by GitHub, but specifically to your case, while I haven't tried it myself but why can't you run your tests against 1. a backend running on wsl1? 2. Or a Docker?

[RolandoMalena]

@andreineculau Currently I am unable to run docker within wsl1, the error I get indicates the docker daemon never starts and I haven't figured out how to start it yet. I will keep trying of course.

Another alternative might be to just download the source code and run the API but I would rather not do that if possible.

Here is my test repo with a workflow and some failed runs, feel free to contribute. https://github.com/RolandoMalena/windows_wsl_workflow

[xavier2k6]

Visual Studio 2022 reached GA now

[juanmalm]

@maxim-lobanov would be possible to include Microsoft.VisualStudio.Component.Windows10SDK.17763 as part of the included software?? We have to keep 17763 as minimum version for our UWP project.

[julianxhokaxhiu]

Please consider updating VS2022 to the official release instead of the preview one. Thank you!

[miketimofeev]

@julianxhokaxhiu the image rollout has started and will be finished tomorrow.

[krokofant]

Any idea when windows-latest will point to windows-2022? If it will switch just after windows-2022 goes stable then maybe it should be mentioned.

[miketimofeev]

@krokofant we are working on a migration plan and will announce the timeline a bit later.

[miketimofeev]

We are going to stop treating the image as beta starting from November, 15. The announcement available here https://github.com/actions/virtual-environments/issues/4488

[nwaf999]

H

[TheRustifyer]

Hello.

How can I enable on the windows-2022 machine the support for the C++20 modules support? I need to "enable" this component like if it where selected in the visual studio installer to download it for vstudio.

I am getting this error on my Action, btw:

fatal error C1011: cannot locate standard module interface. Did you install the library part of the C++ modules feature in VS setup? 

[sylveon]

I would recommend moving away from import std.core; and back to #include <thing> or import <thing>;

The standard library was not modularized for C++20 so you're using a non-standard extension. Using #include or import <thing>; does not require to install an additional component. If you really need them, you can simply run the VS setup from a powershell script:

Set-Location "C:\Program Files (x86)\Microsoft Visual Studio\Installer\"
$InstallPath = "C:\Program Files\Microsoft Visual Studio\2022\Preview"
$componentsToAdd = @(
  # add components here, i don't know the name of the component with the standard library modules
)
[string]$workloadArgs = $componentsToAdd | ForEach-Object {" --add " +  $_}
$Arguments = ('/c', "vs_installer.exe", 'modify', '--installPath', "`"$InstallPath`"",$workloadArgs, '--quiet', '--norestart', '--nocache')
$process = Start-Process -FilePath cmd.exe -ArgumentList $Arguments -Wait -PassThru -WindowStyle Hidden
if ($process.ExitCode -eq 0)
{
    Write-Host "components have been successfully added"
}
else
{
    Write-Host "components were not installed"
    exit 1
}

[TheRustifyer]

So I must add the modules component, copy paste your script into my project and create a new named action inside the current one?

That location (Set-Location "C:\Program Files (x86)\Microsoft Visual Studio\Installer\") is the real location of the preinstalled msvc2022 on the windows-2022 machine?