TeamCity NuGet Installer step issue

6
votes

I'm building a project in TeamCity with NuGet package restore enabled.

I have two build steps:

  • NuGet installer
  • MSBuild

One of the projects has the log4net-package from the official feed installed. (But don't get to hung up on which package)

My problem is when TeamCity runs the first step, it fails in the nuget-installer step with the message: Unable to find version '2.0.3' of package 'log4net'.

So after doing my best to find any errors in the solution, I try to:

  1. Disable the NuGet Installer step
  2. Run my build - which obviously fails because it has no packages (see below)
  3. Enable the NuGet Installer step
  4. ReRun build

[Edit] Concerning the 3. step, MSBuild should ideally, as John H. points out, be able to rebuild the packages, so I shouldn`t need a NuGet Installer step. The error when I try to build the solution without the nuget installer step has something to do with the OctoPack-package I have installed:

OctoPack cannot be run because NuGet packages were restored prior to the build running, and the targets file was unavailable when the build started. Please build the project again to include these packages in the build. You may also need to make sure that your build server does not delete packages prior to each build

Then it succeeds.. Why?

Does anyone have some insight on my issue?

Some more background:

I assume this has something to do with the octopus deploy package. I have the octopus deploy plugin installed on the teamcity server and I´ve ticked the Run OctoPack checkbox in the MSBuild step.

I have tried to uninstall the octopack package and reinstall without any success.

Can it be that NuGet-package restore on the MSBuild-step combined with the octopus plugin is causing my problems?

[Partial resolution] I'm still uncertain why I got the error on the log4net-package. I was running NuGet installer as the first step in my automatic build, which in the end proved to be the correct thing to do due to the nature of the build.

I admit I don't (always) read the "what's new" when a package is updated. When upgrading Octopack from 2.0.26 to 3.0.19 one of the changes is that you no longer need to check in the .octopack folder. So I could really understand why the build could not find the targets-file, when it was checked in.

Now I've:

  • upgraded to Octopack 3
  • removed the .octopack folder from version control
  • (again) enabled the nuget install step in teamcity

and the build is running fine.

Thanks for all help! I'm a better educated man now :)

[Removed] irrelevant information

1
teamcitynugetoctopus-deploy
Is the point of the 'NuGet installer' step explicitly to restore packages for the MSBuild step? Properly configured, the MSBuild step should be able to restore packages without any help. Does the MSBuild step log any NuGet errors? – John Hoerr
Hi John, thanks for pointing that out. When I disable the package restore step and run the build that fails, the error is actually concerning another package OctoPack. "OctoPack cannot be run because NuGet packages were restored prior to the build running, and the targets file was unavailable when the build started. Please build the project again to include these packages in the build. You may also need to make sure that your build server does not delete packages prior to each build". Ill look into that.. – HaraldV
I'm getting the same here using ContinuiCI which creates a new copy of the source folder for each build. If I'm reading this right that means the packages will be restored for each build? – Sean Kearon
I reverted from Octopack 3.0.19 to 2.0.26 and the problem went away. I've reported it to Octopus here: help.octopusdeploy.com/discussions/problems/… – Sean Kearon
Hi Sean, I installed 2.0.26 as well, now it builds. Without the NuGet Installer step as John pointed out. – HaraldV

1 Answers

3
votes

The solution is to run Nuget restore before the restore step that is run by MSBuild.

The MSBuild step halts if it has to restore packages. Doing the restore before MSBuild runs prevents means it does not have to do a restore. This solution is discussed in this .NET Framework Blog article.

Response from the Octopus Deploy team is here.

The same problem can cause TFS to fail - see RinoTom's answer here. I use Continua CI and have added a command line step to run the Nuget restore prior to the MSBuild step.