5

We have successfully set up a couple of local package repositories using the NuGet.Server package and hosted them on a local IIS webserver. We are able to connect from the Package Manager and install no problem. So these are working fine.

In order for us not to have to check in our packages folder we have included the following command line in each project file that includes NuGet references. This works, if the NuGet.exe is in the path on the CI build agent.

However, I would like to move the source configuration form the command line in every project file and put it in just one place, preferably where other pesky developers can't change it ;)

<Target Name="BeforeBuild">
    <Exec Command="nuget install $(ProjectDir)packages.config -s 
       http://domain:80/DataServices/Packages.svc/;
        http://domain:81/DataServices/Packages.svc/ 
       -o $(SolutionDir)packages" />
</Target>

Is there a better way?

Daniel Dyson
  • 13,192
  • 6
  • 42
  • 73

2 Answers2

13

Yes there is ;-) Take a look at NuGetPowerTools. After running Install-Package NuGetPowerTools, it adds a .nuget folder to your $(SolutionDir) containing nuget.exe, nuget msbuild targets and settings (which you will need to check in).

After that, you simply run Enable-PackageRestore and it sets up msbuild targets into your visual studio project files which will make sure that packages will be fetched in a prebuild step, even on your build server, without checking in any packages. (don't forget to check in the .nuget folder though!).

This way, you simply manage the nuget package sources in a nuget msbuild settings file (in the .nuget folder) central to your solution, instead of in each project.

Cheers, Xavier

Xavier Decoster
  • 14,580
  • 5
  • 35
  • 46
  • Exactly what I was going to say. It even works from inside visual studio when you hit Ctrl+Shift+B – ferventcoder Sep 22 '11 at 20:30
  • I tried that and got this error. https://github.com/davidfowl/NuGetPowerTools/issues/8 Can't get NuGetPowerTools to install. so need another way. I think I might trawl through the PowerTools package and recreate the steps manually. – Daniel Dyson Sep 22 '11 at 21:38
  • Someone responded on David Ebbo's post: I turned on verbose logging for the import-module cmdlet and found out that NuGetPowerTools.psm1 was the offending file. Re-saving the file (which is empty) to UTF-8 encoding fixed the problem. – Danny Tuppeny Sep 26 '11 at 17:36
5

I finally got NuGetPowerTools to install after the advice from digitaltrust on http://blog.davidebbo.com

Although NuGetPowerTools solved my problem, it was overkill for what I wanted. It requires that you check in to version control a .nuget folder that it creates in your solution root. The folder contains NuGet.exe, and a couple of target files. I don't like this as I think version control is for source code, not tools.

I came up with the following solution.

  1. Save NuGet.exe to a folder on your local drive, both on dev and continuous integration machines. I chose C:\tools\nuget\
  2. Add that filepath to the Path Environment Variable in all environments

  3. On continuous integration machines, find %APPDATA%\NuGet\NuGet.Config and enter the following

    <?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
    <add key="LocalRepositoryName" value="http://Domain/DataServices/Packages.svc/" /> 
</packageSources>

    You can add more than one entry to packageSources and NuGet will search them in the order that they appear

  4. The after build code from my question can now be amended to the following.

    <Target Name="BeforeBuild">
    <Exec Command="nuget install $(ProjectDir)packages.config 
    -o $(SolutionDir)packages" />
</Target>

The end result of this is that whenever the approved repository location is changed, the config has to be changed in only one place rather than in every csproj file. Also, it is the continuous integration server administrators who determine that location, not the developers in their command line calls.

Daniel Dyson
  • 13,192
  • 6
  • 42
  • 73
  • This looks like more overkill to be that using nuget power tools. You can get the same benefits if you used it and just changed where it looks for nuget.exe.. – davidfowl Oct 01 '11 at 08:38
  • 1
    I wouldn't have had to come up with this solution if PowerTools actually worked without having to go in and edit the package, which had a file saved with the wrong encoding. You checking in an untested package to the official feed cost me and probably many others a good half a day. That cost my client a lot of money. – Daniel Dyson Oct 04 '11 at 14:53
  • I've seen many people complain about that bug but I haven't actually reproduced it myself. Sorry you have to go through that though. Hopefully it'll be fixed soon. – davidfowl Oct 04 '11 at 15:08
  • No worries. If it helps, my machine is an XP 64 bit machine. Not a very common OS, but I don't have a choice with this client. – Daniel Dyson Oct 04 '11 at 16:07