dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.7k stars 1.06k forks source link

Auto-generated Dockerfile fails with Invalid framework identifier '' #31011

Closed Regenhardt closed 1 year ago

Regenhardt commented 1 year ago

Version Used:
6.0.406 Steps to Reproduce:

  1. Create a .NET 6 library ./Src/MyLib
  2. Create a .NET 6 asp.net core hosted Blazor Wasm Application ./BlazorWasmDemo without docker support
  3. Add docker support to BlazorWasmDemo.Server project
  4. Build docker image from Dockerfile
  5. dotnet restore in build stage of Dockerfile fails

Actual Branch with problem: https://github.com/Regenhardt/fido2-net-lib/tree/feature/blazor-wasm

Diagnostic Id:

NETSDK 1013

Expected Behavior:

Dockerfile should build a runnable docker image.

Actual Behavior:

dotnet restore fails with /usr/share/dotnet/sdk/6.0.406/NuGet.targets(132,5): error : Invalid framework identifier ''. [/src/BlazorWasmDemo/Server/BlazorWasmDemo.Server.csproj]

Additional info:

I started up the image from a state just before the error occurs:

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS prebuild
WORKDIR /src
COPY ["nuget.config", "."]
COPY ["BlazorWasmDemo/Server/BlazorWasmDemo.Server.csproj", "BlazorWasmDemo/Server/"]
COPY ["Src/Fido2.AspNet/Fido2.AspNet.csproj", "Src/Fido2.AspNet/"]
COPY ["Src/Fido2/Fido2.csproj", "Src/Fido2/"]
COPY ["Src/Fido2.Models/Fido2.Models.csproj", "Src/Fido2.Models/"]
COPY ["BlazorWasmDemo/Client/BlazorWasmDemo.Client.csproj", "BlazorWasmDemo/Client/"]
COPY ["Src/Fido2.BlazorWebAssembly/Fido2.BlazorWebAssembly.csproj", "Src/Fido2.BlazorWebAssembly/"]
COPY ["BlazorWasmDemo/Shared/BlazorWasmDemo.Shared.csproj", "BlazorWasmDemo/Shared/"]

FROM prebuild as build
# This one crashes:
RUN dotnet restore "BlazorWasmDemo/Server/BlazorWasmDemo.Server.csproj"
COPY . .
WORKDIR "/src/BlazorWasmDemo/Server"
RUN dotnet build "BlazorWasmDemo.Server.csproj" -c Release -o /app/build

I then ran the dotnet restore command from a bash within the image, hoping to get more information, but I got exactly the same as before without extra information. I did however check the files before running it:

root@af1009dcaf2c:/src# ls BlazorWasmDemo/Server
BlazorWasmDemo.Server.csproj
root@af1009dcaf2c:/src# cat BlazorWasmDemo/Server/BlazorWasmDemo.Server.csproj
<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <UserSecretsId>d4e312c9-f55a-43e0-b3ea-699aa6421a5c</UserSecretsId>
    <DockerDefaultTargetOS>Linux</DockerDefaultTargetOS>
    <DockerfileContext>..\..</DockerfileContext>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.Server" Version="6.0.13" />
    <PackageReference Include="Microsoft.VisualStudio.Azure.Containers.Tools.Targets" Version="1.17.2" />
    <PackageReference Include="Swashbuckle.AspNetCore" Version="6.5.0" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\..\Src\Fido2.AspNet\Fido2.AspNet.csproj" />
    <ProjectReference Include="..\..\Src\Fido2\Fido2.csproj" />
    <ProjectReference Include="..\Client\BlazorWasmDemo.Client.csproj" />
  </ItemGroup>

</Project>
root@af1009dcaf2c:/src# dotnet restore BlazorWasmDemo/Server/BlazorWasmDemo.Server.csproj
  Determining projects to restore...
/usr/share/dotnet/sdk/6.0.406/NuGet.targets(132,5): error : Invalid framework identifier ''. [/src/BlazorWasmDemo/Server/BlazorWasmDemo.Server.csproj]

