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 ***@***.***> 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 <#74 (comment)>, 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. Guests cannot see or perform file operations like rename, delete, or add #44 - Guests cannot perform file operations like rename, delete, or add
2. No support yet for find in files, replace in files, and related multi-file search features not backed by a language service/server #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. Allow guests to start a build or debugging session on the host's behalf  #32 - Allow guests to start a build or debugging session on the host's behalf (also covers "attach")
4. Build output is not available to guests #48 - Build output is not available to guests

VS Code specific:

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

VS specific:

1. [VS] Navigate To does not function as expected for guests due to missing backing implementation #76 - Navigate To does not function as expected for guests due to missing backing implementation
2. Support "Solution View" in the Solution Explorer for guests in VS #31 - Support "Solution View" in the Solution Explorer for guests in VS
3. Allow guests to use package and reference management UI in Visual Studio #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.

[louisabraham]

@jpambrun didn't see it like that. You have a point here! :)

[bcurless]

@jpambrun Were you able to figure out if the Live Share extension could be added and functional on code-server? From what I see, its missing from the extensions list, (mainstream marketplace unsupported), although as I understand it, it may be able to be loaded manually if you have the .vsix file?

[wolf99]

@bcurless coder/code-server#33

[ghost]

Maybe it would be nice if it would have two "servers". a "source" and a "tunnel". like what TeamViewer does. So you don't need to modify firewall rules on a source server.

The source and the client would "meet" at the tunnel server instead of directly at the source. and then the tunnel could handle deadlocking between clients when they try to edit the same line?

[Chuxel]

I'm super excited to let everyone know about the public preview of a set of Visual Studio Code Remote Development extensions available now from the marketplace. Out of the gate we have support for SSH, Containers, and WSL.

🔗 Extension pack: https://aka.ms/vscode-remote/download
🔗 Blog post: https://aka.ms/vscode-remote/blog
🔗 Docs: https://aka.ms/vscode-remote
🔗 Feedback: https://aka.ms/vscode-remote-release

We're closing this issue for now with the launch of this effort, but we'd love to hear your feedback!

[Codelica]

I will name my next child VSCode if you add ARM support. 👍

[Chuxel]

@Codelica 🤣🤣 Love it. Feature request is here: microsoft/vscode-remote-release#13

[tiagoad]

Very unexpected, and immensely useful. I was really happy to get this e-mail notification, it's seems really well thought out, great work.

[unixfox]

@Chuxel All of these new extensions are really great for solo development 👍!

But they don't really solve the initial issue where it was asked to have an independent live share server that could be hosted on a remote (headless) machine where developers could develop together.

The thing is I don't find any real collaboration feature in these new extensions, the SSH remote extension is great for accessing a remote directory from vscode but not for simultaneous edit of a same file by multiple developers at the same time.
For example what would happen if one developer save an edited file that another one has already opened? Is vscode going to automatically merge the changes of the first developer on the second developer vscode program like it's already the case on the current Live Share implementation?
If I'm not mistaken the changes from the first developer won't be merged in the second developer vscode program and then when the second developer will try to save the file this will then ask the second developer to resolve a save conflict, which is not really collaboration friendly.

Please correct me if I'm wrong but that's what I tough when I subscribed to this issue.

[wolf99]

@unixfox does vscode-remote plus LiveShare cover this?
e.g. first developer sets up remote, then shares it to other developers...
Not even sure if this works, just a suggestion to try.

[Chuxel]

@wolf99 @unixfox This issue ended up covering quite a number of different scenarios over time - which is part of the reason we opted to close it at this point and open new ones for anything people still felt were gaps that needed to be addressed. (And we really appreciate all the feedback!!)

Here's where things are:

