dotnet restore fails when .dcproj is part of solution

[dazinator]

Describe the bug

Using dotnet sdk 6.0.413 do a dotnet restore of a solution that contains a docker compose project dcproj - it will fail with the error Invalid target framework 'unsupported' - there is seemingly no way to ignore this project

A recent comment on #8019 suggests this is still an issue - but that one is closed.. The suggested workaround from that person was to use dotnet sln to remove the compose project from the solution file prior to running dotnet restore, but this seems very cumbersome. My build also runs dotnet format and also checks in any modifications to source files, so if a sln file is modified that would get pushed up - so in reality I'd have to remove it prior to the restore step, then add it back afterwards. yuk.

To Reproduce

In Visual Studio 2022: File->New Project->ASP.NET Core Web Application targeting .NET 6 Choose either Web API or Web Application Check "Enable Docker Support" Add a global json to use 6.0.413 of the sdk. Go to command line and run

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

Exceptions (if any)

Invalid target framework 'unsupported'

Output from github actions:

Run dotnet restore --ignore-failed-sources dotnet restore --ignore-failed-sources shell: /usr/bin/bash -e {0} Determining projects to restore... /usr/share/dotnet/sdk/6.0.413/NuGet.targets(132,5): error : Invalid restore input. Invalid target framework 'unsupported'. Input files: /home/runner/work/Swarmestrate/Swarmestrate/src/Compose/compose.dcproj. [/home/runner/work/Swarmestrate/Swarmestrate/src/Solution.sln] Error: Process completed with exit code 1.

Further technical details

.NET SDK (reflecting any global.json): Version: 6.0.413 Commit: 10710f7d8e

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

global.json file: C:\Users\FOO\Repos\Swarmestrate\src\global.json

Host: Version: 6.0.21 Architecture: x64 Commit: e40b3abf1b

