New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VS2017 Docker-Compose Project breaks build on command line #6178

Closed
billpratt opened this Issue Mar 28, 2017 · 62 comments

Comments

Projects
None yet
@billpratt
Copy link

billpratt commented Mar 28, 2017

Steps to reproduce

In Visual Studio 2017: File->New Project->ASP.NET Core Web Application
Choose either Web API or Web Application
Check "Enable Docker Support"

Go to command line and run

dotnet restore ./[NAME].sln
dotnet build ./[NAME].sln

Expected behavior

Restore and build work when a Docker-Compose project (.dcproj) is in the solution.
Should work across all platforms that dotnet is supported

Actual behavior

error MSB4019: The imported project "C:\Program Files\dotnet\sdk\1.0.0\Sdks\Microsoft.Docker.Sdk\Sdk\Sdk.props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.

PS C:\Users\foo\Documents\Visual Studio 2017\Projects\WebApplication10> dotnet --version
1.0.0

PS C:\Users\foo\Documents\Visual Studio 2017\Projects\WebApplication10> dotnet restore .\WebApplication10.sln
C:\Users\foo\Documents\Visual Studio 2017\Projects\WebApplication10\docker-compose.dcproj : error MSB4019: The imported project "C:\Program Files\dotnet\sdk\1.0.0\Sdks\Microsoft.Docker.Sdk\Sdk\Sdk.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
  Restoring packages for C:\Users\foo\Documents\Visual Studio 2017\Projects\WebApplication10\WebApplication10\WebApplication10.csproj...
  Restoring packages for C:\Users\foo\Documents\Visual Studio 2017\Projects\WebApplication10\WebApplication10\WebApplication10.csproj...
  Restore completed in 785.82 ms for C:\Users\foo\Documents\Visual Studio 2017\Projects\WebApplication10\WebApplication10\WebApplication10.csproj.
  Lock file has not changed. Skipping lock file write. Path: C:\Users\foo\Documents\Visual Studio 2017\Projects\WebApplication10\WebApplication10\obj\project.assets.json
  Restore completed in 1.08 sec for C:\Users\foo\Documents\Visual Studio 2017\Projects\WebApplication10\WebApplication10\WebApplication10.csproj.

  NuGet Config files used:
      C:\Users\foo\AppData\Roaming\NuGet\NuGet.Config
      C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

  Feeds used:
      https://api.nuget.org/v3/index.json
      C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
      
PS C:\Users\foo\Documents\Visual Studio 2017\Projects\WebApplication10> dotnet build .\WebApplication10.sln
Microsoft (R) Build Engine version 15.1.548.43366
Copyright (C) Microsoft Corporation. All rights reserved.

C:\Users\foo\Documents\Visual Studio 2017\Projects\WebApplication10\docker-compose.dcproj : error MSB4019: The imported project "C:\Program Files\dotnet\sdk\1.0.0\Sdks\Microsoft.Docker.Sdk\Sdk\Sdk.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
  WebApplication10 -> C:\Users\foo\Documents\Visual Studio 2017\Projects\WebApplication10\WebApplication10\bin\Debug\netcoreapp1.1\WebApplication10.dll

Build FAILED.

C:\Users\foo\Documents\Visual Studio 2017\Projects\WebApplication10\docker-compose.dcproj : error MSB4019: The imported project "C:\Program Files\dotnet\sdk\1.0.0\Sdks\Microsoft.Docker.Sdk\Sdk\Sdk.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:04.20
PS C:\Users\foo\Documents\Visual Studio 2017\Projects\WebApplication10>

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.1)

Product Information:
Version: 1.0.1
Commit SHA-1 hash: 005db40

Runtime Environment:
OS Name: Windows
OS Version: 10.0.14393
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\1.0.1

@livarcocc

This comment has been minimized.

Copy link
Member

livarcocc commented Mar 28, 2017

cc @MichaelSimons

This is an SDK that ships only with VS. It is not supported in the CLI.

@billpratt

This comment has been minimized.

Copy link
Author

billpratt commented Mar 29, 2017

Right, completely understand that. By adding the docker-compose project feature to a solution completely breaks running dotnet restore and dotnet build on a solution file. Since the dcproj is a VS2017 feature, I dont expect dotnet to build it, but perhaps ignore it.

The microsoft/aspnetcore-build:1.0-1.1 docker image has "fixed" this by adding the SDK in the dotnet path. Howerver, I hope this is a temporary workaround.

