Live-share: 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 [e-mail] 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...

1. Remote git operations over LiveShare
2. Remote find operations over LiveShare
3. 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.

[Chuxel]

@colek42 @wwwouter Yep, totally understand. Part of the reason I'm asking is so we make sure we've got an understanding of the nuances of the problems you are trying to solve in your specific situation without throwing our biases in by accident. Occasionally there's additional things we'd need to nail to really meet the need we might not realize otherwise.

[eiva]

This will be a really cool feature!
Some of the projects I'm working with lives in some kind of "developer-hostile" environment:

• I can build and run apps only on a remote Linux host.
• I can't run any kind of UI on that host due to some limitations.
• I have no sudo access to that host.

So being able to run "live share" with an ability to edit, build and debug (or attach to the debugger) with VSCode/VS will be really appreciated.

[Chuxel]

@eiva Thanks for the feedback! That's really interesting. Out of curiosity, are things locked down for security reasons? Also, are these on-prem servers or VMs (or something in the cloud)?

[eiva]

@Chuxel This is on-premises hosts, and main reason for such kind of lock is due to security and regulatory requirements, in addition we have regulatory requirements for "developer hosts" which not allow us to get Linux on dev boxes...

[lcswillems]

@Chuxel Is there any advance on this topic?

Actually, I work with a friend on a file I host. The problem is that, when I am not connected, my friend can't access my file. This is really annoying.

[Chuxel]

@lcswillems Let me see if I'm understanding you correctly.

Today, Live Share focuses on real-time collaboration where both the host and the guest are present. Once done with the real time session, you would then typically commit the result to source control which then allows you to interact asynchronusly through something like a pull request. You can then reconnect later based on the latest changes in source control.

If I undertsand correctly, in your use case, you're interested in a way to let people opportunisitcally collaborate by popping in-and-out of a collaboration session as they are available - including the host. Is that correct?

For "opportunistic" collaboration, you can almost do this in a round-and-about way by placing your source code on a server, container, or VM somewhere (e.g. in the cloud) that running an OS that has a desktop you interact with (Windows, Linux w/Gnome, KDE, Xfce, Budgie, etc). You then start up VS Code on the server/VM/container, start Live Share collaboration session, and leave it running. Everyone then connects to the server using the generated collaboration session link. The source code is edited and maintained entirely on the server environment.

The idea described in this issue would allow someone to set up a "headless host" that someone could connect into that no longer requires a graphical desktop environment. A big area this can be useful is when you are actually working on your own but need to interact with a different machine, OS, device, etc as many of described. However, in concept it could also allow you follow the process above using a server/VM/container that didn't have a desktop.

Is that sufficient for your needs, or are you looking for something more or different?

[lcswillems]

Thank you for your detailed answer!

The issue in my case is that I don't have a remote server with a graphical interface... So I don't know how I could start this session on the server?

[Chuxel]

@lcswillems Bummer! Unfortunately, we do not have a great answer for you on this at the moment which is why we're tracking this as a feature request. That said, as you can see we're actively looking into it. Thanks for confirming your scenario!

[lcswillems]

Okay, I understand, thank you for the time you took to answer me :)

And good luck for this amazingly great project!

[elonmallin]

Would really like to be able to do this with a simple command like mentioned above. Something like:
vlsl /folder/to/share
Or with docker:
docker run -v /folder/to/share:/vlsl -p 12345:12345 vlsl which just outputs the url to join the session with.

Maybe an optional password param makes sense so you need more than a random url to join? Maybe that already exists for the VSCode/VS versions, not sure. Either way, this whole thing would be awesome.

[Al12rs]

This is something that has basically no competition at the moment. The ability to easily and effortlessly work on your remote development environment (without need of host).
I'm just a student but I find myself looking for such a solution. I have different projects on my desktop computer, some in a Linux VM running on the same machine. Though during the week I live in an apartment in the city of my university and only have my laptop with me.
The laptop is not powerful enough to host the VM, also the other projects have big dependencies and setups that I can't easily setup other places (it's literally a limiting factor for number of new collaborators). So live share is really awesome as it means I don't have to set up the environment but still work.
Currently I'm using TeamViewer to connect to the remote pc and start the session with VSLive Share. Or open the VM and start the session from there.
Trying to code working on a limited VM, while using team viewer to access the VM host on slow connection, it's just a nightmare.

I would really like the option to just set up the project to be shared, leave the machine, be able to connect to it with VS Code from my laptop, potentially toghether with other people.

The use cases for this feature are a lot and really there is currently no competition.

[ghost]

@Al12rs there is definitely competition. Cloud9 is one of them. but they chose the web interface over a dedicated client like here. Same goes for Eclipse Che.

[Codelica]

@megaxlr unless those Web IDE have progressed since I last looked, they require a full local instance on each host you want to edit. (Unless you want to start getting creative with Fuse or similar, which could probably be done with Code also but would be ugly.) Vs a lightweight agent install like (I think) is being proposed here.

[DanielKristofKiss]

@Al12rs Nuclide remote project offers something similar. Project is recently retired. Less functionality works with the remote but session can be lunched remotely.
https://nuclide.io/docs/features/remote/

Right now I also manually start the VSLive Share on the server far away from me.

[Al12rs]

Thanks for all the suggestions, I still feel like a solution like the one describe here would be more accessible to a lot of users, I really hope this will be a thing.

[tiagoad]

I'm not sure if this belongs here, but I've been thinking about this idea for a long time and I thought of implementing such a thing simply by running a remote electrum app which streams the vscode HTML/CSS/events over, making a very thin client which supports every feature (being heavily limited by latency, of course.)

I hacked together a little proof of concept using the chrome dev tools protocol to forward the DOM from vscode to chromium and mouse events from chromium to vscode. It's a bit clunky right now but shows some promise if anyone would like to move in this direction.

Some things don't work by simply copying over the HTML (namely the terminal, context menus, some icons), but most of the interface is nicely reproduced in chromium. Keyboard events aren't implemented but it's very easy to add.

Here's a little video, it's a bit slower than normal as my CPU wasn't coping with all of this running along with the screen recording: https://streamable.com/gc1n7
And here's the code, the vscode window URL is hardcoded for now, so you'll have to change it: https://gist.github.com/tiagoad/2a2305a9156dea0e425fd57332a951e8

[andreimc]

I sorta did a proof of concept using x and vnc + some other plugins to see how live share would work. It actually works really well. Here is an example. I used ubuntu with cloudinit.

https://github.com/devbox-hero/ansible-roles

[kirbiyik]

Thanks @andreimc, unfortunately the development of this feature is too slow which forced me to abandon VSCode. Let's see when this will be released...

[jpambrun]

I stumbled on that this morning, it might be interesting to some: https://github.com/codercom/code-server

[louisabraham]

@jpambrun this is a good beginning, but not exactly the same. It's much heavier and a bit slower for the user to handle everything but the front on the server.

[jpambrun]

@louisabraham I understand, but it's basically headless vscode. It might be possible to start a live share session and have both the web and live share frontends. It definitely brings us much closer..

[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 https://github.com/codercom/code-server/issues/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: https://github.com/Microsoft/vscode-remote-release/issues/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 :+1:!

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 https://github.com/microsoft/vscode/issues/66814#issuecomment-507691294

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][1]][[2][2]], also the issue opened by @unixfox , #2128 ?

[hickeng]

This use case may be covered by the newly announced Codespaces[[1](https://github.com/features/codespaces)][[2](https://visualstudio.microsoft.com/services/visual-studio-codespaces/)], 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-hosted[1] 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.