Visual Studio Tools for Docker - PrepareForCompile task completed unexpectedly

Question

I took a clean machine (Windows 10 Enterprise without Anniversary update) and installed (in that order) Full IIS, Hyper-V, VS2015 Enterprise, .NET Core 1.0.1 Tooling Preview 2, Docker for Windows, Visual Studio Docker Tools and several others random programs.

Then I opened VS2015 and created the main .NET website. When I run (F5), everything works as expected. Then I right-clicked on the project and went to "Add-> Docker Support". Now when you try to start (F5) using Docker, I see this error message:

MSB4018 The "PrepareForCompile" task failed unexpectedly. Microsoft.DotNet.Docker.CommandlineClientException: Error response from daemon: Container ... is not running at ... 

I searched the Internet and the only thing I can find is that it can explain that I don’t think that shared drives work. I installed it in Docker-> Shared Drives, but when I ran: docker run --rm -vc:/Users:/data alpine ls /data answer is empty.

Similarly, when I try to use a loaded box, the directory is empty.

docker run -it -v /C/Users:/wormhole busybox cd wormhole ls

I tried using Windows for Docker 1.12.1-stable and beta 26. Both have the same problem.

Some of them indicated that Anti-Virus can cause a problem. I have Mcafee, but I can’t remove or disable antivirus software.

Some have suggested that passwords with unusual characters may cause this problem, but this does not apply here.

I don’t know that shared drives cause VS2015 error, but it seems like this is a good place to start, since shared drives are damaged.

I rebooted the boat and computer many times, but to no avail.

Any ideas?

Answer 1

I had the same problem.

To fix this, I found the container referenced by the identifier in the stack trace. Then I deleted it:

 docker rm <containerid> 

When I tried to launch VS 2015 again, it worked. I do not know what caused the problem initially.

Answer 2

I just wanted to add, since I also came across this problem. I had a clean Win 10 machine, and I just had to turn on the "Shared Drive" setting in the docker:

This may not be the problem you are facing (fortunately, you fixed it!); it's just for people who may not have this included!