1. You can develop solo with these extensions.
2. You can install Live Share on a remote host using these extensions. You first connect to the remote machine, install the extension (the first time you connect), then start up a Live Share session to invite others. There are some hiccups in the experience while we are in preview, but the goal is to smooth those out (e.g. your local credentials aren't reused yet).

The one thing we do not have yet is the ability for the host to leave and let the guests keep going. If that is the critical thing you are looking for, we should absolutley spin up a feature request on that. Is that the piece you are looking for?

[unixfox]

@Chuxel
Thank you for your complete reply.

The one thing we do not have yet is the ability for the host to leave and let the guests keep going. If that is the critical thing you are looking for, we should absolutley spin up a feature request on that. Is that the piece you are looking for?

Yes that's mainly the reason why I subscribed the issue, to have some kind of live share server that would stay running in background where developers could join whenever they want to develop without having the host connected.
Should I open a new issue for that?

[Chuxel]

@unifox That would be awesome! Thanks so much!

[louisabraham]

A person mentioned https://coder.com
I just saw https://www.theia-ide.org/ which does about the same thing (serving vscode over the browser).

[hickeng]

I am using WSL Remote as we speak, but this is different from my desires for headless liveshare. Cross posting from microsoft/vscode#66814 (comment)

Headless liveshare is slightly different IMO.

With remote the developer still has to know all of the details of the remote server and have permissions on it.
With liveshare it's possible for one person to set up the headless server and for many to connect, while knowing nothing but that it's a vscode remote environment.

Think of it this way (and this is something I've wanted for a while) - an option on github repos to "enable liveshare", resulting in a hosted dev environment that is launched on the backend simply by the devs attempt to connect to it, and garbage collected after xxx time without active clients.

• maintainers would be able to get read-only or read-write sessions.
• public would be able to get read-only sessions.
• session per branch.

This is not something I think the vscode remote is ever going to be able to do as the entire approach is > inverted.

Regarding billing being free, flat rate, metered, pay-by-project, pay-by-client!, or other I've not given much thought, but I would be willing to pay for this as a service myself.

Would drastically improve my PR review workflow if this was available.

[Trolldemorted]

@Chuxel can we reopen this?

[wolf99]

This use case may be covered by the newly announced Codespaces[1][2], also the issue opened by @unixfox , #2128 ?

[hickeng]

This use case may be covered by the newly announced Codespaces[1][2], also the issue opened by @unixfox , #2128 ?

I think headless is different from allowing sessions to continue - that implies that new users cannot connect, and honestly likely has some serious issues with permissions and identity.

Code spaces is the same use case I think, but doesn’t seem to allow for self hosting. Closer, but not clear what that means for proprietary code.

[david50407]

Codespaces seems allowing to be self-hosted1 with Azure account, but I'm considering is that free to my Azure account when I only use Codespaces with my self-hosted server?

[wolf99]

Codespaces seems allowing to be self-hosted1 with Azure account, but I'm considering is that free to my Azure account when I only use Codespaces with my self-hosted server?

Nice info @david50407 . I too am confused as to why self-hosted Codespaces would require an Azure account. Take a sample use case: an IPR sensitive code base that I may work on as employee of a company,obviously code should not be worked on in a 3PP provider (e.g. Azure) and as such the employer would have no reason to pay for an Azure account. Maybe Azure accounts are free, I have no idea but it is beside the point because as the employee I too would not even sign up for an Azure account to work on my employers code.

On the flip-side, if I was working on non-IPR sensitive code in an open source project or something, then azure hosted service might be more appropriate.

[lostintangent]

Hey all! Just to confirm: self-hosted Codespaces are entirely free, and you can create a free Azure account as well, so there's no payment of any kind that you'd need to start using them. Also note: just because we're currently requiring an Azure subscription, doesn't mean that your code is actually stored or sent to Azure in any way. With self-hosted Codespaces, you control/manage the environment, and Codespaces is simply providing the "anywhere accessibility" of it by means of the same cloud relay networking that Live Share uses (which is fully E2E-encrypted, and never stores code/actions anywhere).

The reason this issue was closed is because the Live Share team is also the Visual Studio Codespaces team, and it's the later that is our focus for enabling remote development (as opposed to real-time collaboration). So we'd love to keep this conversation going, but any improvements we do here would likely be in Codespaces (w/Live Share being a hugely complimentary part as well) 👍

[david50407]

@lostintangent maybe we can re-open this issue since Visual Studio Online Codespaces is going to be consolidated into GitHub Codespaces without self-hosted solution...?

[JustinGrote]

Agreed, @lostintangent now that VSO codespaces is going away, I would like for the VSOAgent to be modified to be able to sign in using Device Code flow (and preferably maybe unattended approach in the future) to my live spaces area and present a URL that I can use to connect as if I was joining a collaboration session

[lostintangent]

Since Live Share is focused on enabling collaboration scenarios, and Codespaces is focused on enabling remote development, I think it makes sense to keep this issue closed, and move the discussion to here, as part of the conversation about the GitHub Codespaces roadmap. The team will be keeping track of that item and will be posting any updates on self-hosted support in Codespaces moving forward.

[AverageComet250]

Hate to revive dead threads, but I think this thread is a better place to go instead of a new thread.

Since Vs codespaces are no longer available and gh codespaces are in beta, what is the best option for having a vscode server that people connect to with a link? Also, I have projects that I don't want on gh and want only on one device, so using gh codespaces is a no go for those projects, and I can't find any alternatives. Since live share is basically a codespaces a light weight codespaces server can we have this detached and made standalone so that people can still self host codespaces.

[derekbekoe]

For anyone still interested in this scenario, VS Code has announced The VS Code Server - https://code.visualstudio.com/blogs/2022/07/07/vscode-server

[SichangHe]

Hi, I came up with a hack to run VSCode persistently entirely on a server without GUI. Please see Running Live Share on server for collaboration - Steven Hé (Sīchàng) for the process.

Please leave any feedback or comment below that page. Thanks!

Steven Hé (Sīchàng)