dotnet build fails on solution with .net framework project while msbuild succeeds

[krishnan-unni]

When I try to build a solution that contains a .Net Framework project which consumes a nuget package which is multi targeted, it fails to build with "dotnet build" command while it builds fine in visual studio or with command msbuild

I have a solution with 4 projects :

• ProjectA (.Net standard class library) - root project
• ProjectB (.Net standard class library) - references ProjectA , Creates a multi targeted nuget package (net461, netstandard2.0) called ProjectB.nupkg on build which also contain libraries of ProjectA.
• ClientA (.Net core 3.1 Console App) - consumes ProjectB.nupkg nuget package and use it to perform operations
• ClientB (.Net Framework 4.6.1 Console App) - consumes ProjectB.nupkg nuget package and use it to perform operations (exactly same as ClientA )

When I build the solution in Visual studio 2019 or with CLI using msbuild.exe command, the solution builds fine; ProjectB's nuget package generated and client apps build fine and I am able to execute them as well.

When I build the same solution using "dotnet build" (it is what is used in the CI pipeline) all the projects executes and build fine except ClientB which is the .net framework project. The error is:

"Restored ClientB.csproj (in 251 ms).
3 of 4 projects are up-to-date for restore.
The type or namespace name '{ProjectA's namespace}' could not be found (are you missing a using directive or an assembly reference?"

This points out that the build is not compiling ClientB project properly or not restoring the nuget package for it properly, making it miss those dependent namespaces.

Is this expected or a shortcoming/bug with "dotnet build" building .Net Framework projects in solutions?

Additional information:

When ever I build the solution using "dotnet build" and it fails, then I try to build the same in Visual Studio the following error is thrown for ClientB project:

" Error: Your project file doesn't list 'win' as a "RuntimeIdentifier". You should add 'win' to the "RuntimeIdentifiers" property in your project file and then re-run NuGet restore. (1, 1)"

It doesn't make any difference even if I add the RID in csproj file. Then when I go and delete the 'obj' folder for that project and builds, I get the same error in Visual Studio as in dotnet cli - References not found.

When I close my Visual Studio and open the solution again and then do a build - All good. Successful build.
This points to some issue with the way dotnet restores the nuget and treats the projects while building.

[carlossanlop]

@joperezr could you help with this?

[joperezr]

@krishnan-unni thanks for logging this. Can you repro locally on a clean environment if you try to do dotnet build? Sounds like the issue in your case is something related with Restore, since the first time you build after clearing out obj seems like it is failing as well but the second time works out fine. If you could, clean bin and obj directory and then perform a build like:
dotnet build yourSolution.sln /bl:msbuild.binlog and then share the msbuild.binlog file that gets generated as part of that execution? That will probably give us some hints as to why is your build failing the first time around when restore hasn't happened yet.

[carlossanlop]

Closing due to lack of response.

[zachrybaker]

I am still reproducing this, fwiw, in the scenario of a solution with a mix of v2015 and v2015 (sdk-style) csproj formats, where the targetframwork is net472 on the sdk csprojs and v4.7.2 on the v2015 csprojs, with one of the final projects requiring a nuget package that has netstandard2.0;net472

the restore solution will bring in the nuget package dependency correctly, and then a build in VS will remove it. However, from the console, doing an msbuild -t:restore, then an msbuild -t:build on the same machine it is successful.

I am on the latest VS2019, 16.8.4, with MSBuild 16.8.3.61104, nuget 5.81.

Ultimately I am thinking that perhaps I have an unsupported scenario.
I do get one warning in msbuild that might be a hint, although I have not been able to sort out the truth to that theory:

MSB4011: "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Microsoft.Common.props" cannot be imported again. It was already imported at "C:\Program Files\dotnet
\sdk\5.0.102\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.props (40,3)". This is most likely a build authoring error. This subsequent import will be ignored.

That is in an sdk project that is a dependency of two later projects, and just inside the root node:

As I did not add this myself, I am a bit confused about it and have not found adequate information to know what knobs it exposes, but I can't help but think that knowing the secrets to it means I can get builds in visual studio to not stomp out nuget restore operations.

Either way, certain early projects, if I roll them back to the v2015 csproj format, and clear all the obj and bin folders, will still get the RuntimeIdentifier issue described above. I was not able to find any workaround on the web that actually worked, and again, I wouldn't expect to need this RuntimeIdentifier element in a v2015 csproj in the first place.

[nathanpovo]

Started getting this issue after migrating from packages.config to PackageReference. The project was a net framework 4.8 with the old style csproj.

The fix, as described in this comment, is to either:

• convert the csproj to the sdk style
• revert back to using a packages.config file

Both of these solutions worked in my case.

Make sure to clean out your bin and obj when doing these changes since that might cause unrelated errors to be thrown.