Live Share looks good to me but I was wondering will there be any focus on not sharing stuff but working on remote machines? As remote desktop tools tend to be slow via network and Live Share can be used to avoid remote desktop in a way will there be some focus on developing VS/VS Code in a way to just connect to remote machine VS and develop then compile and run on remote machine but through GUI of your own VS on your own machine?
I had a job where I used remote desktop in order to avoid having code on my machine (company rules). Now it was frustrating as graphics was lagging. I wanted to test live share but client was again like don't do that just keep it on virtual one. Although some clients will still refuse to have that maybe some will agree to have all the code on remote machines and jet be able to just connect GUI to that code while debug/deploy/run would be still executed on remote machine.
I build developer tools and services at Microsoft (currently Codespaces, Live Share, IntelliCode) and maintain some OSS projects (CodeTour, GistPad, CodeSwing, WikiLens)
Hey! Yes, this is definitely something we’re looking into. Being able to have a “headless” Live Share session is currently our most upvoted GitHub issue, and we hear this request very frequently 😁
In the meantime, if you used Live Share as a solution, all of the code, build, run, etc. would already happen on the remote machine. So I’d be curious to know whether that would work as a near-term option.
Yes of course and thus I was wondering about option just to fire up VS localy and connect without having to run remote desktop to allow myself and run VS remotely.
I build developer tools and services at Microsoft (currently Codespaces, Live Share, IntelliCode) and maintain some OSS projects (CodeTour, GistPad, CodeSwing, WikiLens)
Got it. We’re using the GitHub issue I mentioned to track this, and we’ll keep everyone posted. This is definitely a high-priority area for us.
Just to confirm: is the main reason for you wanting to work from a remote machine due to a client policy (is this for freelance/contract work?) that doesn’t allow you to have the source code on your private machine?
Live Share looks good to me but I was wondering will there be any focus on not sharing stuff but working on remote machines? As remote desktop tools tend to be slow via network and Live Share can be used to avoid remote desktop in a way will there be some focus on developing VS/VS Code in a way to just connect to remote machine VS and develop then compile and run on remote machine but through GUI of your own VS on your own machine?
I had a job where I used remote desktop in order to avoid having code on my machine (company rules). Now it was frustrating as graphics was lagging. I wanted to test live share but client was again like don't do that just keep it on virtual one. Although some clients will still refuse to have that maybe some will agree to have all the code on remote machines and jet be able to just connect GUI to that code while debug/deploy/run would be still executed on remote machine.
Hey! Yes, this is definitely something we’re looking into. Being able to have a “headless” Live Share session is currently our most upvoted GitHub issue, and we hear this request very frequently 😁
In the meantime, if you used Live Share as a solution, all of the code, build, run, etc. would already happen on the remote machine. So I’d be curious to know whether that would work as a near-term option.
Yes of course and thus I was wondering about option just to fire up VS localy and connect without having to run remote desktop to allow myself and run VS remotely.
Got it. We’re using the GitHub issue I mentioned to track this, and we’ll keep everyone posted. This is definitely a high-priority area for us.
Just to confirm: is the main reason for you wanting to work from a remote machine due to a client policy (is this for freelance/contract work?) that doesn’t allow you to have the source code on your private machine?
Correct. Main reason WAS client policy. Currently I have no such problems but I guess it's not the "one of a kind" client.