3 ms·

I'm not sure I follow -- do they suggest running VS locally, and the work/project inside the container? I've been doing this for years, it seems to me like the

I'm not sure I follow -- do they suggest running VS locally, and the work/project inside the container? I've been doing this for years, it seems to me like the absolutely hands-down easiest way to keep projects encapsulated and easily shareable with coworkers. Set up the env in a docker container, mount a volume to a local fs where all the sources live, ssh into the container if necessary, interact with app(s) within the container over http. What's MS adding here, what am I missing? They streamline the process and integrate scripts with VS?

akfrt 2y ago
They are not adding much. It is still Docker, the feature is from 5 years ago. But anything with VS(Code) is hyped up, since half of the OSS ecosystem is now on the take, directly or indirectly, from MSFT. Until MSFT pulls the plug.
emmanueloga_ 2y ago
The missing piece is that the IDE runs on the same environment as your code (0). This is useful, for instance, to communicate with the various LSP services [1] VS Code may need in order to provide proper support (auto-completion and all sorts of other IDE features). I mean, even something as simple as "Run this file" may not work if you just mount the folder somehow. There are other goodies but those are very VS Code specific, like the ability to describe which extensions are used on the DevContainer, that way you can very quickly have everyone in your team use the same extensions and also avoid having a globally installed extension that you only need for a single one of your projects. -- 0: not the GUI part, a daemon. 1: https://en.wikipedia.org/wiki/Language_Server_Protocol https://en.wikipedia.org/wiki/Language_Server_Protocol
- btbuildem 2y ago
  Oh interesting... I definitely host the build chain in the container, but the integration between the elements of that and the IDE itself is cool. Who needs globally-installed Prolog extensions when it's just that one legacy project that needs them!

akfrt 2y ago

They are not adding much. It is still Docker, the feature is from 5 years ago. But anything with VS(Code) is hyped up, since half of the OSS ecosystem is now on the take, directly or indirectly, from MSFT. Until MSFT pulls the plug.

emmanueloga_ 2y ago

The missing piece is that the IDE runs on the same environment as your code (0). This is useful, for instance, to communicate with the various LSP services [1] VS Code may need in order to provide proper support (auto-completion and all sorts of other IDE features). I mean, even something as simple as "Run this file" may not work if you just mount the folder somehow. There are other goodies but those are very VS Code specific, like the ability to describe which extensions are used on the DevContainer, that way you can very quickly have everyone in your team use the same extensions and also avoid having a globally installed extension that you only need for a single one of your projects. -- 0: not the GUI part, a daemon. 1: https://en.wikipedia.org/wiki/Language_Server_Protocol https://en.wikipedia.org/wiki/Language_Server_Protocol

btbuildem 2y ago
Oh interesting... I definitely host the build chain in the container, but the integration between the elements of that and the IDE itself is cool. Who needs globally-installed Prolog extensions when it's just that one legacy project that needs them!