I'm getting an error trying to use the Docker functionality with my .NET core 2.0 project. I've been getting an error message saying
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/DockerToolsTroubleshooting
I followed the link, and upon realizing I have Windows 10 Home x64, and had to install Docker Toolbox, instead of Docker For Windows. Now it installed this executable called
Docker Quickstart Terminal
Is this the way one is supposed to start up that docker services? I have tried running this executable, and it seems to be working. My containers are running, but the error for Visual Studio Container Tools still persists.
What am I missing? Is having a version of windows higher than Home required in order to use the Docker Container Support within Visual Studio 2017?
UPDATE:
I tried to follow Quetzcoatl's suggestion, and I am still getting the same error within visual studio about those tools. Here is what I ran in the Docker Quick Start Terminal. I tried building the project after Visual Studio successfully opened the project, and was still getting the aforementioned error regarding the container tools.
My devenv.exe file is located at
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.exe
and my solution file is located at
D:\Development\Visual Studio\Musify2\Musify2\Musify2.sln
UPDATE 2:
I ran some of the suggested commands to try in the docker quickstart terminal and here were the results of those commands quetz
With Docker Toolbox that's a little tricky, but actually the core-2.0 has nothing to do here. It's all about docker, docker-toolbox, and VS.
First of all:
Is this the way one is supposed to start up that docker services? I have tried running this executable, and it seems to be working.
Yes it is. If docker machine/services are running - that's good!
Now, you have to realize that in docker, typically, the information about how/where the docker is running is kept in environment variables. The quickstart
script not only starts the docker-machine for you and checks some basic things, it also sets up a couple of environmental variables so that later all commands like docker
, docker-compose
etc know where to look for the docker virtual machine. In your/our case that information mainly consists of an IP of the VM and a port number that Docker listens on.
.. and your Visual Studio has no knowledge of that, because, I bet on that, you have ran the VisualStudio from StartMenu or from Desktop icon or by double-clicking on a solution file, so it had no chance of getting the environmental variables from quickstart
console.
The solution is quite simple: make sure that VS gets that information. That is, make sure it gets that environmental variables, and make sure that it gets the fresh state of them, because the IP/port may fluctuate sometimes. So don't just copy them to your OS settings, because nothing will ever automagically refresh them..
The simplest way I found is to just close Visual Studio, run docker toolbox quickstart console, then run the VisualStudio from within that console, for example, for my VS2017 Community Edition:
Starting "default"...
(default) Check network to re-create if needed...
(default) Waiting for an IP...
(.......snip..........)
## .
## ## ## ==
## ## ## ## ## ===
/"""""""""""""""""\___/ ===
~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ / ===- ~~~
\______ o __/
\ \ __/
\____\_______/
docker is configured to use the default machine with IP 192.168.99.100
For help getting started, check out the docs at https://docs.docker.com
Start interactive shell
quetzalcoatl@LAP049 MINGW32 ~
$ /c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio/2017/Community/Common7/IDE/devenv.exe C:\\PATH\\TO\\MY\\SOLUTION.sln
The path is pretty long to write, even with TAB-completion, so usually make a tiny .sh
script to run that for me.
BTW! Notice that the path to DEVENV must be unix-like (/c/Program\ Files...
), because the mingw shell has to understand that, while the path to SOLUTION must be a normal windows path (c:\projects\foo\bar\..
) because VisualStudio will try to read that after starting up.