Closed billpratt closed 4 years ago
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
Is this going to get fixed with .net core 2.1?
Yes.For me, it's working for .net core 2.0 and 2.1
@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?
For all the watchers here: dotnet/cli#8416 should fix this one. I've just bumped it to see if there's anything blocking it.
This a good to hear. Thanks for fixing!
Thanks all.
On 10 Feb 2018 4:24 am, "Bill Pratt" notifications@github.com wrote:
This a good to hear. Thanks for fixing!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/cli/issues/6178#issuecomment-364598176, or mute the thread https://github.com/notifications/unsubscribe-auth/ARNoP8UM8gxIaBy9-ch9WV3DH_Yt8sXvks5tTNOxgaJpZM4MsBSr .
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
Same problem here with SDK 2.2.101. 😞
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.
@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.)
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.
3.0.100-preview8-013656
still broken.
@livarcocc can you reopen this?
@vchirikov how is it broken for you?
@livarcocc you can read about it here https://github.com/microsoft/DockerTools/issues/209
Looking at the issue you referenced, the CLI team will not enable building this dcprojs in the command line. Though, there is now an SDK that should at least skip doing anything for it.
What seems like a bug to me is the failure to use dotnet sln add for dcprojs. If that's the case, I would suggest filling a brand new issue just for dotnet sln add.
@livarcocc Which SDK should skip dcprojs while building? I've just tested with 3.1.100-preview1-014459 and I'm unable to run dotnet build or dotnet test on solution containing dcproj file. The error is: C:\Program Files\dotnet\sdk\3.1.100-preview1-014459\NuGet.targets(123,5): error : Invalid restore input. Invalid target framework 'unsupported'.
And I have a workaround. Adding <TargetFramework>netcoreapp2.0</TargetFramework>
to the PropertyGroup node in the dcproj file fixes the issue.
Can you please file a separate and new issue for this? So that we can start fresh?!
@dsplaisted wonder if this is due to the framework composition work we did. Could you take a look?
Unfortunately I can't reproduce it with solution created from scratch with VS2017, VS2019 and different project types. Issue occurs only in my old and big repository, which I can't share.
Maybe there is a corner case that I have run into, but I can't really tell exactly what it is.
@livarcocc repro here https://github.com/microsoft/DockerTools/issues/209#issuecomment-551064216
How is this issue closed? dotnet restore is still broken for me with a dcproj file in the solution. Why are these projects not simply ignored?
Just for any others needing a workaround in their linux CI agents:
Use something like dotnet sln remove $(dotnet sln list | grep .dcproj)
and you're good
@SeWieland - I also have the same problem. As this one is closed I have opened issue https://github.com/dotnet/sdk/issues/35134
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
Expected behavior
Restore and build work when a Docker-Compose project (.dcproj) is in the solution. Should work across all platforms that
dotnet
is supportedActual 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.
Environment data
dotnet --info
output:.NET Command Line Tools (1.0.1)
Product Information: Version: 1.0.1 Commit SHA-1 hash: 005db40cd1
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