Package folder without version string, Hintpaths merge hell

Topics: General
Dec 13, 2012 at 8:41 AM

This would be about package folder names with versions. I shall start from the beginning, in this case from the problem I have in one of my projects. At my company we organized branches in rings. Simple rule – ring X is able to use artifacts from lower rings only and using this simple rule and dependencies between branches we created something like 10 rings with almost 40 branches producing something about 300 artifacts.

Of course, artifact (CI terminology) means nuget package. We incorporated build number in package version and here problem starts. Changing package number means changing:

  • Hintpaths – so *.csproj  are modified
  • Package versions – package.config is changed

And we are doing this each time we invoke build (automatic variation of nuget update).

We can argue that merging files as a consequence is not that traumatic as it sounds, but still in a large project with many developers it can hurt.

So there came ideas of:

  • removing version string from package folder
    • (+) HintPaths does not change, no merge needed
    • (+) packages.config does not change
    • (+)we still have packages versioned
    • (-) nuget does not allow this
  • freezing package number
    • (+) HintPaths does not change, no merge needed
    • (+) packages.config does not change
    • (-) we loose packages versioning
    • (-) nuget gallery, which is out feed, does not allow (and I won’t argue with this) pushing duplicates J, so it needs uninstalling package first

Going through pros and cons I think first option is to be chosen.

 I checked nuget sources and there is almost everything we need to do so (probably because of nuget install /x functionality). So I made simple proof of concept:

  • Added new class MyPackagePathResolver derived from DefaultPackagePathResolver and hardcoded setting of _useSideBySidePaths field to false.
  • I changed all calls to DefaultPackagePathResolver constructor to my class …

It works … of course this was just proof of concept. What is missing:

  • Propagating _useSideBySidePaths from constructors
  • Putting information about “changed” behavior of nuget into nuget.targets (I think the best option) so it can be used in DefaultPackafePathResolver
  • Going through negative scenarios when because of dependencies we have conflicting packages (not my case, but still to be done). With only one package folder it could be a problem.
  • Tests, tests, tests

What do you, my dear community, think about this.