Support for hosting "headless" Live Share sessions / remote editing

[david50407]

It would be nice if Live Share has its own CLI tool which can start (hosting) a collaboration session without VS/VSCode. This feature will allow remote machine starts a session as host then developers can modify codes directly on the server (which doesn't have GUI desktop). This has a great benifit for both self uses and collaboration uses.

[Chuxel]

Thanks for the suggestion! This is definitely something we've considered. Out of curiosity, what do you see as the critical capabilities you'd need be able to perform remotely for something like this to work for you?

[Chillee]

In my opinion, the best kind of interface for this tool is some kind of running daemon that you can disconnect/reconnect to without losing your previous workspace state. Imagine something similar to tmux.

[Codelica]

I think it would also be valuable to just "spin it up" in a directory as well. So basically some sort of agent that could run in daemon mode or manually (ala carte) would be ideal IMO. Daemon mode could potentially accept a config file with directory/project locations, etc. Much could be done here to help solve an issue that has really been around for years, and years, and...

[Chuxel]

@Codelica @Chillee Yeah I can see both being useful. For example, if there was a CLI, you could have "vsls server my-directory-here" for ad-hoc use particularly in situations where you might not have priv's to setup a daemon in addition to a "vsls install" or "vsls setup" to get a demon running for a particular directory. The install/setup commands could then either take a set of command line args or a json file encapsulating them.

Seem about right?

[Codelica]

Yep.. that would be great. Both situations definitely occur. That gives it a model somewhat like PM2 for Node. Now what would be really neat is npm install vsls -g but however it gets implemented I'm on board. :)

[vchuravy]

I usually work on remote systems and my current workflow is to use sshfs to edit files in VS Code (which is suboptimal) and I would love seeing this as a native feature!

Important for me:

• Use the git identity/keys of the local machine (the one I am editing from)
• Attach a remote shell/run code on the remote machine.

Optional:

• Have a "Open remote" option in VS code that uses ssh to setup a connection

[lostintangent]

@vchuravy Definitely agree that we can likely do better than SSHFS :) Just to confirm, would you still need a remote file mount (which you could use arbitrary local tools against), or would it be sufficient to just have VS Code, and it’s integrated experiences (editor, debugger, terminal, etc.) connected to the remote machine?

[vchuravy]

No I don't need a local filemount. I only use that for VS Code, everything else happens on the server.

On Sat, Feb 3, 2018, 11:11 Jonathan Carter notifications@github.com wrote:

@vchuravy https://github.com/vchuravy Definitely agree that we can potentially do better than SSHFS :) Just to confirm, would you still need a remote file mount (which you could use arbitrary local tools against), or would it be sufficient to just have VS Code, and it’s integrated experiences (editor, debugger, terminal, etc.) connected to the remote machine?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/MicrosoftDocs/live-share/issues/74#issuecomment-362827402, or mute the thread https://github.com/notifications/unsubscribe-auth/AAI3agFFpaKSFr-KiPgRLa4WmpRW1habks5tRIUSgaJpZM4R2m0e .

[Chillee]

@lostintangent For me, i wouldn't need the local file mount. It's not really practical to run any kind of local tool on a sshfs mounted drive. So, being able to open up an integrated terminal easily would suffice.

[lostintangent]

@vchuravy @Chillee Perfect! Thanks for confirming that.

[Chuxel]

There are a series of related issues to this one worth highlighting that may also need to be in place for the headless scenario to work.

I'm curious if others agree (and/or have upvoted them) or if any of these are really not required:

1. 44 - Guests cannot perform file operations like rename, delete, or add

2. 43 - No support yet for find in files, replace in files, and related multi-file search features not backed by a language service/server

3. 32 - Allow guests to start a build or debugging session on the host's behalf (also covers "attach")

4. 48 - Build output is not available to guests

VS Code specific:

1. 42 - Breakpoints do not synchronize in VS Code, guests cannot set them

VS specific:

1. 76 - Navigate To does not function as expected for guests due to missing backing implementation

2. 31 - Support "Solution View" in the Solution Explorer for guests in VS

3. 35 - Allow guests to use package and reference management UI in Visual Studio

Also, anything missing?

[vchuravy]

I would say #44 and #43 are must haves for this feature to make sense, and the others are nice to have.

[Chuxel]

@vchuravy So, if I'm interpreting your workflow correctly, in your case (with VS Code) you'd be using a terminal session to run and build remotely and then directly remote attach the debugger as needed. Consequently the key things you'd get the most value from are the visibility to the entire project structure, remote editing, and full-project intellisense. Debugging / build features then become nice to have. This an accurate interpretation?

