Questions regarding changes to solution & project

Apr 8, 2012 at 3:50 PM

I'm using nuget from time to time, but would like to change to integrate it fully in my workflow.
I've still some questions regarding nuget, nuget settings and source control (git in my case).
If you don't want to read all questions (I know I've written too much :-), number 4 would be my favourite, as 1-3 only concern inital setups, whereas 4 concerns daily workflow.

  1. The "Enable Nuget Package restore" introduces following to my project files:
    <SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\</SolutionDir>
    I'm just asking, in which case is this needed? If I delete the line, VS & Nuget still rebuild my packages.
  2. The "Enable Nuget Package restore" also includes the newly created .nuget folder as a project in my sln-File. I don't need that "project" show up in my solution. If I remove the project-entry from the sln-File (so not let change my sln by nuget at all) recreation of packages still works as should.
    So, in which case is that project in the sln-File needed?
  3. I don't need the .nuget checked in my source control at all. I've created an environment variable named NUGET which points to [MyWindowsUserDir]\Visual Studio 2010\.nuget.
    Then in the projectfile: <Import Project="$(NUGET)\nuget.targets" />
    And in the $(NUGET)\nuget.targets: <NuGetToolsPath Condition=" '$(OS)' == 'Windows_NT'">$(NUGET)</NuGetToolsPath>
    This works, but in new solutions (or if someone clicks "Enable Nuget Package restore" a second time), following will be added: <Import Project="$(SolutionDir)\.nuget\nuget.targets" />
    It would be nice to have a setting in the GUI, where you could define the nugettoolspath, are there any efforts? Any thoughts about this?
  4. It would be nice if I could change the packages foldername:
    I've edited this in my nuget.targets:        
    <PackagesDir Condition=" '$(OS)' == 'Windows_NT'">$([System.IO.Path]::Combine($(SolutionDir), "..\dependencies\nuget"))</PackagesDir>
    The packages will be recreated there if I rebuild my solution, but the hintpath of the dlls will be still on $SolutionDir\packages (therefore not found) and the gui will also point there (installing, uninstalling won't work with the changed path)
    Is there a way to change that foldername (I would even take a hack in win-Registry, if this is the only way).
    A kind of setting in the GUI would be nice, like so: Packages-Dir: $(SolutionDir)..\dependencies\nuget, which defaults to $(SolutionDir)\packages (which is the default right now)

Thanks in advance!

Apr 9, 2012 at 3:58 PM
  1. That's needed for scenarios where you build the csproj directly (e.g. from msbuild) without going through the solution. In that case $(SolutionDir) is undefined, which can break things. If you only build from the solution, it doesn't matter.
  2. I don't think it has to be in the solution. Maybe it's needed for TFS scenarios that integrate source control into VS, to make sure those files get checked in.
  3. The danger with doing this is that someone cloning your solution won't be able to build it unless they're also set up in the same way. Still, it may be interesting to support an env variable that points to a default location for those files, as I agree it can be painful to check those into source control. You may want to open a suggestion issue.
  4. tracks this one
Apr 11, 2012 at 9:54 PM

Hi thanks for the fast answer:

  1. I'll leave it out for the moment, since I'm only using solutions for building. 
  2. I had no problem taking it out so far.
  3. I understand the implications of doing that, there is a small number of developing machines, so it shouldn't be a big deal. I think I'll do it the way I described. It just disturbs that I have to setup this manually. It would also be sufficient to have just the "Nuget bootstrap" in the .nuget dir (I'll have to build my sources 2 times after starting: 1 time to download the "real" nuget and the second to get the packages). Anyway I don't feel comfortable with checking in any binary. (ok pictures don't count :-) )
  4. I somehow reorganized my projects and overthought my structure, a global gitignore also works on packages and as far as I don't name things I want to check in "packages" it should work. Let's say I can live with it for the moment.

Thanks again, perhaps there should be just some more Settings, one for the Nuget.exe-thing and one for the default packages-dir, perhaps I'll open a suggestion.

Apr 11, 2012 at 10:27 PM

For #3, I wish we could have a way for NuGet.exe itself to get downloaded on demand. e.g. some logic in the build script would check if it's there, and if not download it on demand. I agree that having to commit nuget.exe is unfortunate (and it's bigger than it should be!).

Apr 11, 2012 at 10:36 PM

Actually, looks like that's been done! See

Apr 12, 2012 at 9:11 AM

Wow, dind't even know, that I could do such kind of task in a targets-file!
Thats a appropriate solution of not including any binary-files.

Thanks for this code-snippet!

Apr 12, 2012 at 4:11 PM

I didn't either, but I think I'll use it :) We should try to get something like that into the default workflow.