.NET SDKs installed: 6.0.413 [C:\Program Files\dotnet\sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 6.0.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 6.0.21 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 6.0.21 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Download .NET: https://aka.ms/dotnet-download

Learn about .NET Runtimes and SDKs: https://aka.ms/dotnet/runtimes-sdk-info

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[dazinator]

Note: The workaround to do a dotnet remove of the dcproj prior to restoring initally seems to work, but it then cannot be added back by dotnet sln add as "It has an "unknown project type"

My Pipeline goes on to detect any source code modifications (made by dotnet forma) and push them up in a git commit, so this means the modified sln file gets pushed back up which is not what I want.

[KalleOlaviNiemitalo]

Is it possible to work around "unknown project type" in dotnet sln add, by adding a ProjectTypeGuids property into the dcproj file, like in https://github.com/dotnet/sdk/issues/9497#issuecomment-398514163? With the same GUID as what Visual Studio adds to the solution file.

Or, if your pipeline does not expect dotnet format to modify the solution file, it could just exclude *.sln from the Git commit.

[dazinator]

@KalleOlaviNiemitalo

Is it possible to work around "unknown project type" in dotnet sln add, by adding a ProjectTypeGuids property into the dcproj file, like in #9497 (comment)? With the same GUID as what Visual Studio adds to the solution file.

Thanks for this, yes adding the following to the dcproj file allows dotnet sln add to add the compose project back after it was removed as a workaround for enabling dotnet restore to work.

<ProjectTypeGuids>FAE04EC0-301F-11D3-BF4B-00C04F79EFBC</ProjectTypeGuids>

[dazinator]

I think an msbuild project property similar to <IsPackable> should be introduced - i.e IsRestorable - and then when dotnet restore is used on a solution it can skip over projects with <IsRestorable>false</IsRestorable> just like dotnet pack does for the former.

This workaround is a pain that will have to be used in any CI/CD pipeline wherever a restore is done, so would like to know that there is atleast some longer term solution in play.

[KalleOlaviNiemitalo]

Does the dcproj cause an error from dotnet list package on the solution, as well? If it does, and an MSBuild property is defined for marking skippable projects and used for that too, then I don't think it should be called IsRestorable.

[dazinator]

for marking skippable projects and used for that too, then I don't think it should be called IsRestorable.

Why not? Surely only restorable projects would have packages to list? i.e if they aren't restorable then they also inherently shouldn't have any packages to list?

[dazinator]

Does the dcproj cause an error from dotnet list package on the solution, as well?

This command succeeds in terms of exit code, but it outputs warnings for any projects that have not successfully been restored first.

No assets file was found for /home/runner/work/Swarmestrate/Swarmestrate/src/Compose/compose.dcproj. Please run restore before running this command.

So this also implies that if a project is not restorable its also not "package listable" and this this command skips over projects that have not yet been restored.

[dazinator]

Note: It's also necessary to add <IsPackable>False</IsPackable> to the dcproj file else you will get a similar error when doing dotnet pack at an sln level. I now have a new problem, dotnet restore works, but dotnet pack fails, even after adding <IsPackable>False</IsPackable> to the dcproj file:

github actions output:

Run dotnet pack src --no-build --no-restore --configuration Release -p:IncludeSymbols=true -p:SymbolPackageFormat=snupkg /p:PackageVersion=$SEMVER
  dotnet pack src --no-build --no-restore --configuration Release -p:IncludeSymbols=true -p:SymbolPackageFormat=snupkg /p:PackageVersion=$SEMVER
  shell: /usr/bin/bash -e {0}
  env:
    SEMVER: 0.1.0-alpha.107
MSBuild version 17.7.1+971bf70db for .NET
/home/runner/work/Swarmestrate/Swarmestrate/src/Compose/compose.dcproj : error MSB4057: The target "pack" does not exist in the project.
/usr/share/dotnet/sdk/7.0.400/Sdks/NuGet.Build.Tasks.Pack/build/NuGet.Build.Tasks.Pack.targets([2](https://github.com/dazinator/Swarmestrate/actions/runs/6074085147/job/16477325622#step:10:2)0[3](https://github.com/dazinator/Swarmestrate/actions/runs/6074085147/job/16477325622#step:10:3),[6](https://github.com/dazinator/Swarmestrate/actions/runs/6074085147/job/16477325622#step:10:7)): warning : This project cannot be packaged because packaging has been disabled. Add <IsPackable>true</IsPackable> to the project file to enable producing a package from this project. [/home/runner/work/Swarmestrate/Swarmestrate/src/Manager/Manager.csproj]
Error: Process completed with exit code 1.

[dazinator]

There are yet more workaround to get dotnet pack to work, some listed here: https://stackoverflow.com/questions/56018033/cant-exclude-dcproj-from-dotnet-pack

The easiest remedy seems to add a dummy pack target to the dcproj

https://stackoverflow.com/questions/56018033/cant-exclude-dcproj-from-dotnet-pack

So all pertinent things shown below:-

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" Sdk="Microsoft.Docker.Sdk">
    <PropertyGroup Label="Globals">
       ... shortened for brevity      
        <ProjectTypeGuids>FAE04EC0-301F-11D3-BF4B-00C04F79EFBC</ProjectTypeGuids>
        <IsPackable>False</IsPackable>
    </PropertyGroup>   
<!--see https://stackoverflow.com/questions/56018033/cant-exclude-dcproj-from-dotnet-pack-->
    <Target Name="Pack">
    </Target>
</Project>

Github actions example

      # see https://github.com/dotnet/sdk/issues/35134
      - name: Remove compose proj from sln
        working-directory: './src'
        run: dotnet sln remove $(dotnet sln list | grep .dcproj)

      - name: Restore dependencies
        working-directory: './src'
        run: dotnet restore

      # see https://github.com/dotnet/sdk/issues/35134
      - name: Add compose proj back to sln
        working-directory: './src'
        run: dotnet sln add **/*.dcproj

[KUTlime]

I found a different fix, because my problem related to the presence of Directory.Build.props, see this comment in this issue.

[SeWieland]

For me this is still not fixed at all and really annoying as we added compose projects to pretty much any project with integration tests.

Of course you can remove the project, restore the sln and re-add it back in your pipelines. But this is very annoying on a daily bases when you need to restore on your local machine.

[evolve700]

I have just stumbled upon this. In my case <RestoreProjectStyle>PackageReference</RestoreProjectStyle> in Directory.Build.props was at fault.

Fixed it by including the condition mentioned in the comment by @KUTlime.