This project is read-only.


Adding "Nuget pack project.csproj" to a post-build event causes an infinite loop


Trying to automatically package a project on build, I added a post-build event to run "nuget pack" with the .csproj as an input. This caused an infinite loop as pack itself runs a build, so another post-build event is raised, and so on... until the memory of my PC was filled up with lots of "nuget.exe" processes.

In order to be able to run "nuget pack" with the .csproj file (to get metadata from it) in a post-build event, it may have another parameter to avoid the build process, and perform only the package actions. Maybe it should do the build by default, and only avoid it in a post-build event via parameter.

Something like: "nuget pack project.csproj -o packages -disableBuild"
Closed Jun 2, 2011 at 9:18 PM by aldion
  • default: pack uses compiled project but doesn't build, no crash on post-build
  • default: error mentionning to build when project is not built
  • pack -build will build the project


davidebbo wrote May 5, 2011 at 6:49 PM

Someone also brought up issues with the fact that the command builds the project in this thread: I wonder if we should change it so it simply never builds, and makes that something that needs to be done separately (whether from VS or using msbuild).

Yet another issue when we build the project is that the solutiondir variable is not defined, which can break some pre/post build commands.

sgisbert wrote May 5, 2011 at 7:10 PM

That's true, the $(SolutionDir) variable broke it. Had to change it to "$(ProjectDir)..\tools\nuget ... ".

In my opinion, it's not bad that "pack" builds the project. It may be suitable for other scenarios. Obviously not for a post build command :) And once the work is done, it's a pity to throw it to garbage. So, I would prefer adding a new parameter to avoid the build step. In this way, you can keep both.

Haacked wrote May 10, 2011 at 10:35 PM

Change Pack to not build by default. Consider a flag to allow it to also build it. -Build

dfowler wrote May 25, 2011 at 12:40 AM

Fixed in changeset 857a20ee9a09