[Chillee]

To me, none of the features listed are essential. The most critical feature for me is just being able to use my editor remotely with language services. There's not many ways of doing that now, and that gets me 95% of the way there.

It's the only thing that's directly integrated with text editing that requires special support. Find in files is nice, but you can use grep anyways. Same for git, etc. If you're on a remote server to begin with, I'd expect that you were expecting to build stuff manually anyways.

After that, in order of nice to have:

1. Debugging
2. Find in files
3. Anything else

[jedieaston]

agree with @Chillee, but it would also be nice to have ssh be the default shell if you are doing a live share to a box. would save a step of typing ssh user@box and it could use ssh keys on file via ssh-agent.

[dxetech]

I also agree with @Chillee, the most important thing is to use the editor remotely with language services, with debugging a close second. Honestly this would completely transform my workflow. I would consolidate about 3-4 development machines into 1, and the rest would just be a combination of RDP / Live Share into one primary machine.

[colek42]

This would replace supplement vim for me. Our stack is too big to run on a laptop, so we all have machines in the cloud or on an ESXi server. ESXi, VNC was great, until we all started using 4k monitors. Now we all use vim, I love vim and all, but for a lot of tasks I am much more productive with vscode. This would be an amazing add to our new dev boxes we set up and really help our onboarding process.

I think the only thing we would need is a command line utility and API to control shared sessions and LSP support (we are a go shop). We can just use the terminal for everything else. Things like file renaming and find and replace will be great, but the tool can probably be released without it since you have zero competition in this space.

@bketelsen

[Chuxel]

@colek42 Great info - appreciate it! This is definitely something we've been thinking about particularly as we work to improve our language service support to be more universal and round out our core.

[Chuxel]

Merging in feedback in #358 from @Hong-Xiang

---

Product and Version [VS/VSCode]: VSCode 1.23.0 OS Version [macOS/Windows]: Windows 10 Live Share Extension Version: 0.3.98 Target Platform or Language [e.g. Node.js]: Python

Steps to Reproduce / Scenario:

It would be helpful to forward notifications to guest, especially when use live-share as an awesome remote develop tool instead of co-develop tool.

I'm using live-share to develop some program, which would run on some Ubuntu servers, from Windows 10. After opened VS Code on the Ubuntu server (looking forward for feature #74!), I focus on VS code on Windows connecting via live-share.

The problem is some actions would trigger a notification won't have any affect on guest side.

A typical example is Format Document. When autopep8 is not installed in Ubuntu/Server side, if I use Format Document for Python file, there would be a fancy notification notice me that and can easily install it. However when I'm editing it as a guest, if I use Format Document when there is not autopep8 installed on server side, there won't be any notifications on guest side, neither on server side.

This would be some how really confusing. Since when I press Alt-Shift-F and wait Format Document to work, there is nothing happened. But there would be lots of reasons which may cause this, such as syntax error in source code. Even after spend some time in looking for possible syntax error, it is hard for me to realize the problem is missing autopep8 in server side, especially when autopep8 is currently installed in guest side.

This is just one example when forward notification would be really helpful. It would be even more important when reason caused function failing is more complicated, or when it is not easy to operate VS Code on server side.

[DotNetRussell]

From my original post https://github.com/MicrosoftDocs/live-share/issues/498

From what I inferred from Build2018, LiveShare is intended to be used by people attempting to collaborate. It's awesome at this by the way. Such an amazing tool.

That said, I've found more than one dev who are using LiveShare as a means to escape working on a mac or just on a company machine in general.

I use live share everyday now since it was announced at build. I use it because I prefer developing on a Windows Machine as opposed to the MacBook provided by my company. I'm also easily able to use my current main development machine instead of hunching over a laptop. It's super nice and has completely changed how I work.

So my request. Offer a spin off of liveshare or include in liveshare, functionality that would make this experience even better. I think there's a demand for this niche of functionality and LiveShare is a great tool to facilitate that. However, at times it feels like using a pair of plyers to turn a screw when really we need a screwdriver.

[iamwrm]

I'd like to mention that this feature can also benefit debugging and browsing through the file tree in a docker container( or WSL?).

For now debugging for a docker container or through an ssh tunnel is so troublesome and the guideline of tinkering the launch.json is hard and even has bug to follow. https://github.com/Microsoft/vscode-cpptools/blob/master/Documentation/Debugger/gdb/PipeTransport.md

[daytonellwanger]

Copying @colek42 's comment from 208 It looks like all of the pieces are there to make a great remote IDE. Supporting a headless mode, and command line utility or API for sharing would allow me to have my dev machine in the cloud and use Visual Studio/VSCode like I currently use VIM.