root@8ca61219426a:/usr/share/dotnet# find / -xdev 2>/dev/null -name "Microsoft.Docker.Sdk"
/usr/share/dotnet/sdk/1.0.1/Sdks/Microsoft.Docker.Sdk
@livarcocc

This comment has been minimized.

Copy link
Member

livarcocc commented Mar 29, 2017

There is a PR out right now add this SDK to the CLI, which should address this issue.

#6180

@livarcocc livarcocc closed this Mar 29, 2017

@billpratt

This comment has been minimized.

Copy link
Author

billpratt commented Mar 29, 2017

Great! Thanks for the quick turn around

@jgreene

This comment has been minimized.

Copy link

jgreene commented Apr 25, 2017

It appears this issue was closed since #6180 is supposed to resolve it. Then #6180 was closed because it requires the Microsoft.Docker.SDK to be open sourced before it can be merged. So how are users supposed to resolve this issue going forward?

@philcontrolf1

This comment has been minimized.

Copy link

philcontrolf1 commented Apr 25, 2017

@jgreene In the short term, you just need to copy the appropriate files from the VS 2017 installation (C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks\Microsoft.Docker.Sdk) to where dotnet expects to find them (C:\Program Files\dotnet\sdk\1.0.1\Sdks\Microsoft.Docker.Sdk on Windows, /opt/dotnet/sdk/1.0.1/Sdks/Microsoft.Docker.Sdk on *nix). Longer term hopefully the SDK will be open sourced and these files can be distributed...

@billpratt

This comment has been minimized.

Copy link
Author

billpratt commented Apr 26, 2017

@livarcocc I propose that this issue be re-opened since there is no fix currently in place except for manually copying SDK files.

@jgreene

This comment has been minimized.

Copy link

jgreene commented Apr 26, 2017

@philcontrolf1 thank you for the solution, this worked for me

@AlexandreOuellet

This comment has been minimized.

Copy link

AlexandreOuellet commented Apr 28, 2017

Manually copying the files also worked for me, but I also suggest to reopen this issue, as it is indeed an issue until the files are distributed with the CLI.

@philcontrolf1

This comment has been minimized.

Copy link

philcontrolf1 commented May 18, 2017

With vague apologies for the self-promotion, having put together a whole pipeline of .NET Core 1.1, Visual Studio 2017 and Docker on TeamCity, I wrote a blog post for work on it - hopefully it will help anyone else trying to do this.

@khayes

This comment has been minimized.

Copy link

khayes commented May 22, 2017

I also ran into this today. Copying the files is non-ideal as we run dotnet restore on a dynamic build system and having to do this on every build agent is awkward.

@philcontrolf1

This comment has been minimized.

Copy link

philcontrolf1 commented May 22, 2017

@khayes Our build agent bootstrapper copies the files on - see my blog post for details.

@opless

This comment has been minimized.

Copy link

opless commented Jun 15, 2017

In the community edition the sdk is:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Sdks\Microsoft.Docker.Sdk"

... and for 2.0.0-preview1-005977 on OSX you need to put the files here:
/usr/local/share/dotnet/sdk/2.0.0-preview1-005977/Sdks/

@rainersigwald

This comment has been minimized.

Copy link
Collaborator

rainersigwald commented Jul 7, 2017

Since these extensions are installed to VS's copy of msbuild but not dotnet's, can you run the build with msbuild.exe instead of dotnet build?

@philcontrolf1

This comment has been minimized.

Copy link

philcontrolf1 commented Jul 11, 2017

@rainersigwald Not on my Linux CI build agents I can't :-)

@srivatsn

This comment has been minimized.

Copy link

srivatsn commented Jul 18, 2017

Reopening this issue since it hasn't been resolved yet. I think not being able to build a solution that contains a dcproj without hacks is a significant blocker.

@dazhao-msft - any updates on #6180

@srivatsn srivatsn reopened this Jul 18, 2017

@billpratt

This comment has been minimized.

Copy link
Author

billpratt commented Jul 19, 2017

@srivatsn thank you for re-opening

@dmitry606

This comment has been minimized.

Copy link

dmitry606 commented Jul 31, 2017

The fix (copying VS Docker SDK to dotnet sdk) does not seem to work for 2.0.0-preview2. I get this error:
C:\Program Files\dotnet\sdk\2.0.0-preview2-006497\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(80,45): error MSB4022: The result "" of evaluating the value "$(DockerBuildTasksAssembly)" of the "AssemblyFile" attribute in element is not valid. [C:\repos\WebApplication1\docker-compose.dcproj]

