function DownloadAndExtract([string]$url, [string]$targetLocation) {
    Add-Type -assembly "System.IO.Compression.FileSystem"
    Add-Type -assembly "System.IO.Compression"
    $zipStream = (New-Object System.Net.WebClient).OpenRead($url)
    $zipArchive = New-Object System.IO.Compression.ZipArchive -ArgumentList $zipStream
    [System.IO.Compression.ZipFileExtensions]::ExtractToDirectory($zipArchive, $targetLocation)
    $zipArchive.Dispose()
    $zipStream.Dispose()
}

This is really bad for handle Proxy well it does not care, and there is no workaround
I've almost never done any powershell, but from what i found here
https://stackoverflow.com/questions/571429/powershell-web-requests-and-proxies

here is a working way to at least read default proxy settings
I did not test this change on a computer without a proxy BTW
But at least it helps working in Corp Env.

function DownloadAndExtract([string]$url, [string]$targetLocation) {
    Add-Type -assembly "System.IO.Compression.FileSystem"
    Add-Type -assembly "System.IO.Compression"

    $proxy = [System.Net.WebRequest]::GetSystemWebProxy()
    $proxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials
    $wc = new-object system.net.WebClient
    $wc.proxy = $proxy

    # $zipStream = (New-Object System.Net.WebClient).OpenRead($url)
    $zipStream = $wc.OpenRead($url)
    $zipArchive = New-Object System.IO.Compression.ZipArchive -ArgumentList $zipStream
    [System.IO.Compression.ZipFileExtensions]::ExtractToDirectory($zipArchive, $targetLocation)
    $zipArchive.Dispose()
    $zipStream.Dispose()
}

I had a docker-compose working fine, I've not upgraded Visual Studio 2017 (to 15.3.3) and Docker (17.06.1-ce-win24 13025) the dcproj fails:

1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(279,5): error : Value cannot be null.
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(279,5): error : Parameter name: stream

The offending line is:

<CreateComposeVsGeneratedFiles DockerComposeProjectPath="$(DockerComposeProjectPath)"
                                   DockerDevelopmentMode="$(DockerDevelopmentMode)"
                                   DockerVsDbgPath="$(DockerVsDbgPath)"
                                   DockerMsVsMonPath="$(DockerMsVsMonPath)"
                                   DockerOneCoreMsVsMonPath="$(DockerOneCoreMsVsMonPath)" />

When I loaded the project after updating Visual Studio, it asked me to upgrade the compose files. I agreed and it only changed the version number from 2 to 3.

My compose is:

version: '3'

services:
  mcodatabase:
    image: mcodatabase
    build:
      context: ./Data
      dockerfile: Dockerfile
    restart: always
    ports:
       - 9876:5432
    environment:
      POSTGRES_USER: mcodevuser
      POSTGRES_PASSWORD: password
      POSTGRES_DB: mcodev
    volumes:
     - postgresdata:/var/lib/postgresql/data
    networks:
     - mconetwork

  mcoidentityserver:
    image: mcoidentityserver
    build:
      context: ./Mco.IdentityServer
      dockerfile: Dockerfile
    environment:
      IDENTITY_ISSUER: "http://10.0.75.1:5000"
    ports:
       - 5000:5000
    networks:
     - mconetwork

  mcoapi:
    image: mcoapi
    build:
      context: ./Mco.Api
      dockerfile: Dockerfile
    environment:
      IDENTITY_AUTHORITY: "http://mcoidentityserver:5000"
    ports:
       - 56107:80
    links:
     - mcodatabase
     - mcoidentityserver
    depends_on:
     - "mcodatabase"
     - "mcoidentityserver"
    networks:
     - mconetwork
    
  mcotestclient:
    image: mcotestclient
    build: 
      context: ./Client
      dockerfile: Dockerfile
    ports:
     - 56108:80
    networks:
     - mconetwork

volumes:
  postgresdata:

networks:
  mconetwork:
     driver: bridge

I have created a brand new Web API .Net Core application. Without touching anything, if I attempt to debug with Docker, I get the following message:

WARNING: The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use NETStandard 1.0.0-rc3-23829 or newer. This may be expected if the target process did not run .NET code.

My Dockerfile is as follows:

FROM microsoft/aspnetcore:1.1
ARG source
WORKDIR /app
EXPOSE 80
COPY ${source:-obj/Docker/publish} .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

In the Output window, I get the following:

--------------------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with Visual Studio
Code, Visual Studio or Visual Studio for Mac software to help you develop and
test your applications.
--------------------------------------------------------------------------------
realpath(): Invalid argument
realpath(): Invalid argument
Error: assembly specified in the dependencies manifest was not found -- package: 'system.diagnostics.stacktrace', version: '4.3.0', path: 'lib/netstandard1.3/System.Diagnostics.StackTrace.dll'
The program '' has exited with code 140 (0x8c).

My image is created:

REPOSITORY             TAG                 IMAGE ID            CREATED             SIZE
webapplication1        dev                 bb0b993853af        5 minutes ago       305 MB

It appears I can't attach my debugger to my container - anyone have any thoughts as to why?

Thanks!

From @smitpatel on October 6, 2017 22:38

Steps:

1. Create new ASP.NET Core Web Application
2. Choose Web Application template for 2.0
3. Add individual accounts auth
4. Enable Docker support for windows.

Restore packages/build solution etc.
Press F5
Expected output:
Website from template is opened in browser.
Actual output:
Browser fails to load website. The website URL in browser is http://172.21.203.31/https://localhost:44341/

Copied from original issue: aspnet/Mvc#6923

Currently there is no way of knowing, which command is executed in container when we do Start from Visual Studio using Docker. Entrypoint on development container is set to tail -f /dev/null but there is no way of knowing which command is executed to run an app.

When everything works, it's fine and great, but sometimes start of application fails and there is no way of knowing what went wrong.

Example of output in case of error:

Did you mean to run dotnet SDK commands? Please install dotnet SDK from: 
  http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
The program '' has exited with code 145 (0x91).

Error by itself does not provide enough information. Plus the above link is very useless.

It would be very useful if we could see what command is actual exectued and the option to change it.