And I'm pretty sure the <TargetFramework>net6.0</TargetFramework> should be used by dotnet. I did however replace it with <TargetFrameworks> (plural) but the same error happens.

Without this dockerfile, the application works, both running as exe and starting in docker from within VS.

CyrusNajmabadi commented 1 year ago

As the error seems to be coming from dotnet restore, this does not appear to be a roslyn issue.

Regenhardt commented 1 year ago

Sorry thought it's something with the compiler so I put it here. Nuget then? Or something else still?

Regenhardt commented 1 year ago

Or somewhere for visual studio because of how the dockerfile was generated and docker info added to the project file?

CyrusNajmabadi commented 1 year ago

Not sure who owns dotnet restore. @rainersigwald do you know where this should move to?

rainersigwald commented 1 year ago

Not sure who owns dotnet restore. @rainersigwald do you know where this should move to?

It can be MSBuild, SDK, or NuGet, depending on what exactly is failing. Take your best guess and we'll reroute as necessary.

In this case I don't think there's a bug, exactly. @Regenhardt, the Dockerfile copies project files explicitly

https://github.com/Regenhardt/fido2-net-lib/blob/7228d986bbbfc5ab6c6e6e63758037485dd86ceb/BlazorWasmDemo/Server/Dockerfile#L11-L17

But the relevant projects use properties

https://github.com/Regenhardt/fido2-net-lib/blob/7228d986bbbfc5ab6c6e6e63758037485dd86ceb/BlazorWasmDemo/Server/BlazorWasmDemo.Server.csproj#L4

defined in another file (Directory.Build.props) that isn't copied

https://github.com/Regenhardt/fido2-net-lib/blob/7228d986bbbfc5ab6c6e6e63758037485dd86ceb/Directory.Build.props#L17

As a result, when evaluated inside the container, $(SupportedTargetFrameworks) and thus TargetFramework is empty.

You might file Visual Studio feedback that it'd be nice if it didn't generate a Dockerfile susceptible to this problem.

Regenhardt commented 1 year ago

Ah this little confusion is on me for linking all the things but not explaining enough:

This version with the property is just one version I tried.
Before this, I tried the standard version with TargetFramework (singular) defined directly, as seen in my original post in the terminal output of cat. This was also the version visual studio generated.

Additionally, I thought maybe the property could be a problem (although I didn't even once think the directory build props file could just be missing) so I manually put the value from the props file into the project file.

Both of those still produced this same error unfortunately.

rainersigwald commented 1 year ago

Before this, I tried the standard version with TargetFramework (singular) defined directly, as seen in my original post in the terminal output of cat. This was also the version visual studio generated.

When you did that, did you do it recursively for all ProjectReferences?

Regenhardt commented 1 year ago

I absolutely did not and will immediately try this as it seems a really obvious mistake now that you mentioned it. Will be back in a few minutes!

Regenhardt commented 1 year ago

Copying the Directory.Build.props indeed fixed this one, just gotta get a library referencing sourcelink to work inside the container now, many thanks for the help!

baronfel commented 1 year ago

If you have time, submitting the need to include Directory.Build.props (and many other necessary files like Directory.Build.targets, Directory.Packages.props, etc) in the generated Dockerfile over at VS Feedback would be great - the Docker tooling team does get feedback submitted through that method.

Regenhardt commented 1 year ago

Alright I submitted a ticket describing the issue.

rainersigwald commented 1 year ago

I absolutely did not and will immediately try this as it seems a really obvious mistake now that you mentioned it. Will be back in a few minutes!

I would certainly not describe it as "obvious" since the error message clearly blames it on a file that wasn't at fault.

/usr/share/dotnet/sdk/6.0.406/NuGet.targets(132,5): error : Invalid framework identifier ''. [/src/BlazorWasmDemo/Server/BlazorWasmDemo.Server.csproj]

https://github.com/NuGet/Home/issues/12470