Original situation
I have a library that is exposed to other (internal) projects as a nuget version. Before update it was at version 1.0.14. It did not have any dependencies other than common stuff from nuget.org (nothing internal).
It is referenced like this:
<PackageReference Include="My.Contracts" Version="1.0.14" />
Isolating certain code for re-use in other projects
Since version 1.0.14 I have moved logic out of the code because it needs to be used by other projects. Think things like authorization and general purpose logic that will be the same and should be shared centrally for re-use and simple maintenance.
For that a new internal nuget package was introduced. It is called
My.Shared.Backend.Integration
It is published to the same feed My.Contracts is on.
Current situation
My.Contracts has been updated to use that central package and has been updated to version 1.0.16.
I am now trying to update our Blazor frontend WASM to this version.
If I run dotnet --version I get 8.0.101.
What I run into
If I update my nuget packages on the Blazor UI I get this in the *.csproj
<PackageReference Include="My.Contracts" Version="1.0.16" />
but the reference is still shown as version 1.0.14:
That version issue is rectified after I close VS and reopen the solution, it’s corrected to 1.0.16. But the yellow triangles are still there and now also get this when I build:
My question
It seems something is ‘freaking out’ Visual Studio. This should be very straightforward, all solutions and projects are on NET8.
The reference tree is also not too complicated:
UI > Internal Contracts Library > Internal Logic Library
Why am I getting these yellow triangles (or how can I found out) and
what can I do to resolve this?
2
Answers
You’re receiving the yellow triangles due to incorrect version numbers.
A simple way to resolve this may be do clear your nugget cache:
Tools > Options > NuGet Package Manager > General, and clicking on "Clear All NuGet Cache(s)".
Visual Studio has a concept called a design time build
Emphasis mine.
The way that SDK style projects work in Visual Studio, with regards to NuGet, is that the project system loads the project, does a Design Time Build (DTB), uses the results to collect PackageReferences, PackageVersions, and all other information that NuGet needs, then the project system tells NuGet all this restore information. Then NuGet restores the packages, and writes the results in a file named project.assets.json. Finally, the project system can update the dependencies node with the actual package information.
What I mean by actual package information, is that if your project uses floating versions (for example,
8.*, or*), the dependencies node will tell you the "actual" version, not the "requested" version. Another example is if you have something like<PackageReference Include="Newtonsoft.Json" Version="13.0.0" />in your project, but Newtonsoft.Json doesn’t have a version 13.0.0. The lowest 13 version is 13.0.1. The dependencies node will show version 13.0.1, also showing NuGet’s warning about version 13.0.0 not being found.Anyway, if the DTB fails, then the project system often does not tell NuGet about the project package references, versions, etc, and therefore NuGet doesn’t know it needs to restore different packages. Therefore, the assets file still contains information about the previous restore. Hence, when the project system updates the dependencies node with information from the assets file, it’s using old package versions from the last restore that actually ran.
TL;DR you need to focus on fixing errors first. That NETSDK error is almost certainly causing a DBT failure, preventing NuGet from running restore, and updating your package version.