vscode-remote-release

vscode-remote-release copied to clipboard

Currently the Remote - Containers extension supports Linux based containers with the exception of Alpine (though Alpine is highly requested #54).

This issue is to track interest in support for Windows Containers.

this error occurs on a linux container as well.

@akash3456 That's a separate topic from Windows containers. So we can reactivate your issue rather than using this one.

I've got into that restriction last week when working on a project where I had to create a container with a number of 3rd party components then find out why the code that I developing with those components where not working. So +1 to the support request.

@Chuxel how far away is this or what needs to be done? I'd be happy to try to help if possible

I would enjoy this for testing Powershell DSC in fast iterations

One of the main features of our software is that it runs anywhere (Windows, Linux, Mac, Android, etc.) giving customers an incredible amount of flexibility. However, a major issue that we have is having to support multiple code repos with completely different CI systems for each platform. It sometimes requires developers with specific skill sets to work on a particular platform.

We are trying to embrace this idea of a common code repo and CI pipeline for as many platforms (or at least the major ones: Windows, Linux, Mac) as possible. If Remote Containers were able to support Windows and Mac containers, this would be a giant boost towards that goal. It would allow us to offer the same consistent developer experience across all these platforms. It would also allow developers to build features for all platforms at the same time with very little effort!

Hello @Chuxel. Please, could we get an update about the progress on this topic? I think for many of us it is one of the strategical building blocks and I would like to know if the support of Windows Containers is still planned and thus relevant or not.

This feature would require a significant amount of work given the number of commands that need to be fired inside of the container to do various tasks that rely on shell commands. Unfortunately the feature would only work for Windows users with Windows 10 Pro and up (given Hyper-V is required) and these containers cannot run on macOS or Linux. (Docker for WSL2 opened up Windows Home for Linux.) As a result, it's not currently on our 2020 roadmap.

OK @Chuxel, I can see... Thanks for the valuable input!!!

This feature would require a significant amount of work given the number of commands that need to be fired inside of the container to do various tasks that rely on shell commands. Unfortunately the feature would only work for Windows users with Windows 10 Pro and up (given Hyper-V is required) and these containers cannot run on macOS or Linux. (Docker for WSL2 opened up Windows Home for Linux.) As a result, it's not currently on our 2020 roadmap.

@Chuxel , I'm not sure I understood what you meant in your reply. I'm wondering if maybe you guys misunderstood what I was originally suggesting. Here is what I was trying to suggest:

Say I have a repo that contains C/C++ code for a client application. This application is supported on multiple platforms (Windows, Linux, Mac). I have 3 different teams submitting changes to this repo. Team W checks out the repo on a Windows machine and builds the Windows version of the client (using Visual Studio 2017 compilers) and tests it on Windows. Team M checks out the repo on a Mac machine and does the same for their platform. Team L does the same for Linux (using gcc compilers).

The problem is that each of these teams has a totally different experience when it comes to build this code locally on their own machine. It is kind of hard to main 3 totally different build systems. On top of that, the CI/CD system for each of these platforms is completely different.

To simplify the developer's life, we wanted to use Remote Containers. We could potentially create 3 different dockers, one for each platform, that would have all the necessary build tools already setup and ready to go. The developer would simply checkout the repo, open VSCode, connect to the corresponding container for the kind of machine they are using at the moment, and initiate a build command (using something like cmake for example). The developer would not have to worry about setting the machine up with all the necessary tools to build. The BIG problem is that Remote Containers seems to be supported only for containers of type Linux. In other words, a developer on a Windows machine cannot connect to a Windows Remote Container to build, or a Mac developer on a Mac machine cannot connect to a Mac container to build.

Using a docker container to build the code would also simplify the CI/CD system itself.

@alegnicitrix This feature request is above windows containers - everything above applies there. To be clear, you can use Windows, macOS, or Linux with Linux containers today. The comments above still apply to Windows containers, which to be clear are not full windows but run a special flavor of windows, so last I checked, you can't RDP into them for example. Windows containers can also only be used from Windows - you can't use them from macOS or Linux. I'm not aware of any Docker support for macOS containers, and even if there was, Apple licensing undoubtedly would lock them to mac hardware like VMs.

@Chuxel,

Right, I'm not suggesting RDP into the containers. As you mentioned, the Windows docker are not the full Windows OS. I'm also not suggesting that from a Windows machine you connect to a Mac docker (this is obviously not allowed by Apple).

Remote Containers only seems to support the following, which only allows you to produce Linux binaries:

• from a Windows machine connect to a Linux docker
• from a Linux machine connect to a Linux docker
• from a Mac machine connect to Linux docker

I am suggesting the following support to be added to Remote Containers:

• from a Windows machine connect to a Windows docker (so that we can produce Windows binaries)
• from a Mac machine connect to a Mac docker (so that we can produce Mac binaries)

The developer's machine would only need to have VSCode installed (which serves as the frontend UI for the developer), with the Remote Containers plugin. My cross-platform repo where we contain C/C++ code for all platforms would contain the custom docker files (one for each platform, customized to have the VSCode backend, cmake, the various build tools needed to produce binaries for each platform, + additional tools that may be specific to my company that may be part of the build process).

• from a Windows machine connect to a Windows docker (so that we can produce Windows binaries)

This would be very helpful to our organization as well. We would be able to distribute local development and operations environments very efficiently.

I need vscode remote container with a windows image to:

• run the tests on the products in an environment that is mirror of the servers of my clients
• allow the developers in my team to develop directly in this environment

If vscode supported remote connecting into a Windows Container I could create docker images that devs could use to build a given project under Windows. Then the dev could simply have just to install docker desktop (enable Windows Containers) and vscode (with various plugins). Nothing else is needed. As dev tools change I can just update the docker image and have devs fetch that latest version. Working on different branches/projects that use different tool chains and versions of those tools becomes much more doable. Without this support I could still have the docker image but it is much less useful because for vscode to work correctly the devs have to have all the correct tools installed on the host as well as the Windows Container. And if they are working on different projects/branches that use different tool sets this makes life hard. Running vscode in the correct context where it has access to all the tools (at the correct versions) that the various plugins use to do their jobs is the goal here.

The usecase described by @alegnicitrix and @tst-rwildes is very relevant for us also.

VSCode is giving first class remote support to linux containers and linux servers with remote-SSH, remote-WSL and remote - Containers but Windows is nowhere in the ecosystem. Not looking at RDP to windows servers / containers but just providing a remote dev environment where .NET framework or similar apps can be compiled and developed

As we move to remote development models where all dev work is done remotely and we have automated builds and dev environments described in code as dev containers in json to improve our dev experience, we just can not replicate this for windows devs right now.

Would it help if the focus is initially just for windows platform only?

Even though using Linux Containers on a Windows host has greatly improved with WSL and WSL 2, it comes with performance issues and a few caveats (e.g. Docker in Docker).

For some languages/frameworks, developing in Windows is perfectly fine. Hence, using the same OS as the host system would make life way easier for developers while greatly improving performance in some cases.

This might merit a separate issue, but: Can we warn the user that Windows Containers aren't supported?

My experience was seeing this:

Then seeing this in the logs:

container [....] encountered an error during hcsshim::System::CreateProcess: failure in a Windows system call: The user name or password is incorrect. (0x52e)

Which led me on down a user name / password rabbit hole until I stumbled upon this issue, which seems to indicate that this just isn't supported at all?

I would like to use this feature to help myself assemble Windows CI images and pipelines. Debugging DLL loading issues which only arise inside the container without developer tools is no fun. I would like to use my debuggers inside the container to see how exactly my program crashes and burns.

hi, have any news on implementation plans?

One more user looking for devcontainer support for Windows Containers.

I thought I'd dip my toes into devcontainers and got a good Dockerfile setup where I could build and test my .NET Framework project and Windows PowerShell module. But when I tried to open the remote devcontainer, I ended up with an error that suggested the expected container OS was linux. I tried setting my own workspaceFolder and workspaceMount values in the devcontainer.json file before eventually coming upon this thread.

remoteContainers-*.log

[2022-03-19T04:57:55.072Z] Command failed: docker run --sig-proxy=false -a STDOUT -a STDERR --mount type=bind,source=c:\repos\myapp,target=/workspaces/myapp,consistency=cached --mount type=volume,src=vscode,dst=/vscode -l vsch.local.folder=c:\repos\myapp-l vsch.quality=stable -l vsch.remote.devPort=0 --entrypoint /bin/sh vsc-myapp-7ea61046487d0e15a13ab44a868bb0d3 -c echo Container started

After spending a few hours, I also landed here. Be nice if it could at least detect whether it was not supported to prevent these hours being spent.

Can we base of the mono image to spin up .net framework4.8 in wsl2 and remote ssh to that? Would that work…

edit:

found a repo that looks like it’s been achieved, going to need some spit and duct tape though,

https://github.com/hamedhajiloo/mono-nginx-dockerfile

I too have a use-case for Windows Dev Containers. I'm curious what the limitation is here and why there seems to be low interest in supporting this feature?

3+ years later, still no support? What have people been using in the mean time?

3+ years later, still no support? What have people been using in the mean time?

I'd moved all development to Ubuntu...

I'd moved all development to Ubuntu...

Some of us don't have that flexibility and still require the use of a win container for one reason on another (i.e. dependency on .NET Framework).

3+ years later, still no support? What have people been using in the mean time?

You can still SSH into the container if you have OpenSSH or similar running in it: https://github.com/erri120/ModOrganizer-Docker/blob/master/Dockerfile.Dev

Since it has been a bit since we've provided an update here and a frequent question has been "when," I'll mention that we do not have a specific timeframe to pick this up. Since there's been a few questions as to what it would take:

1. The first step would be to update the dev container spec (https://github.com/devcontainers/spec) with a proposal for how to manage the Windows specific aspects of the problem.
2. Next, the dev container CLI would need to be updated with a reference implementation (https://github.com/devcontainers/cli - which anyone can contribute to given it is OSS).
3. A set of windows-specifc samples, templates, Features, and other content would need to be developed given they would inherently all differ from Linux.
4. Finally, each tool or service including the Dev Containers extension would need to make sure its behaviors (and hosting environments) supported it, and commit to maintaining it long term.

Part of the challenge is that Windows Containers are bigger to start cannot do everything a VM could do like Linux containers can. In particular, they cannot support RDP (or running GUI-based apps) which is often one of the first questions raised when considering containers as an "inner loop" development environment - particularly given desktop apps are one of the considerations that drives interest. Instead the focus has been the Remote - SSH extension and the more recently introduced Remote - Tunnels extension since both of these provide a way to use VMs as well.

My team builds C++ libraries that support both Linux and Windows and Windows support for devcontainers is vital for us.

Devcontainers have been a game changer for us and we are huge fans. They have enabled us to craft a solution that significantly simplifies local development, CI environments, and set up for first time users.

However, there is a massive gap in that story when it comes to Windows.

What are the developers on my team supposed to use for developing and triaging issues in Windows?

What should we use for the environment of our CI jobs on Windows runners?

We've invested heavily in building all this unified infrastructure around devcontainers, but it is effectively worthless for an entire axis of our support matrix.

I would think Microsoft would have a vested interest in supporting its own OS :slightly_smiling_face:.