Any solutions for this?

@philcontrolf1

This comment has been minimized.

Copy link

philcontrolf1 commented Aug 1, 2017

@dmitry606 Seems to work for me:

PS D:\Source\HelloWorld> dir

Directory: D:\Source\HelloWorld

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       01/08/2017     09:15                bin
d-----       01/08/2017     09:15                HelloWorld
d-----       01/08/2017     09:15                obj
-a----       01/08/2017     09:15            271 docker-compose.ci.build.yml
-a----       01/08/2017     09:15            723 docker-compose.dcproj
-a----       01/08/2017     09:15             14 docker-compose.override.yml
-a----       01/08/2017     09:15            370 docker-compose.vs.debug.yml
-a----       01/08/2017     09:15            264 docker-compose.vs.release.yml
-a----       01/08/2017     09:15            136 docker-compose.yml
-a----       01/08/2017     09:15           1479 HelloWorld.sln


PS D:\Source\HelloWorld> dotnet --version
2.0.0-preview2-006497
PS D:\Source\HelloWorld> dotnet build .\HelloWorld.sln
Microsoft (R) Build Engine version 15.3.388.41745 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  HelloWorld -> D:\Source\HelloWorld\HelloWorld\bin\Debug\netcoreapp1.1\HelloWorld.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:01.97
PS D:\Source\HelloWorld> dotnet run --project .\HelloWorld\HelloWorld.csproj
Hello World!

Have you got exactly the same SDK files in exactly the same location?

$ sha1sum /cygdrive/c/Program\ Files/dotnet/sdk/2.0.0-preview2-006497/Sdks/Microsoft.Docker.Sdk/Sdk/*
a30e05d5e5d250884a2e5a29f4730f95e0fb6f85 */cygdrive/c/Program Files/dotnet/sdk/2.0.0-preview2-006497/Sdks/Microsoft.Docker.Sdk/Sdk/Sdk.props
cea93148ba2a590fbda25bfba0ed561f510e6c4a */cygdrive/c/Program Files/dotnet/sdk/2.0.0-preview2-006497/Sdks/Microsoft.Docker.Sdk/Sdk/Sdk.targets

