You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: blogs/2019/05/02/remote-development.md
+26-23Lines changed: 26 additions & 23 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,48 +14,51 @@ May 2, 2019 by The VS Code Team, [@code](https://twitter.com/code)
14
14
15
15
## TL&DR;
16
16
17
-
Today we're excited to announce the preview of three new extensions for Visual Studio Code that enable seamless remote development in [Containers](https://www.docker.com/resources/what-container), physical or virtual machines, and the [Windows Subsystem for Linux (WSL)](https://docs.microsoft.com/en-us/windows/wsl). You can [get started](#get-started) right away by installing the [Remote Development Extension Pack](https://aka.ms/VSCodeRemoteExtensionPack).
17
+
Today we're excited to announce the preview of three new extensions for Visual Studio Code that enable seamless development in [Containers](https://www.docker.com/resources/what-container), remotely on physical or virtual machines, and with the [Windows Subsystem for Linux (WSL)](https://docs.microsoft.com/en-us/windows/wsl). You can [get started](#get-started) right away by installing the [Remote Development Extension Pack](https://aka.ms/VSCodeRemoteExtensionPack).
18
18
19
19
**Note**: You'll need to use the [Insiders](https://code.visualstudio.com/insiders/) build for now, but remote development support will eventually be available in the Stable release.
20
20
21
21
Read on to learn how we got here.
22
22
23
-
## Remote development
23
+
## Development Trends
24
24
25
-
As the popularity of Visual Studio Code has grown, we've had the opportunity to talk to a broad set of users with different development environments, many vastly different than our own. And what we heard is that more and more development is happening not only on the local machine, but also on remote environments.
25
+
With the growth in popularity of VS Code, we've had the privlidge and opportunity to talk to more and more users with different development environments, many vastly different than our own, to try to identify ways in which we could move VS Code forward to address real developer pain points.
26
26
27
-
Thousands of engineers at large enterprises such as Facebook work remotely against secure and powerful "developer VMs" and cloud-based services that scale beyond what even the best laptop can handle.
27
+
An interesting pattern emerged during these conversations. We saw many developers trying to use VS Code to develop against containers and remote VMs configured with specific development and runtime stacks, simply because it is too hard, too disruptive, and in some cases impossible, to set up these development environments locally.
28
28
29
-
We heard from Python developers who want to switch to VS Code but need to use development environments configured for a specific Python stack using [containers and virtual machines](https://matttrent.com/remote-development/).
29
+
We've all experienced this problem. Unless we feel its time to flatten that machine :) we hesistate to try out a new stack like Rust, Go, Node, or Python3, for fear of "messing up" our current, well tuned environment.
Python developers want to switch to VS Code but can't, because they need to use [containers and virtual machines](https://matttrent.com/remote-development/) as development environments configured for a specific Python stack.
32
32
33
-
Data scientists often need massive storage and compute services to analyze large datasets that can't be stored or processed even on a robust desktop.
And, [the third most commented issue in the VS Code repository](https://github.com/Microsoft/vscode/issues/13138) is to support running `code` from a Bash terminal in a Linux distro on Windows with the [Windows Subsystem for Linux (WSL)](https://docs.microsoft.com/en-us/windows/wsl/about).
35
+
Because the code bases are so large, we see engineers at shops like Facebook (and Microsoft!) use editors like vim to work remotely against secure and powerful "developer VMs", using alternative cloud-based search and navigation services that scale beyond what even the best laptop can handle.
36
36
37
-
> 
37
+
Data Scientists building and training data models often need massive storage and compute services to analyze large datasets that can't be stored or processed even on a robust desktop.
38
38
39
-
WSL is a great way to use your Windows-based tools to build applications that deploy to and run on Linux, and doing development in WSL is really just remote development from a Windows machine to a Linux environment that happens to be running on the same machine.
39
+
The rise in popularity of the [Windows Subsystem for Linux (WSL)](https://docs.microsoft.com/en-us/windows/wsl/about) is powered in part because it makes it easy to set up a contained development environment, including the target operating system. In fact, [the third most commented issue in the VS Code repository](https://github.com/Microsoft/vscode/issues/13138) is to support running `code` from a Bash terminal in a Linux distro on Windows.
40
40
41
-
## Challenges
41
+
> 
42
42
43
-
In these conversations, we also kept hearing the same challenges repeated that developers face with remote development.
43
+
## Challenges with Current Solutions
44
44
45
-
For example:
45
+
Throughout these conversations, we also kept hearing the same challenges developers face with this type of development.
46
46
47
47
* Remote Desktop can work, but it is difficult or impossible to set up on some Linux distributions, and the development experience can be "laggy".
48
+
48
49
* SSH and Vim (or local tools with file synchronization) work, but they can be slow, error prone, and generally [lack the productivity of modern development tools](https://stackoverflow.blog/2017/05/23/stack-overflow-helping-one-million-developers-exit-vim/).
49
-
* It's hard, and sometimes impossible, to replicate different development environments locally (for example, the right framework/tools environment, or a massive source base) to get rich tooling experiences like IntelliSense or linters. It becomes even more challenging when switching between different project contexts.
50
+
50
51
* Browser-based tools are useful in a variety of scenarios, but developers don't want to give up the richness and familiarity that desktop tools provide, or their existing locally installed tool chains.
51
52
52
-
## A different approach
53
+
Worse (in our opinion!) developers had to sacrifice core VS Code experinces like IntelliSense (completions), linting, and debugging, in order to work against these environments.
54
+
55
+
## A Different Approach
53
56
54
57
Hearing about these challenges we started to look into WSL support and it looked simple enough. Install VS Code and ([carefully at the time!](https://devblogs.microsoft.com/commandline/do-not-change-linux-files-using-windows-apps-and-tools/)) edit the Windows file system as normal. We did work to [enable remote debugging for Node.js](https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_remote-debugging), and we figured we could simply install a small script to enable launching `code` from the bash shell.
55
58
56
59
But, it just wasn't right. It didn't make sense to do special work for every runtime, as we did for Node.js debugging. If you have Python 2.7 and Flask installed on Windows (or none at all!) and Python 3.7 and Django installed in the Linux distro, you wouldn't get proper completions or linting because VS Code was looking at the Windows versions of everything. Having to duplicate the development environment on both Windows and Linux defeated the purpose of having WSL at all.
57
60
58
-
We convinced ourselves that what we needed was a way to run VS Code in two places at once, to run the developer tools locally and connect to a set of development services running remotely in the context of a physical or virtual machine (for example, a container or VM). This gives you a rich local development experience in the context of what is on the remote machine.
61
+
We convinced ourselves that what we needed was a way to run VS Code in two places at once, to run the developer tools locally and connect to a set of development services running remotely in the context of a physical or virtual machine (for example, a container or VM). This gives you a rich local development experience in the context of what is in the remote environment.
59
62
60
63
61
64
@@ -75,7 +78,7 @@ Commands and extensions are run directly in the Linux distro, so you don't have
75
78
76
79
Check out this quick, 2-minute video to see how easy it is to develop in WSL.
For more information, please see the [Developing using SSH](https://aka.ms/vscode-remote/ssh) documentation.
99
102
@@ -105,15 +108,15 @@ The **[Remote - Containers](https://marketplace.visualstudio.com/items?itemName=
105
108
* Containers are isolated, meaning you can quickly swap between different development environments without impacting your local machine.
106
109
* It easy for others to contribute to your project as they can easily develop, build, and test in a consistent development environment.
107
110
108
-
A `devcontainer.json` file can be used to tell VS Code how to configure the development container, including the Dockerfile to use, ports to open, and extensions to install in the container. When VS Code finds a `devcontainer.json` in the workspace, it automatically builds (if necessary) the image, starts the container, and connects to it. Your files are mounted into the container so you can open files and start editing with full IntelliSense (completions), code navigation, debugging, and more.
111
+
A `devcontainer.json` file can be used to tell VS Code how to configure the development container, including the `Dockerfile` to use, ports to open, and extensions to install in the container. When VS Code finds a `devcontainer.json` in the workspace, it automatically builds (if necessary) the image, starts the container, and connects to it. Your files are mounted into the container so you can open files and start editing with full IntelliSense (completions), code navigation, debugging, and more.
109
112
110
113
Check out this quick, 2-minute video to see Development Containers in action.
For more information on development containers, please see the [Developing inside a Container](https://aka.ms/vscode-remote/containers) documentation as well as the [vscode-remote-try-* repositories](https://github.com/search?q=org%3AMicrosoft+vscode-remote-try-&unscoped_q=vscode-remote-try-) that contain samples you can use today.
115
118
116
-
## Managing extensions
119
+
## Managing Extensions
117
120
118
121
When developing remotely, VS Code will attempt to infer where to install an extension, locally or remotely, based on the functionality it exposes. Extensions fall into one of two categories:
119
122
@@ -125,13 +128,13 @@ When developing remotely, VS Code will attempt to infer where to install an exte
125
128
126
129
Most extensions have been updated and work properly in a remote environment, but if you encounter some that do not, please do submit an issue on the extension.
127
130
128
-
### Extension authors
131
+
### Extension Authors
129
132
130
133
If you are creating VS Code extensions, we've implemented new extension APIs that are remote aware. For example, instead of using the `open` package to load a browser window, an extension author should use the `vscode.env.openExternal` API, which will open the browser locally. Similarly, there is a new `clipboard` class, which will place contents on the local clipboard, as expected.
131
134
132
135
Many more details can be found in the updated [API Documentation](https://aka.ms/vscode-remote/developing-extensions), including how to run, test, and debug your extension in a remote environment.
0 commit comments