Closed Regenhardt closed 1 year ago
As the error seems to be coming from dotnet restore, this does not appear to be a roslyn issue.
Sorry thought it's something with the compiler so I put it here. Nuget then? Or something else still?
Or somewhere for visual studio because of how the dockerfile was generated and docker info added to the project file?
Not sure who owns dotnet restore
. @rainersigwald do you know where this should move to?
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
But the relevant projects use properties
defined in another file (Directory.Build.props
) that isn't copied
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.
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.
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 ProjectReference
s?
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!
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!
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.
Alright I submitted a ticket describing the issue.
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]
Version Used:
6.0.406 Steps to Reproduce:
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:
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: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.