(/cygdrive/c is just C:\ in case you're not a Cygwin person)

@dmitry606

This comment has been minimized.

Copy link

dmitry606 commented Aug 1, 2017

@philcontrolf1 Yes, it's exactly the same location

`c:\repo\HelloWorld>cd C:\Program Files\dotnet\sdk\2.0.0-preview2-006497\Sdks\Microsoft.Docker.Sdk\Sdk

C:\Program Files\dotnet\sdk\2.0.0-preview2-006497\Sdks\Microsoft.Docker.Sdk\Sdk>dir

Directory of C:\Program Files\dotnet\sdk\2.0.0-preview2-006497\Sdks\Microsoft.Docker.Sdk\Sdk

07/31/2017 03:59 PM

.
07/31/2017 03:59 PM ..
07/28/2017 06:50 PM 1,927 Sdk.props
07/28/2017 06:50 PM 1,220 Sdk.targets
2 File(s) 3,147 bytes
`

@philcontrolf1

This comment has been minimized.

Copy link

philcontrolf1 commented Aug 1, 2017

@dmitry606 You've definitely got different files though - my Sdk.props is 1750 bytes and my Sdk.targets is 1264 bytes. Both copied from C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks\Microsoft.Docker.Sdk\Sdk with Visual Studio 15.2.26430.16, although I don't think they've changed in a while.

@dmitry606

This comment has been minimized.

Copy link

dmitry606 commented Aug 1, 2017

@philcontrolf1 Yep.. looks like that. I copied the SDK from VS 2017 Preview 2. Probably they broke the SDK in preview2. For now I decided to use Visual Studio for build, hope it will be fixed soon..

@dazhao-msft

This comment has been minimized.

Copy link

dazhao-msft commented Aug 1, 2017

@dmitry606 It looks like that you copied the Microsoft.Docker.Sdk folder from VS 15.3 Preview, under which there are 3 folders: build, Sdk, tools. Please delete build and tools and only keep Sdk.

@dmitry606

This comment has been minimized.

Copy link

dmitry606 commented Aug 1, 2017

@dazhao-msft It worked! Thanks!!

@milla

This comment has been minimized.

Copy link

milla commented Aug 11, 2017

now Linux .net core 2.0 sdk doesn't support docker? I got
docker-compose.dcproj : error MSB4236: The SDK 'Microsoft.Docker.Sdk' specified could not be found.

@philcontrolf1

This comment has been minimized.

Copy link

philcontrolf1 commented Aug 11, 2017

@milla Have you copied the appropriate SDK as listed in this thread? If so, exactly which files did you copy, where did you copy them from, and where did you copy them to? A number of us have this working under Preview 2, so it's definitely not completely broken.

@mkoertgen

This comment has been minimized.

Copy link

mkoertgen commented Oct 3, 2017

Ok, the suggested workaround fixes dotnet restore and dotnet build.

How about dotnet run?

Unable to run your project.
Please ensure you have a runnable project type and ensure 'dotnet run' supports this project.
A runnable project should target a runnable TFM (for instance, netcoreapp2.0) and have OutputType 'Exe'.
The current OutputType is 'DockerCompose'.

Seems that the output type is not supported. Any idea on how to work around this, too?

@mlowijs

This comment has been minimized.

Copy link

mlowijs commented Oct 16, 2017

As another workaround, one could run dotnet sln MySolution.sln remove docker-compose.dcproj to remove the project reference.

This is what I do in my VSTS build definition.

@Vlaaaaaaad

This comment has been minimized.

Copy link

Vlaaaaaaad commented Nov 6, 2017

Will this ever be fixed?

@sheigel

This comment has been minimized.

Copy link

sheigel commented Nov 12, 2017

After so many years of generating frustration it seems that Visual Studio still takes priority to having a working/proper CLI.
It seems that having a strong CLI that always works is much more useful than having a slow running IDE that either way should not be installed on the CI machine. But for the sake of having this single IDE more click-friendly you are willing to break something so foundational as platform independence.

I was looking through the eShopOnContainers. I was so happy to have dotnet, docker and Mac working together. I wanted to start with the WebMonolithic solution. But I cannot even dotnet restore.

You've put a lot of effort in making dotnet core a good platform for the current times. Is it a bad idea to make sure that whatever feature is added it is working first on the CLI and then see what can be done for VS?

@billpratt

This comment has been minimized.

Copy link
Author

billpratt commented Nov 16, 2017

@DamianEdwards @shanselman Sorry to include you two on this issue but we haven't received feedback on this issue for some time now and we are looking for help. More and more people are coming to this issue as well as the closed PR that would have fixed it.

@tyronegroves

This comment has been minimized.

Copy link

tyronegroves commented Dec 4, 2017

So no fix?

@shanselman

This comment has been minimized.

Copy link
Contributor

shanselman commented Dec 4, 2017

ping @richlander ?

@zunair-ch

This comment has been minimized.

Copy link

zunair-ch commented Jan 30, 2018

I open Docker CLI as an administrator and just move to the project directory and run following set of commands and it works for me. Also make sure kitematics is running if you are on windows 8.

  1. dotnet restore
  2. dotnet build
  3. dotnet run
@mmisztal1980

This comment has been minimized.

Copy link

mmisztal1980 commented Jan 30, 2018

Is this going to get fixed with .net core 2.1?

@zunair-ch

This comment has been minimized.

Copy link

zunair-ch commented Jan 30, 2018

Yes.For me, it's working for .net core 2.0 and 2.1

@philcontrolf1

This comment has been minimized.

Copy link

philcontrolf1 commented Jan 30, 2018

@zunair-ch Yes, it will work in the project directory because then all you're building is the one project. What happens if you build the solution - e.g. dotnet build ./MySolution.sln in the solution directory?

@philcontrolf1

This comment has been minimized.

Copy link

philcontrolf1 commented Jan 31, 2018

For all the watchers here: #8416 should fix this one. I've just bumped it to see if there's anything blocking it.

@livarcocc livarcocc closed this Feb 9, 2018

@livarcocc livarcocc added this to the 2.1.3xx milestone Feb 9, 2018

@billpratt

This comment has been minimized.

Copy link
Author

billpratt commented Feb 9, 2018

This a good to hear. Thanks for fixing!

@zunair-ch

This comment has been minimized.

Copy link

zunair-ch commented Feb 10, 2018

mjrousos added a commit to mjrousos/dotnet-apiport that referenced this issue May 15, 2018

Remove the docker-compose project from the sln
It was blocking solution-level restore from working (dotnet/cli#6178) and didn't work to launch Docker containers from VS anyhow (Microsoft/DockerTools#54)

mjrousos added a commit to Microsoft/dotnet-apiport that referenced this issue May 16, 2018

Remove docker-compose project from the sln (#647)
* Remove the docker-compose project from the sln
  * It was blocking solution-level restore from working (dotnet/cli#6178) and didn't work to launch Docker containers from VS anyhow (Microsoft/DockerTools#54)
* Remove .dcproj since it's not currently used
@TomaszG

This comment has been minimized.

Copy link

TomaszG commented Jul 13, 2018

I'm currently facing the same problem - solution with docker-compose.dcproj (added by VS after adding enabling docker support) cannot be built or restored with dotnet CLI.
C:\Program Files\dotnet\sdk\2.1.301\NuGet.targets(114,5): error : Invalid restore input. Invalid target framework 'unsupported'. Input files: C:\project\src\docker-compose.dcproj. [C:\project\src\something.sln]

Looking at the comments above I think it should be working, however it doesn't (at least for me). Am I missing something?

Below is dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.301
 Commit:    59524873d6

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.16299
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.301\

Host (useful for support):
  Version: 2.1.1
  Commit:  6985b9f684

.NET Core SDKs installed:
  1.0.0 [C:\Program Files\dotnet\sdk]
  2.1.4 [C:\Program Files\dotnet\sdk]
  2.1.101 [C:\Program Files\dotnet\sdk]
  2.1.102 [C:\Program Files\dotnet\sdk]
  2.1.103 [C:\Program Files\dotnet\sdk]
  2.1.104 [C:\Program Files\dotnet\sdk]
  2.1.201 [C:\Program Files\dotnet\sdk]
  2.1.301 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

@gitfool

This comment has been minimized.

Copy link

gitfool commented Dec 19, 2018

Same problem here with SDK 2.2.101. 😞

@joergjo

This comment has been minimized.

Copy link

joergjo commented Dec 22, 2018

The latest Docker support for ASP.NET Core projects doesn't use .dcproj anymore. So if you recreate your project structure with the latest tooling, you won't run into this issue anymore.

@gitfool

This comment has been minimized.

Copy link

gitfool commented Dec 22, 2018

@joergjo I tried; that only works if a single Dockerfile suffices. If you need to use docker-compose, after creating a new project, right-click Add Orchestrator Support and it adds a dcproj file to the sln and refers to it in the WebApplication csproj:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
    <DockerDefaultTargetOS>Linux</DockerDefaultTargetOS>
    <UserSecretsId>f3532c1f-c8ec-4713-8e86-0fc6ebc385c8</UserSecretsId>
    <DockerComposeProjectPath>..\docker-compose.dcproj</DockerComposeProjectPath>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.2.0" PrivateAssets="All" />
    <PackageReference Include="Microsoft.VisualStudio.Azure.Containers.Tools.Targets" Version="1.0.2105168" />
  </ItemGroup>
</Project>

... and the command-line build fails again:

Microsoft (R) Build Engine version 15.9.20+g88f5fadfbe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

C:\Program Files\dotnet\sdk\2.2.101\NuGet.targets(114,5): error : Invalid restore input. Invalid target framework 'unsupported'. Input files: D:\Devel\Repos\WebApplication1\docker-compose.dcproj. [D:\Devel\Repos\WebApplication1\WebApplication1.sln]

Build FAILED.

There is a newer version available on NuGet, compared to what was generated by the right-click experience, of Microsoft.VisualStudio.Azure.Containers.Tools.Targets, but that doesn't help.

I don't know the details, but it seems to me that we're still blocked on the Microsoft.Docker.Sdk being open sourced before we can use the dotnet CLI to build these solutions on Linux.

(Note: Although I did the above quick & dirty build on Windows, my requirements are to be able to also do the above build on Linux for CI/CD on a build server, ultimately in a Docker container, and with that in mind I think I see another problem that Microsoft.VisualStudio.Azure.Containers.Tools.Targets currently only targets .NET Framework 4.6.1, so presumably it also needs to target .NET Standard 2.0 for my dream scenario to work.)

@joergjo

This comment has been minimized.

Copy link

joergjo commented Feb 2, 2019

I hadn't even noticed that feature!

I always use the "basic" Docker support (i.e. no .dcproj), and add docker-compose files manually as required.

If I want to debug a containerized app with its dependencies running in Docker as well (which rarely happens), I start all dependencies using docker-compose before debugging the actual app, and expose their ports on the host. In this setup, the application can resolve its dependencies using host.docker.internal as host name. It's requires a few more manual steps and works only for a debugging a single container, but it saves me all the .dcproj headache you've mentioned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment