Issue
Every guide that I've found concerning Linux development in VS2022 using WSL2 has involved Ubuntu exclusively. No one ever outlines the steps using CentOS or Rocky in his example.
I've had Ubuntu working just fine for C++ WSL2 Linux development, but I've never been able to do the same for CentOS or Rocky. Whenever I switch to either operating system -- either by (a) selecting one of them in the Target System dropdown, or by (b) editing the "ActiveTargetSystem" value in .vs\VSWorkspaceState.json
and then opening the solution folder -- Visual Studio 2022 just (in the first case) greys out the Target System, Configuration, and Build Preset dropdowns, and makes it impossible for me to select a startup item (doing so does nothing), or (in the second case) the solution simply fails to open.
I've noticed in output that VS2022 reports:
Not using [path_to_solution_folder]\CMakePresets.json for CMake configuration. Using the default configuration instead.
I'm not sure why it decides not to use my CMakePresets.json
file, but apparently, it's possible to set different target systems to use different CMake configuration files. I don't know how/where this is done, however. In my options for CMake
-> General
, I have "CMake configuration file" set to "Always use CMakePresets.json," so I would think that it would use that file regardless. Project
->Diagnose CMake issues
yields no information whatsoever.
It's all rather bewildering, and it's looking like everyone is just developing on Ubuntu and conspicuously avoiding set-up examples of VS2022 development involving non-Ubuntu flavors of Linux. Has anyone gotten WSL2 development with non-Ubuntu Linux working OK?
Solution
I got CentOS Stream 9 and Visual Studio 2019 working with CMakeSettings.json. I have copied my configuration at the bottom of the post, so at least that could help you with making CentOS itself working. After that verify it with a CMakeSettings.json.
However, when I try to get it working with CMakePresets.json I get exactly the same issue that you are describing as soon as I switch the target system to the remote server. To get Visual Studio after that working again I close it and remove the .vs folder. Until now I have not found the solution. Is this a bug in Visual Studio?
UPDATE: I found this link: https://developercommunity.visualstudio.com/t/cmake-presets-doesnt-work-for-wsl2-on-some-distrib/1489055 I can confirm the issue is fixed in Visual Studio Professional 2022 Preview! The fix was implemented in V17.4 on August 10th 2022, more than a year after the issue was raised. You can download it here: https://visualstudio.microsoft.com/vs/preview/ or just wait for the regular V17.4 release.
My configuration of CentOS Stream 9 has been the following (after a fresh install from the iso):
[root@localhost ~]# yum -y makecache
[root@localhost ~]# yum -y update
[root@localhost ~]# dnf -y makecache
[root@localhost ~]# dnf -y update
[root@localhost ~]# yum -y install centos-stream-release
[root@localhost ~]# visudo
Add myuser line to enable sudo rights for myuser (username depends on your own user):
## Next comes the main part: which users can run what software on
## which machines (the sudoers file can be shared between multiple
## systems).
## Syntax:
##
## user MACHINE=COMMANDS
##
## The COMMANDS section may have other options added to it.
##
## Allow root to run any commands anywhere
root ALL=(ALL) ALL
myuser ALL=(ALL) ALL
Save the file.
[root@localhost ~]# exit
[myuser@linux ~]$ sudo vim /etc/ssh/sshd_config
Set PermitRootLogin to no in the file and save it.
[myuser@linux ~]$ sudo systemctl enable sshd
[myuser@linux ~]$ sudo service sshd restart
[myuser@linux ~]$ sudo yum -y install clang
[myuser@linux ~]$ sudo yum -y install cmake
[myuser@linux ~]$ sudo dnf -y --enablerepo=crb install ninja-build
[myuser@linux ~]$ sudo yum -y install libstdc++-static
[myuser@linux ~]$ sudo yum -y install systemd-devel
End of configuration
Example entries in CMakeSettings.json for Clang and GCC:
{
"name": "Linux-Clang-Debug",
"generator": "Ninja",
"configurationType": "Debug",
"cmakeExecutable": "cmake",
"remoteCopySourcesExclusionList": [ "CMakePresets.json", ".vs", ".dockerignore", ".git", ".gitignore", "*.vcxproj", "*.vcxproj.filters", "*.vcxproj.user", "*.sln", "*.rc", "packages.config", "out", "Debug", "Release", "packages", "x64" ],
"cmakeCommandArgs": "",
"buildCommandArgs": "",
"ctestCommandArgs": "",
"inheritEnvironments": [ "linux_clang_x64" ],
"remoteMachineName": "${defaultRemoteMachineName}",
"remoteCMakeListsRoot": "$HOME/.vs/${projectDirName}/${workspaceHash}/src",
"remoteBuildRoot": "$HOME/.vs/${projectDirName}/${workspaceHash}/out/build/${name}",
"remoteInstallRoot": "$HOME/.vs/${projectDirName}/${workspaceHash}/out/install/${name}",
"remoteCopySources": true,
"rsyncCommandArgs": "-t --delete --delete-excluded",
"remoteCopyBuildOutput": false,
"remoteCopySourcesMethod": "rsync",
"variables": [
{
"name": "CMAKE_EXE_LINKER_FLAGS",
"value": "-lsystemd",
"type": "STRING"
}
]
},
{
"name": "Linux-GCC-Debug",
"generator": "Ninja",
"configurationType": "Debug",
"cmakeExecutable": "cmake",
"remoteCopySourcesExclusionList": [ "CMakePresets.json", ".vs", ".dockerignore", ".git", ".gitignore", "*.vcxproj", "*.vcxproj.filters", "*.vcxproj.user", "*.sln", "*.rc", "packages.config", "out", "Debug", "Release", "packages", "x64" ],
"cmakeCommandArgs": "",
"buildCommandArgs": "",
"ctestCommandArgs": "",
"inheritEnvironments": [ "linux_x64" ],
"remoteMachineName": "${defaultRemoteMachineName}",
"remoteCMakeListsRoot": "$HOME/.vs/${projectDirName}/${workspaceHash}/src",
"remoteBuildRoot": "$HOME/.vs/${projectDirName}/${workspaceHash}/out/build/${name}",
"remoteInstallRoot": "$HOME/.vs/${projectDirName}/${workspaceHash}/out/install/${name}",
"remoteCopySources": true,
"rsyncCommandArgs": "-t --delete --delete-excluded",
"remoteCopyBuildOutput": false,
"remoteCopySourcesMethod": "rsync",
"variables": [
{
"name": "CMAKE_EXE_LINKER_FLAGS",
"value": "-lsystemd",
"type": "STRING"
}
]
}
Answered By - Jeroen De Maeijer Answer Checked By - Marie Seifert (PHPFixing Admin)
0 Comments:
Post a Comment
Note: Only a member of this blog may post a comment.