Yesterday, I found myself face-to-face with a rather peculiar phenomenon that managed to consume a good hour of my time. As is often the case, the solution turned out to be surprisingly simple. With the intention of documenting this for future reference (especially for my future self), I am writing this short blog post.
What happened?
A colleague of mine updated XUnit in our solution and merged it into our main branch. When I pulled the new code locally and tried to restore the NuGet packages, I encountered an error message:
xunit.assert version 2.4.2 is not compatible with net6.0 (I don’t recall the exact wording, but it was something along those lines).
How can that be?
This seems quite unusual indeed. After all, xunit.assert version 2.4.2 is compatible with .NET Standard 1.1, which is in turn implemented by .NET Core 6.0. Even after multiple attempts at restoring and rebuilding, the error persisted. It’s perplexing.
Alright, maybe the restoration process is not working correctly. How about trying dotnet restore --no-cache? Hmm, that didn’t help either. What if we clear the local NuGet cache using dotnet nuget locals all --clear and then perform a restore? No, that didn’t work either…
It didn’t make sense, so the question arose: Did XUnit perhaps upload a new NuGet package with the same version that is no longer compatible with .NET Standard 1.1 due to some error? I launched the NuGet Explorer to investigate, but no, everything appeared to be correct there as well.
How was the problem solved?
In the end, it turned out that there was a persistent old (incompatible) version hiding in my bin and obj directories, despite explicitly rebuilding the solution.
To delete all the bin and obj folders (and their contents) in a directory, you can use the following PowerShell script:
Get-ChildItem .\ -include bin,obj -Recurse | foreach ($_) { remove-item $_.fullname -Force -Recurse }
I have a Clean-Tree.ps1 which does exactly this (and deleting some other directories of our C++ projects, which have custom Release/Debug folders)
I do this when I do a “global” package update, e.g. after monthly .NET updates.
And sometimes it’s useful to delete .vs, too.
Why not use git clean -xdf?
Sure, that would work as well!
The blog post, however, is not about the script that was ultimately used at the end, but rather about the described problem and what ultimately caused it.