When debugging/running MANY containers the Output Debug can be VERY verbose. Being able to attach to the logs of the specific container using the docker cli would be useful. As well as other container monitoring tools such as kitematic.

Is there another way to start the containers such that standard out and error can also go to docker container? Basically an alternative to:

entrypoint: tail -f /dev/null

Copied from dotnet/dotnet-docker#300 by @lczc1988

Steps to reproduce the issue

1.Log in to machine with azure AD account.
2.Start docker for windows
3.Create a asp.net core web api and click Docker to debug. Report error as below.

Starting: "docker" exec -i b7ca27fbf035 /clrdbg/vsdbg/vsdbg --interpreter=mi
rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:262: starting container process caused "exec: "/clrdbg/vsdbg/vsdbg": stat /clrdbg/vsdbg/vsdbg: input/output error"
"docker" exited with code 126 (0x7E).

docker-compose -f "C:\Projects\testdocker2\TestDocker2\docker-compose.yml" -f "C:\Projects\testdocker2\TestDocker2\docker-compose.override.yml" -f "C:\Projects\testdocker2\TestDocker2\docker-compose.vs.debug.yml" -p dockercompose357593242 config
services:
testdocker2:
build:
args:
source: obj/Docker/empty/
context: C:\Projects\testdocker2\TestDocker2\TestDocker2
dockerfile: Dockerfile
entrypoint: tail -f /dev/null
environment:
ASPNETCORE_ENVIRONMENT: Development
DOTNET_USE_POLLING_FILE_WATCHER: '1'
image: testdocker2:dev
labels:
com.microsoft.visualstudio.targetoperatingsystem: linux
ports:
- 80/tcp
volumes:
- C:\Projects\testdocker2\TestDocker2\TestDocker2:/app:rw
- C:\Users\EdX\clrdbg:/clrdbg:ro
- C:\Users\EdX.nuget\packages:/root/.nuget/packages:ro
version: '2.0'
docker ps --filter "status=running" --filter "name=dockercompose357593242_testdocker2_" --format {{.ID}} -n 1
b7ca27fbf035

Expected behavior

Start debugging and can visit the site.

Actual behavior

Report error.

Additional information (e.g. issue happens only occasionally)

Output of docker version

Client:
Version: 17.06.1-ce
API version: 1.30
Go version: go1.8.3
Git commit: 874a737
Built: Thu Aug 17 22:48:20 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: true

(paste your output here)

Output of docker info

rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:262: starting container process caused "exec: \"/clrdbg/vsdbg/vsdbg\": stat /clrdbg/vsdbg/vsdbg: input/output error"
"docker" exited with code 126 (0x7E).
(paste your output here)

Our project is quite complex and we can't use docker-compose build in any case due to bug in docker-compose: docker/compose#3886

We have our own build script for docker-compose and I would like to use it instead of usual docker-compose up --build to start project.

Can I achieve that?

The tooling requires installing Docker For Windows separately from Visual Studio.

Should the ReadMe be updated? ... I was informed that VS2017 now installs the Docker runtime with .NET Core workload install.

Copied from dotnet/dotnet-docker#287

Steps to reproduce the issue

1. Created a new .NET core project with several web api projects, and a web app project all with docker support.
2. Try to run the generated project docker-compose with F5.
3. Got an error stating

"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

4. Installed the Docker Toolbox and installed all options
5. Ran the toolbox via the docker quickstart terminal application to launch docker
6. 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.

https://stackoverflow.com/questions/45869766/how-to-get-docker-toolbox-to-work-with-net-core-2-0-project/45870338?noredirect=1#comment78702229_45870338

Expected behavior

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?

Actual behavior

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.

Additional information (e.g. issue happens only occasionally)

https://github.com/ddeamaral/LetsMusify --source code

Output of docker version

Client:
 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

Output of docker info

Containers: 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

I am using the Docker Tools for VS2017 to run a ASP.NET 4.5 MVC app in a microsoft/aspnet container.

Building and running the project works as expected when I comment out the volume mount for the project directory i.e.
- .\MasterPortal:C:\inetpub\wwwroot\

However when I have the above line in the docker-compose.vs.debug.yml file starting the service fails.

Below are the verbose logs using docker-compose up in PowerShell:

compose.cli.verbose_proxy.proxy_callable: docker start <- (u'854d7608bddcde165aec6e1354c91b3314b191ba204ffe4b7476636be8e
49d2d')
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.feed_queue: Pending: set([])
compose.parallel.parallel_execute_iter: Failed: <Service: citizengateway>
compose.parallel.feed_queue: Pending: set([])

ERROR: for citizengateway Cannot start service citizengateway: container 854d7608bddcde165aec6e1354c91b3314b191ba204ffe4b7476636be8e49d2d encountered an error during Start: failure in a Windows system call: The compute system exited unexpectedly. (0xc0370106)
ERROR: compose.cli.main.main: Encountered errors while bringing up the project.

Any information on what is the cause of this error ?

If your docker-compose file defines virtual volumes to be shared between multiple containers, these are left in place during DockerCleanWorkspace. The next build and run will still have data in these volumes, despite the expectation that the run should be clean.

If docker-compose down is instead run with the -v command line argument, the volumes will be deleted.

Example docker-compose.yml:

version: '3'

services:
  couchbase:
    image: btburnett3/couchbasefakeit:latest
    volumes:
    - "./couchbase:/startup"
    - "nodestatus:/nodestatus"
    networks:
    - network
    ports:
    - "8091:8091"
  service:
    image: service
    build:
      context: ./Service
      dockerfile: Dockerfile
    environment:
      Couchbase__Servers__0: http://couchbase:8091/
      READY_FILE: /nodestatus/initialized
    networks:
    - network
    volumes:
    - "nodestatus:/nodestatus"
    depends_on:
    - couchbase
networks:
  network:
volumes:
  nodestatus:

In this example, the file /nodestatus/initialized is written by one container to indicate that initialization is complete. The main service being debugged should wait for this file before startup because it will be unable to connect. During simple builds this file will still be present, resulting in fast startup and intact data.

But during a Rebuild operation the "couchbase" service is destroyed and restarted. If the nodestatus volume isn't also destroyed, the /nodestatus/initialized file is still present during the next startup, causing unexpected behavior. The only way to fix this currently is to manually delete the volume on the command line.

When building and debugging clients that connect to services, the clients often need to know the URL, even if it's localhost:8080 to enable client connectivity.
The current tools use the dynamic port syntax -P to dynamically find an available port. This works will when everything runs in a container as docker network discovery kicks in. However, when attempting to connect outside the docker DNS, the address must be known.
In the development environment, we need a way to allocate a known address:port that can be set on the project, checked into scc, and known by other clients in the solution, or outside the solution for a known address.
This follows the IISExpress pattern and we may have made this too flexible in our current tools.
If another container is running on that port, we would docker rm -f that container as we assume the current VS instance is the controlling scenario.

I like to set up my projects so the obj and bin directories are all together instead of within the src files. I do this by adding a Directory.Build.props file to the top level directory next to the solution file with lines similar to this:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <PropertyGroup>
    <OutputFullPath>$(MSBuildThisFileDirectory)</OutputFullPath>
    <OutputDrop Condition=" '$(OutputDrop)' == '' ">$(OutputFullPath)bin\$(Configuration)\</OutputDrop>
    <OutputPath>$(OutputDrop)\$(MSBuildProjectName)\</OutputPath>
    <BaseIntermediateOutputPath>$(OutputFullPath)obj\$(MSBuildProjectName)\</BaseIntermediateOutputPath>
  </PropertyGroup>

</Project>

However, if a project has this and tries to add Docker support, then the resulting Dockerfile and docker-compose.yml do not produce a viable container.

Steps

1. Create a new ASP.NET Core Web API project (do not select Docker support)
2. Add a Directory.Build.props as described above
3. Close VS and clear out everything (some of the paths may be cached - if under git use git clean -xfd)
4. Open VS
5. Add Docker Support to project
6. Debug with F5

Expected

Container launches, debugger attaches, and site works

Observed

Container launches, but debugger cannot attach. If I go into the container, I don't see a bin directory. The output of F5 looks like this:

-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
Did you mean to run dotnet SDK commands? Please install dotnet SDK from:
http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
The program '[12] dotnet' has exited with code 145 (0x91).
The program '' has exited with code 145 (0x91).

I have relative paths in docker-compose*.yml and Dockerfiles. So far building docker-compose.dcproj works. But when i try to start debugging session the invocation of docker-compose configdepends on the working directory of VS2017.

Hello,

If I delete de ".vs" folder, the option to "launch in docker is missed in VS2017

Hello,

I've recently started using the docker tools in Visual Studio 2017 15.4.

my docker-compose.yml looks like this:

version: '3'

services:
  testR_servicecore:
    image: testR_servicecore
    restart: always
    ports:
      - 32768:80
    build:
      context: .
      dockerfile: testrdf
    depends_on:
      - testR_postgre

  testR_postgre:
    image: postgres/latest
    restart: always
    build:
      context: .
      dockerfile: testPostgredf
    ports:
     - "5432:5432"
    environment:
      POSTGRES_USER: TestRPostgre
      POSTGRES_PASSWORD: Mortel
      POSTGRES_DB: TestR_db
    volumes:
       - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

While manually running docker-compose up runs fine, the issue is created by DockerTools itself.
The error generated by Visual Studio:

yaml.scanner.ScannerError: while scanning a simple key
  in "<omitted>\obj\Docker\docker-compose.vs.debug.g.yml", line 16, column 1
could not find expected ':'
  in "C:\<omitted>\obj\Docker\docker-compose.vs.debug.g.yml", line 17, column 15.

The generated docker-compose.vs.debug.g.yml, with the faulty line:

version: '3'

services:
  testR_postgre:
    image: postgres/latest:dev
    build:
      args:
        source: obj/Docker/empty/
    environment:
      - DOTNET_USE_POLLING_FILE_WATCHER=1
      - NUGET_FALLBACK_PACKAGES=$container_paths_to_fallback_packages_testR_postgre$
    volumes:
      - C:\_Dev\testR_ServiceCoreFull:/app
      - C:<omitted>\vsdbg:/remote_debugger:ro
      - $nuget_user_folder_testR_postgre$:/root/.nuget/packages:ro
$nuget_fallback_packages_volume_mapping_testR_postgre$
    entrypoint: tail -f /dev/null
    labels:
      com.microsoft.visualstudio.debuggee.program: "dotnet"
      com.microsoft.visualstudio.debuggee.arguments: " $debuggee_arguments_probing_paths_testR_postgre$ bin/Release/netcoreapp2.0/testR_ServiceCore.dll"
      com.microsoft.visualstudio.debuggee.workingdirectory: "/app"
      com.microsoft.visualstudio.debuggee.killprogram: "/bin/bash -c \"if PID=$$(pidof -x dotnet); then kill $$PID; fi\""

  testR_ServiceCore:
    image: testR_ServiceCore:dev
    build:
      args:
        source: obj/Docker/empty/
    environment:
      - DOTNET_USE_POLLING_FILE_WATCHER=1
      - NUGET_FALLBACK_PACKAGES=/root/.nuget/fallbackpackages
    volumes:
      - C:\_Dev\testR_ServiceCoreFull:/app
      - C:<omitted>\vsdbg:/remote_debugger:ro
      - C:<omitted>\.nuget\packages\:/root/.nuget/packages:ro
      - C:\Program Files\dotnet\sdk\NuGetFallbackFolder:/root/.nuget/fallbackpackages:ro

    entrypoint: tail -f /dev/null
    labels:
      com.microsoft.visualstudio.debuggee.program: "dotnet"
      com.microsoft.visualstudio.debuggee.arguments: " --additionalProbingPath /root/.nuget/packages --additionalProbingPath /root/.nuget/fallbackpackages  bin/Release/netcoreapp2.0/testR_ServiceCore.dll"
      com.microsoft.visualstudio.debuggee.workingdirectory: "/app"
      com.microsoft.visualstudio.debuggee.killprogram: "/bin/bash -c \"if PID=$$(pidof -x dotnet); then kill $$PID; fi\""

In short:

according to the error the line:

$nuget_fallback_packages_volume_mapping_testR_postgre$

is causing the issue.
It resides in the docker-compose.vs.debug.g.yml, a file automatically generated by DockerTools.
The line is indented incorrectly and misses a -.

Solved by @sgreenmsft :
The dockerfile of the second container shouldn’t be placed in the same folder as the csproj’s dockerfile.

I noticed that in 15.3 preview 6 the DockerTools don't seem to create the same file set (the docker-compose-override.vs.debug.yml and docker-compose-override.vs.release.yml files aren't created).

