Graphinder – Solution changes and nuget hell


While I’m moving my solution closer and close to first microservice part, I’ve decided to rearrange my solution a little.
I’ve decided to divide folder hierarchy inside solution, based on to which microservice part it belongs.
Besides a minor inconvenience on having to manually rearrange folders despite the fact that they were already in Visual Studio (solution folder does not represent physical one in system), I think it went quite smoothly. As long as I didn’t attempt to restore my projects’ depedendencies… and entering nuget hell.

Nuget hell genesis

I’ve decided to move all my algorithms project elements from solution root to subfolder of /Algorithms.
Of course, first thought: “there would be problem with packages path”. Nuget will have problem with finding ../packages folder as it’s located by default in solution root.
Alright, I’ll change paths in project files then. Example change that occurred in .csproj was:

Before

After

Straightforward, right? Right.
But Visual Studio insisted that:

This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.

But by the love of… they ARE THERE. !#(*@#*(!^#*!^##&T*$@(#!@!
Alright, calm down. Let’s look for some clues then. Keep looking…
We have a suspicious thing here. Error tells us that the guilty one is \packages\xunit.runner.visualstudio.2.1.0\build.

Nuget hell – solution (a.k.a nuke em all)

What would a sane developer do? Delete reference perhaps. Let’s try out then.
Reference of xunit.runner.visualstudio.2.1.0 removed, rebuilding project, looking at build output…

This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.

🙉

But I’m not even referencing this, how come!?
Let’s see what’s in the project’s .csproj once again…
Wait a second fella, what are you still doing here?

Whole XML node removed, nuget readded from Package Manager Console, let’s see now what will explode…

========== Build: 11 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Now that’s what I’m talking about! New solution hierarchy feels a little more organized now, although I’m already thinking of splitting it into Shared, WorkerApi and GatewayApi subfolders for the sake of readability.

Final outcome of my crusade against nuget references:

nuget hell solution outcome

2 thoughts on “Graphinder – Solution changes and nuget hell”

  1. Have you seen Paket (http://fsprojects.github.io/Paket/). It is a much better (albeit incompatible in some minor details) alternative to NuGet Package Manager. It works with NuGet packages and also git(hub) and http dependencies.

    It does a much better job keeping references clean and has a more sane approach to version resolving IMO. It’s also great for creating packages from solution projects (see paket pack command and the paket.template file).

Leave a Reply

Your email address will not be published. Required fields are marked *