Docker-Compose error "Visual Studio Container Tools requires Docker to be running before building, debugging or running a containerized project" about dockertools HOT 22 CLOSED

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.

from dockertools.

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.

from dockertools.

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.

from dockertools.

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:

• Avoid the "Add Docker Support" when creating project or from project's context menu. It will break your csproj and yell about docker tools not running.
• Use the "Add Container Orchestrator Support" instead. It will create Dockerfile, add your project to docker-compose.yml and allow run/debug.
• If you have enabled docker support previously, remove Microsoft.VisualStudio.Azure.Containers.Tools.Targets reference from csproj to get rid of errors.

from dockertools.

We have no plans to support Docker Toolbox at this time.

from dockertools.

Correct, Windows 10 Home doesn't include hyper-v which is required by Docker for Windows

from dockertools.

Back to NodeJS and Linux environment...
MS--

from dockertools.

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?

from dockertools.

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.

from dockertools.

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 $PATH and run it like cd /c/stuff/app && vs app.sln

vs contents: nohup /c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio/2017/Professional/Common7/IDE/devenv.exe "$@" >/dev/null 2>&1 &

from dockertools.

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 $PATH and run it like cd /c/stuff/app && vs app.sln

vs contents: 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.

from dockertools.

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..."

from dockertools.

Is anyone able to look at this, or have any suggestions other than forking over $100 for win10 pro?

from dockertools.

And to my understanding...Docker for Windows only works with windows 10 professional edition correct?

from dockertools.

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...

from dockertools.

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

from dockertools.

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.

from dockertools.

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

from dockertools.

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.

from dockertools.

older Windows systems like Windows 10 Home? Or anyone who wants to use any other virtualization software?

from dockertools.

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.

from dockertools.

I had to enable the shared drive in Docker Settings.

from dockertools.