Is there anywhere I can read more information about these changes?
I tried the preview release notes, but didn't see the information there.

Thanks!

After upgrade to latest VS 2017 15.3 I cannot start debug of Docker container from VS.
Reproducible with any kind of .net core projects (console, asp.net) and with any version of .net core.

I also tried to start VS with admin rights, restart my box and stop and start docker.

Error message: Operation aborted (Exception from HRESULT: 0x80004004 (E_ABORT))
Docker log:

docker-compose -f "C:\Users\Sergii_Tkachenko\Documents\Visual Studio 2017\Projects\ConsoleApp1\docker-compose.yml" -f "C:\Users\Sergii_Tkachenko\Documents\Visual Studio 2017\Projects\ConsoleApp1\docker-compose.override.yml" -f "C:\Users\Sergii_Tkachenko\Documents\Visual Studio 2017\Projects\ConsoleApp1\obj\Docker\docker-compose.vs.debug.g.yml" -p dockercompose9756074155277170669 config
services:
  consoleapp1:
    build:
      args:
        source: obj/Docker/empty/
      context: C:\Users\Sergii_Tkachenko\Documents\Visual Studio 2017\Projects\ConsoleApp1\ConsoleApp1
      dockerfile: Dockerfile
    entrypoint: tail -f /dev/null
    environment:
      NUGET_FALLBACK_PACKAGES: /root/.nuget/fallbackpackages
    image: consoleapp1:dev
    labels:
      com.microsoft.visualstudio.debuggee.arguments: ' --additionalProbingPath /root/.nuget/packages
        --additionalProbingPath /root/.nuget/fallbackpackages  bin/Debug/netcoreapp2.0/ConsoleApp1.dll'
      com.microsoft.visualstudio.debuggee.killprogram: /bin/bash -c "if PID=$(pidof
        -x dotnet); then kill $PID; fi"
      com.microsoft.visualstudio.debuggee.program: dotnet
      com.microsoft.visualstudio.debuggee.workingdirectory: /app
    volumes:
    - C:\Users\Sergii_Tkachenko\Documents\Visual Studio 2017\Projects\ConsoleApp1\ConsoleApp1:/app:rw
    - C:\Users\Sergii_Tkachenko\vsdbg:/remote_debugger:ro
    - C:\Program Files\dotnet\sdk\NuGetFallbackFolder:/root/.nuget/fallbackpackages:ro
    - C:\Users\Sergii_Tkachenko\.nuget\packages:/root/.nuget/packages:ro
version: '3.0'
docker  ps --filter "status=running" --filter "name=dockercompose9756074155277170669_consoleapp1_" --format {{.ID}} -n 1
1f2a3ec3b102

But, I can see that image created and container is up and running using docker -ps:
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1f2a3ec3b102 consoleapp1:dev "tail -f /dev/null" 16 hours ago Up About a minute dockercompose9756074155277170669_consoleapp1_1

in order to diagnostic why i can't use it at work.
i have to decompile the MsBuild sdk for docker i. order to under all the detection stuff like the CLI etc ...

seeing the code made me understand that if Docker is installed elsewhere than c:\program files
it will fails
or magic string like "DockerCli.exe" that are not reused
is there a way to let the community helps on that ?

I want to be able to read from a .env file.

Docker, by convention, looks for a .env file in the current execution folder. DockerTools does not run from root, and also does not allow you to specify where to execute from.

An alternative would be to allow me to add an additional docker-compose override file and have it passed along with the provided override files.

Visual Studio 2017 and Dockers for Windows on Windows 10.
VS version: 15.3.5
Docker version: 17.06.2-ce
Docker-Compose version: 1.14
When adding Docker Support to project
expected docker-compose.vs.debug.yml and docker-compose.vs.release.yml to be included under docker-compose.yml along with docker-compose.override.yml

Actual behavior

the two files are missing

Information

• Diagnostic ID from "Diagnose & Feedback" in the menu.
• a reproducible case if this is a bug, Dockerfiles FTW
• page URL if this is a docs issue or the name of a man page
• host distribution and version (Windows version, build number, etc)

Steps to reproduce the behavior

1. ... Have Windows 2016 VM and several Windows 10 VM that have same issue
   

As Microsoft announced Docker Tools would be open sourced, could you consider making it open source as soon as possible?
https://blogs.msdn.microsoft.com/stevelasker/2016/11/22/visual-studio-docker-tools-support-for-visual-studio-2015-2017/

As far as I know, I can't find the open source repository for Docker Tools not only for Visual Studio 2017 but also for Visual Studio 2015. If the repository is already open sourced, please let me know.

• ASP.NET Core 1.1.2
• Target frameworks: netcoreapp2.0;net461

Added docker support to my 3 projects. Trying to run docker-compose debug from inside VS gives the following errors:

