_Copied from https://github.com/dotnet/dotnet-docker/issues/287_
"Visual Studio Container Tools requires Docker to be running before building, debugging or running a containerized project. For more info, please see: http://aka.ms/DockerTollsTroubleshooting
- Installed the Docker Toolbox and installed all options
- Ran the toolbox via the docker quickstart terminal application to launch docker
- Tried to run the project again, and continue to get the same error message.
Here is a stack over flow question I've created and don't seem to be getting any answers. I've tried the suggested information in the SO responses apart from downloading a process hacking applicaiton to check vs environment variables.
I expected docker to work after installing the docker toolbox since I'm running Windows 10 Home edition, and that's what the docs suggested to do since Docker for Windows isn't supported on win 10 home?
repeatedly getting the same error in visual studio, not allowing me to get up and running with Docker in my current project. It doesn't seem to be a code issue, it appears to be a tooling issue.
https://github.com/ddeamaral/LetsMusify --source code
docker versionClient:
Version: 17.06.0-ce
API version: 1.30
Go version: go1.8.3
Git commit: 02c1d87
Built: Fri Jun 23 21:30:30 2017
OS/Arch: windows/amd64
Server:
Version: 17.06.1-ce
API version: 1.30 (minimum version 1.12)
Go version: go1.8.3
Git commit: 874a737
Built: Thu Aug 17 22:54:55 2017
OS/Arch: linux/amd64
Experimental: false
docker infoContainers: 2
Running: 0
Paused: 0
Stopped: 2
Images: 2
Server Version: 17.06.1-ce
Storage Driver: aufs
Root Dir: /mnt/sda1/var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 10
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
runc version: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 4.4.83-boot2docker
Operating System: Boot2Docker 17.06.1-ce (TCL 7.2); HEAD : 80114bc - Fri Aug 18 17:58:04 UTC 2017
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 995.8MiB
Name: default
ID: NFRJ:HKIE:VG3A:Z5VL:3PPN:3DZ4:QUGG:X5YX:LU4Q:2S76:HUAZ:CJPD
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 16
Goroutines: 26
System Time: 2017-08-26T00:08:27.991030674Z
EventsListeners: 0
Registry: https://index.docker.io/v1/
Labels:
provider=virtualbox
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Is anyone able to look at this, or have any suggestions other than forking over $100 for win10 pro?
The Docker tooling in Visual Studio 2017 does require Docker for Windows. Since Docker Toolbox is legacy we chose to support only Docker for Windows going forward. In our latest builds, I verified when adding Docker support we mention in the error message to "Verify that Docker for Windows is installed...". Docker For Windows has both Linux and Windows container modes that our tooling takes advantage of along with other items specific to D4W.
And to my understanding...Docker for Windows only works with windows 10 professional edition correct?
Correct, Windows 10 Home doesn't include hyper-v which is required by Docker for Windows
Well this is unfortunate. Docker uses hyper-v which precludes any other VM and basically locks the whole box down. Docker toolbox is the only workaround, but it doesn't even work. Once again, hampered by M$. I'm so moving to Go. Had enough of this over the years. BTW - toolbox not legacy. It's there to get around EXACTLY this.
I agree with cemdev and should point out that most enterprises especially in my neck of the woods are still on Windows 7, and likely will be for a little while. This creates a significant gap for those organizations who want to start working with Dockerized .NET Core applications. MS would be well advised to drop this seemingly arbitrary restriction and enable their development community stuck behind organizational barriers.
Back to NodeJS and Linux environment...
MS--
I agree @leovolpatto docker for windows totally sucks i have spent more time trying to get past errors such as this recently to come to the decision its just pointless...
One possible solution is to run visual studio ide (e.g. "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\devenv.exe") from cmd where you first ran the output of "docker-machine env". At least you wont see this nasty error message on startup, debugging won't work, though. Argh, never mind, ... it just doesn't work
You can make it work with linux containers using oracle virtualbox on Win10 home.
Stackoverflow has a beautiful description on how to achieve it.
Just enable virtualization, if it isn't already.
Set up toolbox (legacy).
Share drive C in virtualbox.
And everything should works. At least it does for me.
If error still appears. I would suggest checking docker-compose config, if it is not valid VS can return that kind of error.
Hi,
To develop with Docker within a secure network, which does not have a direct route to the Internet, it is not possible to install Docker for Windows. The Docker for Windows installer requires access to the Internet. Therefore, one can only use the Docker Toolbox. The Docker Toolbox can be installed correctly without an Internet connection, but Visual Studio does not recognise that it exists. For example, issuing the docker compose command that Visual Studio tries to run from a powershell window successfully completes, whereas Visual Studio fails to build with Docker compose with "An error occurred while sending the request". Good integration between Visual Studio and the Docker Toolbox would be helpful.
Best regards,
Will
That's it? No comment, no platitudes, no attempt at reconciliation, just an unceremonious closing of the issue with a wontfix label? What do you have to say to your users who are still stuck in an enterprise environment using Windows 7 for whom this is still a blocking issue?
We have no plans to support Docker Toolbox at this time.
Do you support Windows 7 being used in software engineering/devops environments in your enterprise customers? What is the solution for them since D4W is only usable on Windows 10 Pro+? Last I checked you set your EOL for business customers of Windows 7 to 2020.
On Windows 7, you can still use Visual Studio to write code. You can use the VS Docker tools to create/edit a Dockerfile for your project. You can use that Dockerfile to build/run containers outside of Visual Studio. You can use Visual Studio to manually hook up a remote debugger to an application running in a container. All of this is fully supported today. The piece that we have no plans to support is the one-click container build/debug from VS.
I'm not sure if it's mentioned or linked in this thread, but i see a lot frustrated users so i'll just leave it here:
vs, placed it somewhere under $PATH and run it like cd /c/stuff/app && vs app.slnvs contents: nohup /c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio/2017/Professional/Common7/IDE/devenv.exe "$@" >/dev/null 2>&1 &
Docker Inc is extremely clear that Docker Toolbox is legacy. The note at the top of the overview doc page is "Legacy desktop solution. Docker Toolbox is for older Mac and Windows systems that do not meet the requirements of Docker for Mac and Docker for Windows..."
older Windows systems like Windows 10 Home? Or anyone who wants to use any other virtualization software?
Docker Inc is extremely clear that Docker Toolbox is a solution to legacy, not a legacy itself. The note at the top of the overview doc page is "Legacy desktop solution".
It's ok if the team doesn't want to do backward compatibility works, I understand, I also prefer to work on the new, exciting stuff. But I don't think it's nice that you just came back to emphasize whether Docker Toolbox is a legacy and ignore all other good pieces @Rast1234 brought up. Something like his comment is what the team should propose to all of our frustrated users, not meaningless arguments over something doesn't matter.
By the way, i updated VS and docker toolbox and now running a project with Docker does not work, resulting in the same error. Cleaning a project with docker support gives the same.
But running and debugging docker-compose project works! Add container ochestrator support by right-clicking on desired csproj, it will create new dcproj called docker-compose. Set it as startup project and configure your docker-compose.yml. Start debugging and be happy if you can live with VS giving errors on clean/rebuild.
UPD: just remove <PackageReference Include="Microsoft.VisualStudio.Azure.Containers.Tools.Targets" Version="1.0.1916590" /> from your csproj to get rid of VS errors. Also remove "Docker" section from launchsettings.json if your project has it.
To sum up:
Microsoft.VisualStudio.Azure.Containers.Tools.Targets reference from csproj to get rid of errors.I'm not sure if it's mentioned or linked in this thread, but i see a lot frustrated users so i'll just leave it here:
- Install Docker Toolbox which is not legacy and works fine with Virtualbox
- Run the Docker Quickstart Terminal (shortcut is created by installer in start menu). It is basically bash with some startup magic.
- Run Visual Studio from inside this terminal. It will get all the env vars and just work with docker.
- I even created a file called
vs, placed it somewhere under$PATHand run it likecd /c/stuff/app && vs app.sln
vscontents:nohup /c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio/2017/Professional/Common7/IDE/devenv.exe "$@" >/dev/null 2>&1 &
I have repeated every steps you listed and it did not work for me.
I had to enable the shared drive in Docker Settings.

Most helpful comment
Well this is unfortunate. Docker uses hyper-v which precludes any other VM and basically locks the whole box down. Docker toolbox is the only workaround, but it doesn't even work. Once again, hampered by M$. I'm so moving to Go. Had enough of this over the years. BTW - toolbox not legacy. It's there to get around EXACTLY this.