好几年前，我想要用visual studio上调试wsl程序时，还需要填远程linux地址为本机ip+端口号，现在已经完全不用了。GPT大人告诉我这个的时候，我试了一下，由于中间很多步骤它都在猜测出错的可能的方向，排查，逐渐耗尽了耐心。今天搞定后重看了一遍聊天记录，它一个字都没说错...
真的是跟以前的那个胡编乱造的家伙不一样了。
先说结论：
visual studio不能编辑wsl上的项目，也无法正确识别wsl上已经存在的cmake项目。
即使能打开和编辑，也是不能写回的，这方面根本就是个残废。
蓝色部分是GPT的,验证无误的话.
更关键的一点：WSL 2 在 VS 里的官方主路，并不是“直接把源码放在 WSL 文件系统里然后像 VS Code 那样编辑”
微软对 VS 2022 的 WSL 2 工具链说明里有一句非常关键的话：
open-quoteVisual Studio 的跨平台/WSL 2 支持假设源码起始于 Windows 文件系统；当目标是 WSL 2 时，VS 会用 rsync 把源码复制到 WSL 文件系统。也就是说，它的设计中心更像是：Windows 侧源码 + WSL 侧构建/调试，而不是你现在这种“直接在 WSL 文件系统里把整个项目当 VS 本地项目来操作”。Microsoft Learnclose-quote
同时，微软现在还明确写了：
-
WSL 2 的原生支持，官方重点是 CMake 项目；
-
而且只对把 CMakePresets.json 作为活动配置文件的 CMake 项目提供原生 WSL 2 支持。 Microsoft Learn
这就解释了你为什么会觉得：
“VS 这方面就是残的”
至少对你想要的这条路径来说，确实没有 VS Code 那么自然。
方案 B：如果你就是想在 Visual Studio 里体验官方支持路径
那就不要再直接拿 WSL 文件系统里的现有目录 去硬开。更接近微软文档主路的做法是：
-
在 Windows 文件系统 新建一个 CMake Project；
-
打开 Tools > Options > CMake > General，优先使用 CMake Presets；
-
再把目标配置成 WSL / Linux-GCC-Debug 一类；
-
让 VS 按它自己的模型，把源码复制到 WSL 侧去构建和调试。
这才是它更像“官方 happy path”的用法。
然后是，如何正确的创建在visual studio中编译运行wsl中的程序
1.新建项目，开发平台选linux。
2.对CMakePresets.json右键，点击Add Configuration..,选linux debug
3.工具栏选ubuntu.
完结。
完结。
21号与GPT聊炸错在哪了?
M:
在visual studio里创建了linux空白项目，点击debug的时候出错“Could not connect to the remote system or the connection was lost.”
G:
调本机 WSL不用搞远程链接
调本机 WSL不用搞远程链接
(而且此时它对于how to check的指点都是对的)
* 你创建了 Linux 空白项目（Remote Linux）
* VS 以为你要连一台 远程服务器（SSH）
* 但你填的是 WSL → ❌ 不通
所以如果连接远程机器,需要connect,而本机,不需要,且linux项目本身可以在远程机器上连接执行.
key: 它推荐我用 “Open Folder” 直接打开 WSL 项目,并且让我用vs直接打开
\\wsl$\Ubuntu\home\你的用户名\cpp-test
还说VS 会自动识别为 WSL 项目且利用linux的tools编译,
还说我可以在wsl中创建合适的结构,vs打开它的时候会自动识别.
从这里开始应该就已经错了,后面我问它单文件是不是不行,它又告诉我加cmakefile,删掉.vs,.vscode 之类的文件夹,因为文件夹被占用我又烦躁了一会.
然后我问他用打开项目的方式还是打开文件夹的方式打开wsl里的文件夹,因为两个我打开后都做不到它说的"vs自动识别",
然后就算无法识别,我还遇到了能读不能写的情况(仅限于vs,sublime on windows就能读写linux上的文件),这事完结.
接下来就是另一个话题了,我们尝试按照它说的在vs里创建cmake on linux 平台的项目,然后还是无法编译,它漏掉了像今晚一样告诉我绿字里的2,再加上前面我们已经试了那么多错误的破事,所以接下来很快我就疯了,我觉得gpt在基于msdn的内容按照自己的理解胡编乱造.