Restoring NuGet packages...
To prevent NuGet from restoring packages during build, open the Visual Studio Options dialog, click on the Package Manager node and uncheck 'Allow NuGet to download missing packages during build.'
1>------ Build started: Project: docker-compose, Configuration: Debug Any CPU ------
1>docker  version --format {{.Server.Os}}
1>linux
1>docker-compose -f "C:\Projects\bw-core\docker-compose.yml" -f "C:\Projects\bw-core\docker-compose.override.yml" -p dockercompose6075498849837586277 config
1>services:
1>  api:
1>    build:
1>      context: C:\Projects\bw-core\src\Api
1>      dockerfile: Dockerfile
1>    environment:
1>      ASPNETCORE_ENVIRONMENT: Development
1>    image: api
1>    ports:
1>    - 80/tcp
1>  billing:
1>    build:
1>      context: C:\Projects\bw-core\src\Billing
1>      dockerfile: Dockerfile
1>    environment:
1>      ASPNETCORE_ENVIRONMENT: Development
1>    image: billing
1>    ports:
1>    - 80/tcp
1>  identity:
1>    build:
1>      context: C:\Projects\bw-core\src\Identity
1>      dockerfile: Dockerfile
1>    environment:
1>      ASPNETCORE_ENVIRONMENT: Development
1>    image: identity
1>    ports:
1>    - 80/tcp
1>version: '3.0'
1>C:\Projects\bw-core\src\Api\Api.csproj : error MSB4057: The target "DockerResolveAppType" does not exist in the project.
1>Done building project "Api.csproj" -- FAILED.
1>C:\Projects\bw-core\src\Billing\Billing.csproj : error MSB4057: The target "DockerResolveAppType" does not exist in the project.
1>Done building project "Billing.csproj" -- FAILED.
1>C:\Projects\bw-core\src\Identity\Identity.csproj : error MSB4057: The target "DockerResolveAppType" does not exist in the project.
1>Done building project "Identity.csproj" -- FAILED.
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========
========== Deploy: 0 succeeded, 0 failed, 0 skipped ==========

Dockerfile (from one project)

FROM microsoft/aspnetcore:1.1.2
ARG source
WORKDIR /app
EXPOSE 80
COPY ${source:-obj/Docker/publish} .
ENTRYPOINT ["dotnet", "Api.dll"]

VS info

Microsoft Visual Studio Enterprise 2017 Preview (2)
Version 15.3.0 Preview 6.0
VisualStudio.15.Preview/15.3.0-pre.6.0+26724.1
Microsoft .NET Framework
Version 4.7.02046

Installed Version: Enterprise

Visual Basic 2017   00369-60000-00001-AA734
Microsoft Visual Basic 2017

Visual C# 2017   00369-60000-00001-AA734
Microsoft Visual C# 2017

Visual F# 4.1   00369-60000-00001-AA734
Microsoft Visual F# 4.1

Application Insights Tools for Visual Studio Package   8.8.00712.1
Application Insights Tools for Visual Studio

ASP.NET and Web Tools 2017   15.0.30718.0
ASP.NET and Web Tools 2017

ASP.NET Core Razor Language Services   1.0
Provides languages services for ASP.NET Core Razor.

ASP.NET Template Engine 2017   15.0.30718.0
ASP.NET Template Engine 2017

ASP.NET Web Frameworks and Tools 2017   5.2.50601.0
For additional information, visit https://www.asp.net/

Azure App Service Tools v3.0.0   15.0.30719.0
Azure App Service Tools v3.0.0

Azure Data Lake Tools for Visual Studio   2.2.9000.0
Microsoft Azure Data Lake Tools for Visual Studio

Azure Data Lake Tools for Visual Studio   2.2.9000.0
Microsoft Azure Data Lake Tools for Visual Studio

Commit Formatter   1.0
Adds automatic word wrap to the Git commit message textbox.

Common Azure Tools   1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Fabric.DiagnosticEvents   1.0
Fabric Diagnostic Events

Indent Guides   15
Indent Guides

Adds visual guides at each indentation level.

JavaScript Language Service   2.0
JavaScript Language Service

Microsoft Azure Tools   2.9
Microsoft Azure Tools for Microsoft Visual Studio 2017 - v2.9.50712.2

Microsoft Continuous Delivery Tools for Visual Studio   0.3
Simplifying the configuration of continuous build integration and continuous build delivery from within the Visual Studio IDE.

Microsoft JVM Debugger   1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

Microsoft MI-Based Debugger   1.0
Provides support for connecting Visual Studio to MI compatible debuggers

NuGet Package Manager   4.3.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.

Redgate ReadyRoll   1.14.2.3918
Extend DevOps processes to your SQL Server databases and safely automate database deployments.
    
Visit https://www.red-gate.com/readyroll for more information.

Copyright (C) 2011 Red Gate Software Ltd. All rights reserved.
  
This software contains components from Component Owl.
SQL Server is a registered trademark of Microsoft Corporation. 
Visual Studio is a registered trademark of Microsoft Corporation. 

ReadyRoll contains code from the following open source software:

NuGet https://www.nuget.org/
SQL LocalDB Wrapper https://github.com/martincostello/sqllocaldb
Autofac https://autofac.org/
Json.NET https://json.net/
MahApps.Metro http://mahapps.com/
SemVer https://github.com/maxhauser/semver
Log4Net http://logging.apache.org/log4net/
Extended WPF Toolkit https://wpftoolkit.codeplex.com/
Code InfoBox VSX http://www.codeproject.com/Articles/55196/Code-InfoBox-Visual-Studio-Extension-VSX
OctoPack https://github.com/OctopusDeploy/OctoPack
SQLite https://sqlite.org/

This product contains icons from http://www.visualpharm.com distributed under a free backlink license.

For license details or other notices relating to the above software, please see NOTICE.TXT and EULA.rtf in the ReadyRoll application folder.
    

SQL Server Data Tools   15.1.61707.200
Microsoft SQL Server Data Tools

TypeScript   2.3.4.0
TypeScript tools for Visual Studio

Visual Studio Code Debug Adapter Host Package   1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual Studio

WebJobs Tools v1.0.0   __RESXID_PRODUCTVERSION__
WebJobs Tools v1.0.0

If I create a .NET Core Console application in Visual Studio using nothing but default settings (netcoreapp2.0) and add docker support and press F5, several compose steps will run successfully until the last stage wherein the Debug console will indicate failure.

-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
realpath(): Invalid argument
realpath(): Invalid argument
It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '2.0.0-preview2-25407-01' was not found.
- Check application dependencies and target a framework version installed at:
/
- Alternatively, install the framework version '2.0.0-preview2-25407-01'.
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
The program '[14] dotnet' has exited with code 131 (0x83).
The program '' has exited with code 131 (0x83).

I have all necessary images pulled (and they were pulled successfully by the prior compose steps).

As a side-note, docker-compose.ci.build.yml does not set the correct image (I have tried this with both the default invalid value and the corrected microsoft/dotnet:2.0-sdk value).

version: '3'

