NuGet issues with packages.config, project references and the solutionwide packages folder

Question

We are starting to use NuGet and we are having some issues:

First some NuGet facts:

(Just to make sure that we have understood the premises for how NuG

Answer 1

As suggested in NuGet Enterprise - best practices for different maturity levels of packages, I think you are making things more complicated than necessary :)

1. Why would you not want to capture the version of the package with which the code was compiled? This is crucial information for reliable diagnostics and repeatable builds. Given that you'd likely be committing code changes back to version control, committing details of which packages were used to help build that source is very useful.
2. "when installing i.e. a Foo-1.1.0 version, allowedVersions="[1,2)" should be implied" I do not think that allowedVersions can ever really be implied, because not all NuGet packages adhere to SemVer (see the debacle with log4net 1.2.11). Setting up a grep for allowedVersions as part of either CI build or pre-commit/pre-push Dev checks should catch this. It should not change often, and it's useful to keep an eye on it (if other teams and packages are using SemVer correctly, anyhow :) ).
3. To find Prerelease packages you'll need the Prerelease or -IncludePrerelease flags on nuget install.
4. "If you are working in a mix-and-match solution, which contains a project-A (repo-1) and project-B (repo-2)" - why have you arranged your code like this? The code for a single solution should live all in the same repo. Breaking solution code across repos is definitely going to be painful!
5. You can tell nuget to use version-less folder names for installing packages (-ExcludeVersion).

I would strongly recommend ditching the Visual Studio NuGet integration in favour using the command-line nuget.exe and build scripts instead. This relates particularly to #5 but to interaction with NuGet in general. The Visual Studio integration is nice when working solely with 3rd-party public packages from the nuget.org feed, but is not flexible enough for my liking when dealing with internal NuGet feeds and packages.