Hello, I'm trying to use docker-compose support with vs and already got some bugs.
I faced something like https://github.com/dotnet/cli/issues/6178 , steps to reproduce:
dcproj to solutiondotnet restore Solution.sln --ignore-failed-sources -r linux-musl-x64 -v n -funsupported is unacceptable. I got error message in russian (although I setted DOTNET_CLI_UI_LANGUAGE to en_US)C:\Program Files\dotnet\sdk\3.0.100-preview8-013656\NuGet.targets(123,5): error : Входные данные восстановления недопустимы. Целевая платформа "unsupported" недопустима. Входные файлы: c:\Src\docker-compose.dcproj. [c:\Src\Solution.sln]
I suppose that nuget client want TargetFramework from dc project, although Microsoft.Docker.Sdk contains
<ResolveNuGetPackages>false</ResolveNuGetPackages>
<SkipImportNuGetProps>true</SkipImportNuGetProps>
<SkipImportNuGetBuildTargets>true</SkipImportNuGetBuildTargets>
Okay I can remove dcproj, restore / build and then add project back, right? NO.
dotnet sln Solution.sln remove docker-compose.dcproj
dotnet restore Solution.sln --ignore-failed-sources -r linux-musl-x64 -v n -f
dotnet build Solution.sln --nologo --no-restore -c Debug -r linux-musl-x64
everything is ok here, but dotnet sln Solution.sln add docker-compose.dcproj throws:
Project 'c:\Src\docker-compose.dcproj' has an unknown project type and cannot be added to the solution file. Contact your SDK provider for support.
So I'm here, can you fix it or give me workaround?
@vchirikov What version of .NET CLI are you using? What version of Visual Studio? I was not able to reproduce the issue with a 3.0 .NET CLI.
dotnet --version
3.0.100-preview8-013656
VS v16.3.0 preview .2.0
It's strange. for start try reproduce second bug with dotnet sln Solution.sln add docker-compose.dcproj, after confirmation of this bug, I will try to make repro playground for you (my current project is too complex structure etc)
@vchirikov I'm able to reproduce the second part:
PS C:\Users\brandonw\source\repos\BlazorApp2> dotnet sln add .\docker-compose.dcproj
Project 'C:\Users\brandonw\source\repos\BlazorApp2\docker-compose.dcproj' has an unknown project type and cannot be added to the solution file. Contact your SDK provider for support.
This issue is with the dotnet CLI though, not something that we ourselves can resolve.
@bwateratmsft - Regarding the "Project {0} has an unknown project type" error: in the past we elected not to include the full Docker-Compose SDK in .NET Core (primarily because of the complications around open sourcing the SDK). So, in theory at least, we could work with the .NET Core team and revisit what it would take to resolve this.
Separately, regarding the "Invalid target framework 'unsupported'" error -- it seems that dotnet cli issue 6178 has regressed. We should definitely engage with the dotnet CLI folks regarding this to determine what's happened.
@sgreenmsft It seems like even if the SDK isn't present, it should allow adding the project to the solution?
I think the design choice they make is to not add things to a solution file if doing so would result in the inability of the dotnet CLI to successfully build that solution file.
Can you talk to the CLI command yourself or do I need to recreate the issue there?
up, any news? Can you fix it before release 3.0?
@vchirikov - Apologies for the delayed response. I, like Brandon, was also unable to reproduce the "Invalid target framework 'unsupported'" error using dotnet CLI version 3.0.100-preview8-013656. Do you have any more details on how to reproduce the problem or a sample solution that exhibits the behavior?
I have the same issue. Adding<TargetFramework>netcoreapp2.0</TargetFramework> to the PropertyGroup node in the dcproj file fixes the issue. I have to add it manually.
It doesn't make any sense for docker-compose project to target any framework, but it seems like dotnet CLI requires it to work.
@vchirikov Can you provide a repro project for the "Invalid target framework 'unsupported'" error? It looks like someone else ran into the same issue here, but was unable to reproduce it in a simple project.
@sgreenmsft @dsplaisted
Finally I found how to make the minimal repro. Bug in restore command with Directory.build.props with PackageReference + dcproj.
Still can reproduce with 3.1.100-preview2-014569
dotnet_cli_bug.zip
@sgreenmsft , @dsplaisted
Can you reproduce now?
@vchirikov I am able to reproduce this. I am investigating a long term wholistic fix. To unblock you can you try adding:
Condition="'$(MSBuildProjectExtension)' != '.dcproj'"
To the ItemGroup(s) in Directory.build.props for your PackageReferences?
I think I'm in the exact same situation as @vchirikov now. We just added a packagereference for git versioning into the root Directory.Build.props file and I would've never made the connection. Awesome work!
I was not able to fix this for net5.0 project by doing the following:
[not a fix]
<TargetFramework>net5.0</TargetFramework> to docker-composer.dcsprojdotnet sln ./Epam.MentorHub.Api.sln remove docker-compose.dcprojdotnet sln ./Epam.MentorHub.Api.sln add docker-compose.dcproj[fix] I've added Condition="'$(MSBuildProjectExtension)' != '.dcproj'" to root Directory.Build.props
It was troublesome to find a workaround for this. I don't have a fun time using docker-compose tooling inside VS .
$ dotnet --version
5.0.200
Most helpful comment
I think I'm in the exact same situation as @vchirikov now. We just added a packagereference for git versioning into the root Directory.Build.props file and I would've never made the connection. Awesome work!