services:
  ci-build:
    image: microsoft/aspnetcore-build:1.0-1.1
    volumes:
      - .:/src
    working_dir: /src
    command: /bin/bash -c "dotnet restore ./DockerTest3.sln && dotnet publish ./DockerTest3.sln -c Release -o ./obj/Docker/publish"

Output of docker images

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
dockertest3         dev                 7cf0e6eca6ca        4 minutes ago       219MB
dockertest2         dev                 1470a7483065        5 minutes ago       1.63GB
microsoft/dotnet    2.0-sdk             8ad7a9c7770d        9 hours ago         1.63GB
microsoft/dotnet    2.0-runtime         43f11b0e30ad        9 hours ago         219MB

As a second side-note, when this fails, it fails to stop and remove the container created by the attempt. 😦 Output of last two tests in docker ps

CONTAINER ID        IMAGE               COMMAND               CREATED             STATUS              PORTS               NAMES
a13e76bb5c3c        dockertest3:dev     "tail -f /dev/null"   5 minutes ago       Up 5 minutes                            dockercompose10379318983622196731_dockertest3_1
af296f6343ef        dockertest2:dev     "tail -f /dev/null"   6 minutes ago       Up 6 minutes                            dockercompose10378476757715176330_dockertest2_1

I have a console app that I've added Docker Support to - so it was added to my docker-compose.yml file as expected:

some.console.app:
  image: some.console.app
  build:
    context: ./Some.Console.App
    dockerfile: Dockerfile

I would like to run this console app twice with an environment variable flag which would change its behavior. So I attempted to change the docker-compose.yml file (and made similar changes to the .vs.debug.yml file along with it etc)

some.console.app.A:
  image: some.console.app
  build:
    context: ./Some.Console.App
    dockerfile: Dockerfile
  environment:
    - Flag=A
some.console.app.B:
  image: some.console.app
  build:
    context: ./Some.Console.App
    dockerfile: Dockerfile
  environment:
    - Flag=B

I've tried several different things, such as changing the image name so that each are different, but still come from the same Dockerfile, just to see if maybe VS2017 was differentiating by image name or something. But no matter what I do, I am unable to see the output of the second instance in the Output window. I made sure to copy the relevant section in the docker-compose.vs.debug.yml file to get the tail -f /dev/null entry point for this container as well. And when I run docker ps -a I am able to see that the container is actually running (just the tail command though), but VS has not actually called the dotnet command.

When I read the output from the Build Output, I see the build process look for and kill the dotnet process in both container instances

1>docker  ps --filter "status=running" --filter "name=dockercompose1323906375_some.console.app.A_" --format {{.ID}} -n 1
1>9a6c371e39c5
1>docker  exec -i 9a6c371e39c5 /bin/bash -c "if PID=$(pidof -x dotnet); then kill $PID; fi"
...and same for some.console.app.B

and when Build runs docker-compose -f .... up -d I see both containers running (or saying they are up-to-date).

However, in the Docker Output window, the process only execs the dotnet process on the first instance of the container:

docker  ps --filter "status=running" --filter "name=dockercompose1323906375_some.console.app.A_" --format {{.ID}} -n 1
9a6c371e39c5
docker  exec -i 9a6c371e39c5 dotnet --additionalprobingpath /root/.nuget/packages bin/Debug/netcoreapp1.1/Some.Console.App.dll
but NOT for some.console.app.B

How can I get VS to run my container twice?

When code hits an unhandled exception it would be nice to have a View Details "link", which opens QuickWatch. This works when running application outside of containers.

Currently you can still see a unhandled expection details in $exception variable (Locals tab or manually in Watch1 tab), but it would be much more friendlier to have a missing link.

I can't seem to be able to get debugging to work with Windows Containers from Visual Studio 2017. Is this something that could work?

Visual Studio persists in downloading and mapping ClrDbg for -RuntimeID debian.8-x64 even with "com.microsoft.visualstudio.targetoperatingsystem=windows" and even though Visual Studio attempts to start msvsmon in this case, none of the nanoserver images have it and mapping it or copying it over, msvsmon appears to be only capable of exiting instantly.

