Visual Studio 与 Linux

<img src=http://7xjh3j.com1.z0.glb.clouddn.com/2017-01-26-vs-vs.jpg class=full-image />

曾经我是比较排斥 VS 的,尽管不得不承认这玩意大概是世界上最好的 IDE 无疑

最新的 2017RC 发布后,观望了半天还是装上了,然后深陷其中无法自拔…oh


自从微软拥抱开源之后,大动作不少,例如 Win10 中的 Linux 子系统,例如 Visual Studio Code,例如微软在 Github 上的贡献年度第一。

我也逐渐把 Sublime Text 换成了 VS Code,nodejs 应用感觉要开始爆炸了,哪哪都是 nodejs 写的东西。

要说当初为什么不想用 VS 那一系的东西,原因不少,可能其中有一些是没啥用的强迫症:

  • 我平时习惯的编译系统是 GNU 的,VS 一系的 C 语言标准略有区别,虽然其实也能在 VS 里面改用 GCC 编,不过以前历史遗留下来给我的印象就不太好。

  • VS 的包太大,作为一个平时只是写点小程序的人来说,即使采取了最精简的安装,可能里面 90% 以上的都是我不会用到的内容,几十 M 的例如 DevC++,或者再稍大点的 Code::Blockes 足以满足我的需求。

  • 运行起来不太顺畅,可能也跟以前包太大这个原因有关,要么就是心理作用了,总觉得用起来很不爽。

新版的 2017RC 采用了一些新的设计,例如模块化的安装器:

<img src=http://7xjh3j.com1.z0.glb.clouddn.com/2017-01-26-vs-installer.jpg class=full-image />

然后最重要的就是它原生支持 Linux 开发了,这也是我阔别多年重新装回 VS 的一个重要原因。

VS 可以本地编辑,通过 ssh 把文件远程传输到 Linux 服务器上运行和调试,这里的由于用的是 ssh,其实本地的 WSL 子系统也是可以用的,不知道以后微软会不会加上与 WSL 交互的一些更方便的接口。


WSL 上的 ssh

这其实也是个坑。

没加 Insider Preview 所以不知道目前 WSL 的开发到了哪个程度了,正式版系统中的 WSL 反正是还有不少的问题需要解决。

例如现在只有在管理员模式下运行 cmd 然后再开 bash 才能用 ping 等等的网络命令,然后其他还有各种奇怪的问题。

默认的 WSL 下(用的 Ubuntu 14.04)需要重新设置一下 ssh 才能用。

装上 openssh-server 之后,sshd_config 中有几个比较重要的需要改的有:

1
2
3
4
5
6
7
8
9
Port 2222

ListenAddress 0.0.0.0

UsePrivilegeSeparation no

PasswordAuthentication yes

PermitRootLogin yes

端口号是因为 Win10 系统自带一个 ssh … -_-///

忘了是什么时候出现的了,某次更新之后,发现可以 ssh 自己,账号是 Win10 的本地账户,密码是微软账号的密码。

ssh 进去之后是一个 cmd,当时知道的时候真是觉得我了个大去,微软偷偷摸摸就把这功能加上了。

所以为了避开,就只能另外选个端口了。

另外 ListenAddress 亲测不加不行,不知道什么原理。

切到 root 下 service ssh restart 就好了,ssh 可以正常使用,然后过程中这个 bash 窗口不能关,关掉就切断了子系统中的所有任务。

我看网上有其他教程有弄开机启动脚本的,后台一直跑着一个 sshd,有需要可以另外再找。


VS 的远程调试

首先在设置中的 Cross Platform 里面把远程 Linux 的 ssh 加进去。

在 VS 中创建一个 Linux 项目,然后正常写代码,远程 gdb 调试就 OK 啦。

详细的项目配置里面有 gdb 和 gdbserver 两个选项,默认用的应该是 gdbserver,需要 Linux 服务器上也装上,如果选用 gdb 选项的话,用的是 ssh 到服务器上之后调用 gdb --interpreter mi 即调用 Machine Interface 接口。

目前 VS 上的这部分似乎有 BUG,调试完之后 Linux 服务器上的进程不会自己结束,估计后面几个版本应该会修复。

调试中可以查看内存块、调用栈等等等等等,话说 VS 的调试器确实是好用啊,各种强大,具体的以后再挖掘。


Attach to Process

gdb 能调,理论上服务器上跑的任何程序都应该是能调的,对 gdb 来说只是加个 -p pid 选项而已。

果然在调试里面找到了 附加到进程 这个命令,可以选择 ssh,显示出远程服务器上的进程之后再选择调试即可,不过目前的版本上也有 BUG。

坐等后面的更新:

https://developercommunity.visualstudio.com/content/problem/11345/attach-to-process-over-ssh-fails.html

今天补充的时候,VS 的版本已经更新了,至少我在 root 下登进去已经可以用“附加到进程”进行调试了,爽!!!


目前遇到的然后解决了的 BUG

  • 添加 ssh 服务器的时候卡死

在配两台服务器的时候遇到的这个问题,其中一台很顺利,另一台一添加 ssh 服务器就卡死了,中间反复检查过各种配置,两台服务器是一模一样的。

一开始还以为是网关、路由表什么的影响,改了之后仍然未果。

更坑爹的是我新建了个账户测试完全正常,只有我自己那个用户账户是不对的。

最后找到的原因是:两台用的都是 zsh,但是卡住那台的默认 shell 用的是 bash,是在 .bashrc 最后加了个 exec zsh 才跳转到 zsh 的。因为当时有些环境变量的脚本跟 zsh 有冲突,所以用 bash 调完脚本加好环境之后才调 zsh。

似乎 VS 的登录到了这一步就卡死了,删掉这部分之后正常。但是我在另外的地方测试了又是好的(例如我的 WSL 就是在 .bashrc 里面写 zsh 跳转,然而在 VS 里面可以正常用)。

Anyway,玄学。

反正一般情况下还是最好不要用这种方式改 shell 了。

  • 附加到进程失败的问题

参见上面那个网址吧,是这个版本的一个 BUG,下个版本能修复,要么就把默认 shell 改成 bash,或者试试在 VS 里面添加 root 的账号。


用 VS 进行远程调试的例子

参见 Python-SWIG 初探以及其 gdb 调试

0%