-
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
1 2 3 4 |
<Reference Include="NSubstitute, Version=1.9.2.0, Culture=neutral, PublicKeyToken=92dd2e9066daa5ca, processorArchitecture=MSIL"> <HintPath>..\packages\NSubstitute.1.9.2.0\lib\net45\NSubstitute.dll</HintPath> <Private>True</Private> </Reference> |
After
1 2 3 4 |
<Reference Include="NSubstitute, Version=1.9.2.0, Culture=neutral, PublicKeyToken=92dd2e9066daa5ca, processorArchitecture=MSIL"> <HintPath>..\..\packages\NSubstitute.1.9.2.0\lib\net45\NSubstitute.dll</HintPath> <Private>True</Private> </Reference> |
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?
1 2 3 4 5 6 |
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild"> <PropertyGroup> <ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText> </PropertyGroup> <Error Condition="!Exists('..\..\packages\xunit.runner.visualstudio.2.1.0\build\net20\xunit.runner.visualstudio.props')" Text="$([System.String]::Format('$(ErrorText)', '..\..\packages\xunit.runner.visualstudio.2.1.0\build\net20\xunit.runner.visualstudio.props'))" /> </Target> |
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:
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 thepaket.template
file).I will definitely take a look as I’ve had it enough with nugets already.
Thanks for the tip!