Hi, I would like to build my solutions inside a build container (aka the "Docker builder pattern"). I would like to just call MSBUILD mysolution.sln /p:Configuration=Release but that trigger the build of the dcproj which will try do call docker inside my container (as far as I know we can't run docker in docker with Windows containers yet).

Is there a MSBUILD parameter I can set so the dcproj is skipped or do I need to build each of my csproj individually?

Hi All, I am trying to publish my asp.net 5 web app to my docker host, but it's not working. The error message like this:

Publishing with publish method [Custom]
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Microsoft.DNX.Publishing.targets(386,5): Error : An error occurred during publish.
AspnetPublishHandler with name "Custom" was not found

I use vs 2015 with update 1 and Tools for Docker 0.9.2.
I have repair the tools and vs, but it still not work.
Wish someone can help me, thanks.

i can’t attach my debugger because sharing drive C is forbidden by GPO

my source code is on D:
Vs2017 is on c:
docker can only install on c: (even thought i tricked it to work for a short period on D:)

should i share C ? D ? both

open sourcing this code would be a HUGE bonus when dealing with issue like this
What are the blocker so you can OpenSource DockerTools for vs2017 ?
can we help you so remove these blocker ?

Original post by @chrisoverzero: aspnet/Configuration#659

Summary: User secrets cannot (easily, portably) be used with Visual Studio's "Docker Support" feature for ASP.NET Core projects.

Hi! I've been using User Secrets for a while in several ASP.NET Core projects. My company is evaluating a move to Docker for deployments, and – as part of that evaluation – I activated the Docker Support feature in Visual Studio. After this, the application completely failed to reference my secrets.

I've worked around this for my own support by bind-mounting (in docker-compose.override.yml) the secrets.json file on my development box to the correct location in the Linux container, but this seems to violate Microsoft's advice:

You should not write code that depends on the location or format of the data saved
with the Secret Manager tool, as these implementation details might change.

...in addition to not being portable between our Windows and Linux developers.

Versions of things

• Microsoft.Extensions.Configuration.UserSecrets: 1.1.1
• Microsoft.Extensions.SecretManager.Tools: 1.0.0
• Visual Studio: 15.1 (26403.7)

Comment by @natemcmaster: aspnet/Configuration#659 (comment)

The advice was written with authors of third-party class libraries and tools in mind. The location of the files is not "under contract" so your docker-compose file might break in future versions. However, until that happens, volume mounting the user secrets location for development environments is fine, and seems like something Docker Tooling could consider doing by default.

That said, mounting UserSecrets for production is not recommended. For production secrets, checkout https://github.com/aspnet/Configuration/tree/dev/src/Microsoft.Extensions.Configuration.DockerSecrets

Moved issue from https://github.com/dotnet/coreclr/issues/11605#issuecomment-301917443

In VS2017 Update 2, I start a brand new project, add docker support. Hit run and get the following error:

You may only use the Microsoft .NET Core Debugger (vsdbg) with Visual Studio
Code, Visual Studio or Visual Studio for Mac software to help you develop and
test your applications.

realpath(): Invalid argument
The specified framework 'Microsoft.NETCore.App', version '1.1.2' was not found.

• Check application dependencies and target a framework version installed at:
  /usr/share/dotnet/shared/Microsoft.NETCore.App
• The following versions are installed:
  1.1.1
• Alternatively, install the framework version '1.1.2'.
  The program '' has exited with code 131 (0x83).

I assume I need to run this in order to be able to publish to my host but I can't find any suitable documentation. After running it I get an error as the script can't find "C:\RuntimeSettings\docker.settings".

Any ideas?

I am using VS 2017 vs DOCKER_HOST pointing to a remote linux machine.

In 15.2 - I am able to override mounts:
- /mnt/${USERNAME}/.nuget/packages:/root/.nuget/packages:ro

In 15.3, it is impossible due to auto-generated files:
docker-compose.vs.debug.g.yml
with content

version: '3'

services:
  my-project:
    image: my-project:dev
    build:
      args:
        source: ${DOCKER_BUILD_SOURCE}
    volumes:
      - C:\my-project:/app
      - ${NUGET_PACKAGES}:/root/.nuget/packages:ro
      - ${VSDBG_PATH}:/remote_debugger:ro
    entrypoint: tail -f /dev/null

Please provide some way to override this volumes:
- C:\my-project:/app
- ${NUGET_PACKAGES}:/root/.nuget/packages:ro
- ${VSDBG_PATH}:/remote_debugger:ro

Or provide some way to auto mount this volumes to a remote linux machine

I currently have a in-house hosted VSTS build agent and getting it to build projects that utilize the VS 2017 Docker tools has been a royal pain in the behind.

Some documentation and guidance on how to set-up a build agent that can build Windows Containers is sorely needed.

When creating a #aspnetcore 2.0 project that has #identity enabled the DockerServiceUrl in the .dcproj file in not valid and is a string that is combined URIs in the form of http://{ip}/https:localhost:{port}/ see https://github.com/grahamehorner/AspNetCoreTemplateDockerIssues/tree/master/WebApplicationLinuxWithAuth as example of a repo

Create an ASP.NET Core Web App
Add Docker Support
Choose Windows
Open the docker-compose.yml file
Change the image value to something

services:
  web:
    image: webish
    build:
      context: .\Web
      dockerfile: Dockerfile

Hit F5
Run docker images
Notice the image name is still web
I should be able to rename the image to reflect my actual image name. It may include my registry, another name like frontendmarketingweb

When attempting to build an ASP.NET Core 1.1 WEB API templated project within Visual Studio 2017 (and on a network that requires an authenticated proxy to get outside), I continually get this error:

MSB4018 The "EnsureVsDbgExists" task failed unexpectedly.
System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The remote server returned an error: (407) Proxy Authentication Required.

I have added the proxy string into my docker for windows container and yet nothing seems to work. Is there a special configuration required for the VS build tools to acknowledge the proxy settings?

I updated to Visual Studio 2017 15.3.2.

Immediately after updating, I loaded a solution I was using.

The solution now displays the following:

"docker-compose (load failed)

Project file is incomplete. Expected imports are missing."

Attempting to re-generate the docker-compose files by deleting and re-creating everything did not work.

I was never prompted to update the docker-compose file to follow the 2.0 structure in this solution. In a different one, I was, and did, Attempting to copy over those changes also did not work.

I have an soa architecture with many dotnet core webapi services in my compose file.
Most times I am working on only one of many (but need the many running).

When I debug the docker-compose project it compiles ALL of them... recreates all of them.
I would like the tool to be able to debug a single service

docker-compose .. up -d <servicename>

My expectation is that whatever I set is for url is launched regardless of how the composition is set up. It's less clear to me how the service selection is used, but I'm guessing it has to be a .NET core service so the tools will know when startup is complete.

In any case, the launch browser setting doesn't seem to be working properly and I don't see anything in the output indicating why it's failing. I don't see any documentation for these settings.

My setup is a composition with several .NET Core services and an nginx service to proxy traffic to them. The nginx service will route https traffic from 443 and redirect 80 to https and 443. The .NET services have fixed ports that are only internally visible.

I've tried a number of different url and service combinations. So far, the only combo that actually launches a browser is http://localhost:443 with one of my .NET Core services. But nginx coughs up an error because the protocol doesn't match the port (notice the http rather than https).

Any guidance would be appreciated if I'm doing something wrong.

When you try to expand a variable it takes a couple of seconds to actually expend.

It would be very nice if that was instant, as it normally is, outside of containers.

Introduction

I've tried to launch supervisord in a container to run both webpack-dev-server and .NET Core Web App at the same time (for development purposes).

I've created the following Dockerfile:

FROM microsoft/aspnetcore:1.1

(... omitted for brevity ...)

ENTRYPOINT ["supervisord"]

and the following supervisord.conf file:

[supervisord]
nodaemon=true

(... omitted for brevity ...)

[program:frontend]
command=/bin/bash -c "cd wwwroot && npm start"

[program:backend]
command=/bin/bash -c "dotnet App.dll"

When I hit F5, I see that supervisor doesn't start, so frontend and backend apps shouldn't start. The weird thing is that my App.dll starts successfuly. When I started supervisor manually from the container itself, I noticed that backend (which is my App.dll) can't be started (because it is already running), but frontend works fine:

After few more tries I realized that VS2017 starts my app behind the scenes and ignores my ENTRYPOINT because docker-compose.vs.debug.yml overrides the ENTRYPOINT with the following command:

entrypoint: tail -f /dev/null

Changing entrypoint in docker-compose.vs.debug.yml doesn't help, it seems that tail -f /dev/null command is required.

Problem

The problem is that I can't find where and how my app starts. Also, it would be great to know a way to change default VS2017 behavior, so I can stop VS2017 from launching my app and launch supervisord instead.

Maybe I am missing something?

I was able to isolate and reproduce this issue(?).

Steps to reproduce

1. Create a new solution using standard "Console App (.NET Core)" template
2. Right-click on a new console app and select "Add => Docker Support"
3. Open Dockerfile and change ENTRYPOINT to something that should cause an error.

FROM microsoft/dotnet:1.1-runtime
ARG source
WORKDIR /app
COPY ${source:-obj/Docker/publish} .
ENTRYPOINT ["DOESNOTEXIST"]

4. Hit F5

EXPECTED RESULT: Console app doesn't start.

ACTUAL RESULT:

Project created with VS2017 for .net core and with docker support contains docker-compose files in the root folder and Dockerfile in the project folder. It's also standard to have Dockerfile in the root, or in the same folder as docker-compose files. Problem occurs when Dockerfile is moved next to docker-compose files and context of docker-compose is set to "."

Why I put it in solution directory? Well, I am using approach with Dockerfile.build and Dockerfile. So, this dockerfile.build file just copies source code, then restore dependencies and finaly creates build artefacts.
If Dockerfile is in project directory, dotnet restore command will not restore dependencies from another projects in solution. So, I placed it in solution directory. And it works fine, images are created successfully.

But I still want to build them and debug from VS. So, I set context in docker-compose file to "." And I got the error in subject.
Thanks.

I've read https://developercommunity.visualstudio.com/content/problem/37623/circular-dependency-error-when-building-for-docker.html, but it is not really helpful.

I cannot find the possibility to change or override the command to execute docker-compose from visual studio. For example, I need to start (using F5) to environment by using this command "docker stack deploy -c docker-compose.yml xxx" and still need to be able to debug it. Is it possible? Can you please incorporate this idea to the next version. I think it uses "docker-compose up -d" and there is no way to override this behavior.

I have a local SQL Server instance running on my Windows dev machine. I want to connect to it from my Linux docker container using Entity Framework Core. My connection string of Data Source=localhost fails, I've also tried several IP addresses and port combinations but can't seem to connect to my SQL Server.

I asked this question on StackOverflow here and someone mentioned that I could use the --net=host option to share the host network with the container. I tried adding network_mode: host to my docker-compose.yml or docker-compose.override.yml file but I get an error in both cases:

Is this a supported scenario? Am I supposed to be able to connect to my SQL Server using localhost? If not, am I supposed to use an IP address, if so what would that IP address be?

Summary

It'd be helpful to have more Roslyn Analyzers added to VS Docker files. Posting here to see who else is interested or has more suggestions.

Suggested Analyzers for Discussion

• Dockerfile
  • Show error when base image in Dockerfile has been updated on DockerHub, but not re-pulled.
    • If image is not from DockerHub or a known image registry no codefix should be triggered.
    • Add Code Fix to re-pull the updated Docker Image from DockerHub
    • List when image was last pulled
    • Throw error if updated image is a security patch.
      • May be unable to determine with current DockerHub json endpoint
  • Add info symbol on FROM line that links to DockerHub Readme.
  • Add tag suggestions
    • Ex: When I type FROM microsoft/aspnetcore:1 Should suggestions for 1.1, 1.0 appear?

Already Implemented

• Docker syntax info appears when hovering.

Teamwork makes the dream work

@SteveLasker @glennc @MichaelSimons

Hi! I'm trying out the Visual Studio 2017 Community and ASP.NET Core web app and get a prompt stating "Unable to start debugging. Unable to establish a connection to VSDBG. Debug output may contain more information."

Output Windows shows the following:

Starting: "docker" exec -i dd11077d4248 /clrdbg/vsdbg/vsdbg --interpreter=mi
rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:247: starting container process caused "exec: "/clrdbg/vsdbg/vsdbg": stat /clrdbg/vsdbg/vsdbg: no such file or directory"
"docker" exited with code 126 (0x7E).

I saw that a similar problem was being discussed
dotnet/dotnet-docker#162
But the solution did not help.

Steps to reproduce the issue

1.Open VS 2017 Community
2.Create new ASP.NET Core Web App
3.Debug with Docker

Expected behavior

Should run app in container and allow breakpoints, etc.

Actual behavior

It prompts with error mentioned above. It does appear to deploy and run a container.

Output of docker version

Client:
Version: 17.03.1-ce
API version: 1.27
Go version: go1.7.5
Git commit: c6d412e
Built: Tue Mar 28 00:40:02 2017
OS/Arch: windows/amd64

Server:
Version: 17.03.1-ce
API version: 1.27 (minimum version 1.12)
Go version: go1.7.5
Git commit: c6d412e
Built: Fri Mar 24 00:00:50 2017
OS/Arch: linux/amd64
Experimental: true

Output of docker info

Containers: 4
Running: 1
Paused: 0
Stopped: 3
Images: 12
Server Version: 17.03.1-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 4.9.27-moby
Operating System: Alpine Linux v3.5
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.934 GiB
Name: moby
ID: 2NIF:L7XL:JNC7:UIWV:VCGX:KBZU:MITL:43VJ:X3VR:DWKL:BZAO:TXP6
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 21
Goroutines: 32
System Time: 2017-05-22T17:19:35.5988348Z
EventsListeners: 0
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false

After adding Docker support to a project and running it, Docker build step failed on dnu restore because it could not find dependencies, specifically, another project in same solution that is referenced by current project. This is due to fact that only current project is copied to Docker container.

Manually chaining Dockerfile templates to copy whole solution or both projects fixes the problem.

Will there be a support in DockerTools out of the box for projects that reference another project in solution, or should every dependency be packed and pushed to nuget feed?