[ruohki]

This would be a great feature, curently iam using Cloud9 on a remote SSH workspace, because i work on multiple workstations. Sadly iam bound to the webide that way. Id really love to be able to use my fav editor with this kind of setup.

[kirbiyik]

I fall asleep by dreaming this feature at nights. I hope one day my dreams will come true...

[DotNetRussell]

What would make LiveShare perfect for me?

1. Ability to use the find everywhere ability from guest machine
2. Ability to use git operations from guest machine
3. Ability to run LiveShare headless

[Codelica]

I like the list, but priority wise it's reversed for me.

1. Run LiveShare session/daemon headless from cli (with simple install).
2. Allow bringing up remote shell sessions over LiveShare

Those two alone would give a ton of freedom IMO. Beyond that...

3. Remote git operations over LiveShare
4. Remote find operations over LiveShare
5. Any other LiveShare functions (debugging, etc.)

Remote headless sessions would be a real winner though, with tons of uses IMO. Inside containers, headless iot devices, remote servers, etc.

[okur]

I think this feature would be very handy since it will change the way people use ssh.

[Chuxel]

Appreciate the additional insights folks!

Out of curiosity, how many of you are looking to be able to access existing (or self-provisioned) remote servers / machines / devices verses having a cloud hosted environment like @ruohki described?

[Codelica]

Our use case would be remote servers and containers. Some are bare metal VM servers we manage, others are cloud hosted VMs, etc. In the end we'd like to use it wherever we have a shell prompt and files to edit. :)

[fiesel]

Well a in a far dream a workflow like:

1. Fire up VS Code.
2. Select a new Template Environment / Existing Environment.
3. Start Your Work on a remote Machine. . . Last. Deploy it to a Azure / AWS / DO / WhateverCloud machine

Would be a blast.

[kirbiyik]

@Chuxel In my use case, in our university lab we are heavily dependent on cluster to run our programs. I was using vim but I was never satisfied with it(no offence vimmers!). I've used extensions like Remote VSCode and Remote Workspace. Yet they are not well maintained and have many bugs. I am waiting for this feature to fire up vscode and share a workspace from terminal and develop from my local computer. Thanks in advance for your efforts!

[DotNetRussell]

My use case is, my company gives me a MacBook to work on. MacOS Is a dumpster fire and I hate developing on a laptop full time. I just want to be able to work on a machine I'm comfortable on. So I use Live Share and Windows Linux subsystem with ssh and tmux to tap into my MacBook.

[Chuxel]

@Codelica Yeah makes sense. Since you mentioned managing, are you primarily thinking about being able to use this for managing the servers or DevOps activities (e.g. editing scripts), debugging a deployed application, develop a new application/feature/bug fix, or some combination?

@fiesel Given your description, I assume in this future you are thinking about a service managing these environments for you, correct?

@kirbiyik Is your current workflow then to sign into one of the machines in the cluster and use Vim / NeoVim to do the development? Is this because the infrastructure cannot run you local machine?

@DotNetRussell Got it - that's a really interesting use case.

[fiesel]

@Chuxel well lets have a look at codesandbox.io. You select a template you wanna start on and then get going on it. Sadly this just works for frontend solutions.

Having such a system using vscode as your editor and managing remote machines (like a cloud workspace) would be insanely cool. This is a PaaS solution.

As a first beeing able to setup a remote workspace somewhere and then beeing able to connect to it trough vscode. Using the terminal, exposing ports and live collaboration on the same workspace (in terms of teaching / mentoring people) is an insanely cool idea.

In times where you can grab a free virtual machines or pay literally a dollar for a small one this is a super cool usecase for people

Edit: Right now iam working on a windows machine via remote desktop when iam home, just so i can use the live session to work on it when on a 3G/4G connection

[kirbiyik]

@Chuxel yes, I do not only run code on cluster but also change the code in it instantly for practical purposes during experiments. I basically want to use VSCode on ssh connections. In my opinion, there are a lot of people in ML community would want a feature like this since they generally run the program in remote due to need of GPU and memory constraints.

[Codelica]

@Chuxel It would be a real variety TBH. Devops that include everything from simple edits to config files and scripts, to connecting to a larger remote Ansible directory tree we manage (which would be awesome). But also more development related items like editing a remote Node services in containers to try out a live hot fix (it does happen ;) ). Depending on how it was implemented, potentially making file edits on remote IOT devices we have at customer locations (w/ vpn access). And things I haven't even considered I'm sure.

[Chuxel]

Awesome info folks! Thank you! Happy to take other feedback as well as people think about it more or catch up on their GitHub alerts. 😁

[boyvinall]

I have a MacBook at work and want to VPN to it from home and edit stuff. Mac has no (free) equivalent to RDP (no, vnc does not count as it doesn't handle multiple screens at work rendered on single home laptop screen) so this would be great there too.

[ghost]

@boyvinall teamviewer is free for personal use and handles multi screens on mac (no advertisement here)

[pingec]

I travel a lot and work remotely. Part of my build process is downloading latest libraries on which my project depends on. These libraries can be huge (50+ MB of DLLs) and can change hourly,

Sometimes my internet connection is slow and it is impossible to download them locally. My solution is to rdp into a workstation close to the source of the libraries and code + build on that remote machine. But then I have another problem, if the latency is bad coding over rdp becomes a nightmare.

Liveshare has helped me in this scenario, now what I do is rdp to the workstation and start up the liveshare session. This is an improvement, but still tedious to setup every single time.

Being able to have a headless liveshare server near the source of the libraries would make this setup perfect for remoting.

[tibaes]

I would use it with Docker, so I could code & debug in the exact same environment as the production one. It is possible to use Docker with X, however it not as usable as a "local" editor.

[Chuxel]

This is all great info folks! Appreciate the insights.

@boyvinall and @pingec Out of curioisty, in your situation are there requirements that make it necissary to connect specifically to the work MacBook/workstation similar what @DotNetRussel or @Codelica mention? Or would the idea @fiesel and @ruohki mention of a cloud based workspace you could connect to from anywhere be closer to what your ideal situation?

@tibaes Totally makes senese. One follow up quesiton, Microsoft also has Azure Dev Spaces which pushes code as you edit it out to a cloud Kubernetes cluster where the build and deployment happens. It then establishes a debug channel and you then work in a prod-like environment. Ignoring what orchestrator you use for a moment, is this kind of workflow appealing or are there things that come to mind that only editing inside the container would allow you to do?

[pingec]

@Chuxel the workstation I connect to cannot be cloud-based, it has to be setup locally on-premise because of work policies and because it has to be physically located close to various resources (machines and files), that is one of the main benefits of such setup.

[boyvinall]

@Chuxel I use the macbook all day so all the working directories are in a particular state. Sometimes when working remotely I'll commit push everything then pull down onto the laptop but other times I don't want to. Also, the git server is internal so not accessible from a cloud space without yet more hoop jumping.

@Botkoenig Didn't know teamviewer coped well with multi/single screens but TBH I try to avoid it for anything except last resort. I simply don't like the idea of a publicly-exposed thing sitting on my work network, no matter what the passwords are.

[Chuxel]

@boyvinall @pingec Makes sense! Doing dirty commits to move code betweens machines can be annoying and given I work remotely I can totally relate to the challenges of accessing on-prem resources. Thanks for the insights!

[colek42]

@Chuxel, One thing that this could also help with is developing inside a Docker container. You can see @campoy struggle with it here: https://www.reddit.com/r/golang/comments/92izhx/justforfunc_live_getting_started_with_tensorflow/ being able to have some sort of a live-share daemon run inside the container would allow developers to have self-contained dev environments inside of Docker containers irrespective of tools/libs installed on their host machine.

[wwwouter]

+1 for dead easy docker setup

I'm using Node and NPM is a security nightmare. Working inside a container would it a little bit less dangerous.

[Chuxel]

@colek42 @wwwouter Thanks for the insights, makes sense!

It sounds like you may have tried to work in this way (or are now). Out of curiosity, are you currently / thinking about to having the tools/CLIs/etc in a container with a volume mounted local filesystem or in your mind is the ideal solution that source code is in the container as well?

Similar to above, would your ideal be that the container runs locally, on a remote server, or in the cloud (e.g. the EC2 example in the tensorflow example)? @colek42 given your previous description of using VMWare, I'm assuming you're thinking about hosting the containers in a private cloud, but I don't want to put words in your mouth. 😊

[colek42]

I am actually on a new team now. I develop on my local machine for the most part now, but isn't it really a matter of how you mount the container and do forwarding? Very high, level I would envision some sort of "Remote Workspaces" these workspaces would have whatever context the live-share daemon running in. If the daemon is running inside a container then you would get that container's shell and access to all of the tools installed.

[wwwouter]

I'd like to answer your multiple choice question with a 'yes' 😄 Best case would be having the option to work disconnected on a local machine and the combination of a cheap Chromebook and a container in the cloud. This could be EC2, or maybe something more geared towards this usecase.