I enabled package restore on one of our solutions to test it out, and it does not play nice with our CI (TeamCity).
When enabled, package restore adds the following to your project files:
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\..\MySolution\</SolutionDir>
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
The problem is with the hard coded Solution directory name, in this example "MySolution". In our setup, and I think this is typical, we have TeamCity check out the source from the root directory of "MySolution" into the root of the build
agent. The directory name on the Build Agent is not "MySolution" but more like "1d04296e17d6eb39". When TeamCity tries to build the solution, it fails when it can't find the directory "..\..\MySolution" (because it does not exist).
There are two work arounds:
1. Checkout to the sources to a subdirectory on the build agent named exactly like the folder in the project file. This is undesirable for us because we have other process that assume the solution file is in the root on the build agent. These values could
potentially get out of sync and cause a configuration headache as well.
2. Change the line to be purely relative like so:
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\</SolutionDir>
I personally use the second workaround. Nuget doesn't go in after the fact to change the directory back to the hard coded value.
I'm not sure why the solution directory name is hard coded in the solution file, but if there isn't a compelling reason, I would think Nuget should use a purely relative directory by default. This seems to be more in line with the way solution and project
files are setup in my opinion.