• Github
  • https://github.com/m-wilczynski/Localwire.Graphinder
• Graphinder series articles
  • Graphinder – Project Introduction
  • Graphinder – I don’t need this covered…
  • Graphinder – Minimum Vertex Cover problem
  • Graphinder – Simulated Annealing algorithm
  • Graphinder – Code review yourself
  • Graphinder – Genetic Algorithm – Introduction
  • Graphinder – Genetic Algorithm – Selection
  • Graphinder – Genetic Algorithm – Crossover
  • Graphinder – Genetic Algorithm – Mutation
  • Graphinder – Genetic Algorithm – Wrap up
  • Graphinder – Monthly Progress Report – March
  • Graphinder – Async IEnumerable with Rx.Net and IObservable
  • Graphinder – Reporting progress with Rx.Net
  • Graphinder – TDD and starting from red
  • Graphinder – Domain models vs Persistence models
  • Graphinder – Queries and Commands vs Repository pattern
  • Graphinder – Encapsulating persistence layer
  • Graphinder – Solution changes and nuget hell
  • Graphinder – Monthly Progress Report – April
  • Graphinder – Application architecture
  • Graphinder – Resources planning on Azure
  • Graphinder – Quick summary and what next
  • Quick thoughts after Daj Sie Poznac 2016 finals

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: